Learn AJAX by Building a View Counter

[karuppiah7890]

Let me know if I understood this project right - it's a single web page which has a counter showing number of views for that web page. And there's a backend which stores this counter value.

[karuppiah7890]

I am planning to build it by assuming the above idea. Let me know if it's a different idea @QuincyLarson

[QuincyLarson]

@karuppiah7890 Awesome! It's all yours. You can get started on this.

[karuppiah7890]

@QuincyLarson I have questions regarding this challenge.

I am not sure if I understand the goals of the project. I feel like it has mixed things in it. Like, Ajax coming under data viz - I think Ajax is pretty common and not specific to data viz, no? About the data viz part, the visualization is just showing the number of views of that web page? or is it like a graph of the number of the views over some time (past 1 day, 1 week etc)? and are we going to push and pull data (number of views) to and from an actual backend ? if yes, then we need backend too - is that within the scope of this project ?

I wasn’t sure of these, so just wanted to clarify on what were the goals and thoughts when this project was created

Also, based on assumptions, I tried building this golang in the backend and was planning to use vuejs and bulma on the front end. But I guess the stack will be different for the challenge ? Like vanilla js on the front end ? And based on the above questions, probably nodejs backend or no backend?

[karuppiah7890]

@QuincyLarson ping^

[QuincyLarson]

@karuppiah7890 The reason we're including AJAX in the data visualization section is it's a common way of retrieving and updating visualizations, and this is the certification that has the least amount of tools that need to be learned. In the interest of keeping all the certifications at roughly 300 hours of learning, I think this is a good place to put it.

We won't have a back end for any of these projects, because that would require reliable internet access, and we want these projects to be completable offline. Instead, you will want to mock out the response.

[scissorsneedfoodtoo]

@karuppiah7890, just wanted to check in and see how everything's going with this project.

Please correct me if I'm wrong, @QuincyLarson, but I believe this project will be a replacement for the lessons here: https://learn.freecodecamp.org/data-visualization/json-apis-and-ajax. So your project doesn't have to be overly complex, just something along the lines of a basic blog article with a simple view counter tracking the total number of views. It's more of a way to teach users how to make HTTP requests with XMLHttpRequest, displaying the (mock) JSON data, and updating the view count. This would also be a good way to teach users about fetch by refactoring their XMLHttpRequest code once it's working.

As for the front end, I would say that it's best to build it using basic HTML and CSS, and to use vanilla JavaScript to handle the requests and posts.

Please let me know if there's anything I can help with!

[HKuz]

Hi folks - an FYI only - I'm working on the JSON challenges, which cover JSON.stringify() and JSON.parse(), but to keep things simple I'm not including lessons on XMLHttpRequest or fetch(). I'm guessing the JSON section will be ordered before this one, so one of my challenges is currently referencing them and saying they're taught in the AJAX section (which seems to make more sense). I'll keep an eye on this project and just make sure my section ties in properly with what you end up covering 👍

[karuppiah7890]

@scissorsneedfoodtoo @QuincyLarson thanks for the inputs! I still haven't started. Will start working on it. I have to learn about mocking though and see how I can incorporate it in the challenge. Will create a very basic project and post the link to it here 😄

@HKuz sure ! 👍

[scissorsneedfoodtoo]

@karuppiah7890, just checking in to see how things are going with your prototype. Do you have anything you can show us? If so, we could give some early feedback.

[karuppiah7890]

@scissorsneedfoodtoo No. I just have a small html page with some css. I am still looking at options on how to mock the response https://github.com/berniegp/mock-xmlhttprequest , https://www.wheresrhys.co.uk/fetch-mock and I am not sure how it will be explained to the students if I put the mock code

[scissorsneedfoodtoo]

@karuppiah7890, that's great! Looking forward to seeing your view counter soon.

It's my understanding that we'll try to keep things as realistic feeling as possible, and will probably not explain the fact that we're mocking these services. I did some a bit of searching and found this page that suggests using local JSON files to create a simple mock backend. It does mention that only GET methods are possible with local JSON files, though. I imagine the final project will involve many local files and regex for testing, rather than actual POST and other methods.

For a simple prototype, feel free to use any packages to get things working. Once we see it we'll get a better idea of how to get things working offline.

[QuincyLarson]

@karuppiah7890 I hope you're having a good weekend. Please keep us posted on your progress - I'm super excited to see what you build with this.

[karuppiah7890]

@QuincyLarson @scissorsneedfoodtoo here's what I got working https://karuppiah7890.github.io/view-counter-example/ and the source code is here .

Let me know how it looks. I made it very simple. I only used a GET request to get the mock view count; didn't do any POST to increment view count as I wasn't sure to persist it and also I wanted to keep it simple to start with.

About implementation, the js has require for the mock server module, so I had to use parcel to bundle it, as I couldn't see any doc in mock-xmlhttprequest on how to just use a single js file in the script tag. If I go with this, we will have to create that js file ourselves and get rid of the require line and use the module file in the script tag

[scissorsneedfoodtoo]

@karuppiah7890, this is definitely off to a great start! Glad that you were able get the GET request working. Were you able to get POST working in some way? Since this is just a prototype, using local storage or even a simple DB to keep track of the count is totally fine -- we can figure out the offline functionality later.

[karuppiah7890]

@scissorsneedfoodtoo I didn't try the POST. Will try that and try to use local storage to store the count and use it for the GET too!

[scissorsneedfoodtoo]

@karuppiah7890, okay, no problem! Looking forward to seeing what you come up with :+1: :+1:

[karuppiah7890]

@scissorsneedfoodtoo I used local storage and it worked great! I have deployed the new site https://karuppiah7890.github.io/view-counter-example/ . Check it out and let me know how it looks 😄

[karuppiah7890]

I just assumed success scenarios for the GET and POST requests to get the whole thing working

[scissorsneedfoodtoo]

@karuppiah7890, this is coming along really well! I was able to get your code up and running with locally with parcel, which is neat little tool. I believe another contributor is using the same package for the TypeScript Poker Game.

My only suggestion at this point would be to add a bit of error handling in the addEventListenermethod. It's fine to assume success scenarios at first, but it would be good to teach students about how to handle situations where an AJAX call fails. It could be a few simple lessons about error codes and how to handle an error, whether that be appending something to the page or just a console log. Also, I ran into some reference errors while running this locally. Could you add const or let where necessary?

[karuppiah7890]

Sure, I will see what basic error scenarios I can think of and try to implement them!

On Mon, Apr 29, 2019, 12:14 PM Kristofer Koishigawa < notifications@github.com> wrote:

@karuppiah7890 https://github.com/karuppiah7890, this is coming along really well! I was able to get your code up and running with locally with parcel, which is neat little tool. I believe another contributor is using the same package for the Typescript Poker Game.

My only suggestion at this point would be to add a bit of error handling in the addEventListenermethod. It's fine to assume success scenarios at first, but it would be good to teach students about how to handle situations where an AJAX call fails. It could be a few simple lessons about error codes and how to handle an error, whether that be appending something to the page or just a console log.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/freeCodeCamp/CurriculumExpansion/issues/111#issuecomment-487466666, or mute the thread https://github.com/notifications/unsubscribe-auth/ADBXB2A5MMWKGGVBZISFQVDPS2KLXANCNFSM4G4RYTAQ .

[scissorsneedfoodtoo]

@karuppiah7890, cool! Sounds good. Any sort of basic error handling is fine, doesn't have to be complicated. Let me know if there's anything I can do to help.

[karuppiah7890]

@scissorsneedfoodtoo I simulated and handled some error scenarios based on the features the mock module provided. I published the changes to https://karuppiah7890.github.io/view-counter-example/ , just clear your storage after loading the page and then reload to see the error messages in the console. And the errors don't always occur, they occur only at some particular values of count. You can see the updated code - https://github.com/karuppiah7890/view-counter-example

[scissorsneedfoodtoo]

@karuppiah7890, thank you for your patience. This works really well! Seems like you have a good grasp of local storage and the mock-xmlhttprequest package. I noticed some inconsistent indentation and some missing semicolons, so I tried to tidy up your code a bit here: https://gist.github.com/scissorsneedfoodtoo/05339d3d65b40d21a11705ea5b12814e

I did a bit of reorganization and put getViewsReq before updateViewsReq. In my mind, this project has a bit of a narrative where students are hooking up to an existing API and the view counter starts at some number greater than 0. That way, they can write a simple getViewsReq request and see a pretty big number appended to the page quickly.

I ended up commenting out exampleBadAPIReq because, as I looked through your code, I thought it would be more natural to introduce that kind of error handling while writing getViewsReq. After writing the simple getViewsReq request, students could be instructed to change /views to /vsdfkjsjiews or some other path that will return an error. Then I thought you could introduce the different HTML status codes and how to log errors to the console. As they work through the lessons, count could change to certain larger values and produce errors (487 and 629 instead of 4 and 6, respectively). These are just some ideas I had while playing with your code, so please let me know your thoughts.

Would you be able to refactor what you have here to teach fetch as well? Now that getViewsReq and updateViewsReq are working well, it could be nice to show how simple fetch is in comparison to XMLHttpRequest. Also, do you have time to hop on a 20 to 30 minute call so we can talk more about this project? If so, please send me an email at kris@freecodecamp.org!

[karuppiah7890]

@scissorsneedfoodtoo The gist looks great! I will make those changes in my code and commit it. For fetch I need to see how the mocking of fetch is done, and accordingly do it. Not sure if I would call it a refactor, there will be some major changes in the code, and I will remove the xml http request mock module. Or I can let xml http request mock to co exist with the fetch mock. The consumer can use XMLHttpRequest or fetch for their calls and it will all behave the same way. How does that sound? And about the call, I will try! May be possible during a weekend. I will send you an email soon 😄

[scissorsneedfoodtoo]

@karuppiah7890, glad it looks good! Please take another look because there's a good chance I missed a semicolon somewhere.

Don't worry! No need to make major changes to your code. My thinking was that your project would first teach XMLHttpRequest, then refactor that code to use fetch. I've been playing around with it a bit, but I couldn't get fetch to work with MockXMLHttpRequest. I was able to get another package, fetch-mock working, though not to the extent that you got MockXMLHttpRequest to respond with the view count and different error codes. I'm not sure it's necessary to get fetch-mock working just for this prototype, especially since we probably won't have the benefit of parcel or either mocking packages on the final platform. Either way, I updated the Gist with the extra fetch-mock code: https://gist.github.com/scissorsneedfoodtoo/05339d3d65b40d21a11705ea5b12814e

At this point, I think it might be best to focus on what you already have, and start breaking down everything in document.addEventListener into short lessons. I figure we can just focus on XMLHttpRequest for now, and add more short lessons later where students refactor their code to use fetch. What do you think?

[karuppiah7890]

Sounds good to me 👍 and what will we do to mock XML http request or even fetch later? Like in the platform

On Wed, May 8, 2019, 11:14 AM Kristofer Koishigawa notifications@github.com wrote:

@karuppiah7890 https://github.com/karuppiah7890, glad it looks good! Please take another look because there's a good chance I missed a semicolon somewhere.

Don't worry! No need to make major changes to your code. My thinking was that your project would first teach XMLHttpRequest, then refactor that code to use fetch. I've been playing around with it a bit, but I couldn't get fetch to work with MockXMLHttpRequest. I was able to get another package, fetch-mock working, though not to the extent that you got MockXMLHttpRequest to respond with the view count and different error codes. I'm not sure it's necessary to get fetch-mock working just for this prototype, especially since we probably won't have the benefit of parcel or either mocking packages on the final platform. Either way, I updated the Gist with the extra fetch-mock code: https://gist.github.com/scissorsneedfoodtoo/05339d3d65b40d21a11705ea5b12814e

At this point, I think it might be best to focus on what you already have, and start breaking down everything in document.addEventListener into short lessons. I figure we can just focus on XMLHttpRequest for now, and add more short lessons later where students refactor their code to use fetch. What do you think?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/freeCodeCamp/CurriculumExpansion/issues/111#issuecomment-490355799, or mute the thread https://github.com/notifications/unsubscribe-auth/ADBXB2BTW2RFL57P5JD3FDDPUJSEZANCNFSM4G4RYTAQ .

[scissorsneedfoodtoo]

That's a great question! I guess I shouldn't speak too soon since I don't have many details about the updated platform yet. It's possible that a bundler like Parcel or Webpack will be used the more complicated projects like this or the Typescript one, but I really can't say for sure. Just to give you an idea, for other projects like creating an NPM module, we will probably have a fake console and mock return statements as students enter commands, rather than find a way to run an actual bash console in the browser.

For now we can focus on the test descriptions for each step and the actual code students will be writing as they build this project. The JS RPG Game is a good example of how much we'd like to break things down. Let me know if there's anything I can do to help!

[karuppiah7890]

Cool! I'll checkout the RPG Game and ping here if I get stuck

On Wed, May 8, 2019, 3:13 PM Kristofer Koishigawa notifications@github.com wrote:

That's a great question! I guess I shouldn't speak too soon since I don't have many details about the updated platform yet. It's possible that a bundler like Parcel or Webpack will be used the more complicated projects like this or the Typescript one, but I really can't say for sure. Just to give you an idea, for other projects like creating an NPM module, we will probably have a fake console and mock return statements as students enter commands, rather than find a way to run an actual bash console in the browser.

For now we can focus on the test descriptions for each step and the actual code students will be writing as they build this project. The JS RPG Game https://github.com/freeCodeCamp/CurriculumExpansion/tree/master/basic-javascript-role-playing-game is a good example of how much we'd like to break things down. Let me know if there's anything I can do to help!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/freeCodeCamp/CurriculumExpansion/issues/111#issuecomment-490421361, or mute the thread https://github.com/notifications/unsubscribe-auth/ADBXB2GGUWKDHM2G2P3OS2LPUKOCZANCNFSM4G4RYTAQ .

[scissorsneedfoodtoo]

@karuppiah7890, how's everything going? Were you able to start breaking this project down into steps? Please let us know your status and if there's anything we can help out with!

[karuppiah7890]

@scissorsneedfoodtoo No, I got busy in between. Gonna do stuff today!

[scissorsneedfoodtoo]

@karuppiah7890, great, thank you. Please keep us posted on your progress.

[karuppiah7890]

@scissorsneedfoodtoo I just finished writing some index.html files with comments for the span tag and for the introduction. But midway I realized I made it a bit verbose. So cutting down the details and trying to add just the instructions. Will raise a WIP PR just to show how it looks like.

[karuppiah7890]

@scissorsneedfoodtoo I raised a draft PR for this issue!

[scissorsneedfoodtoo]

@karuppiah7890, I left some review comments over in #188. Were you able to start working on another draft?

[karuppiah7890]

@scissorsneedfoodtoo No 🙈 got caught up with other things. Also, about explaining .open, .send is it okay to let them read by giving links like https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/open and just saying "now we will create a http request, and then send it" ?

[scissorsneedfoodtoo]

@karuppiah7890, it would be best if we can explain all of those concepts ourselves in just a few short sentences per step. The Express Stock Trading project does a great job of this. If you go through that project, you can see some simple explanations of different Express methods and code examples that are similar to what the learner will write.

[karuppiah7890]

Sorry folks, I have been caught up with multiple other things. Should have posted here about it. Really sorry. 😞

[scissorsneedfoodtoo]

@karuppiah7890, no need to apologize. Thank you for checking in. How's everything going now? Will you be able to work on the next draft of your project?

[karuppiah7890]

I figured I'm good at making small projects, but explaining them, not so much. I would recommend someone else to pick it up 🙈 this could be a good hacktoberfest issue

[scissorsneedfoodtoo]

@karuppiah7890, that sounds good. Thank you again for your help so far and for letting us know.

[vkWeb]

@scissorsneedfoodtoo Hey. I'm back again. I am getting back to working on some unfinished projects. I am planning to complete the Intermediate algorithm scripting project - Yahtzee by this week. I was just looking at the help-wanted issues and found this one interesting. It looks like @karuppiah7890 has already done some great work here ✨.

I took a quick look at the code. I was just thinking instead of mocking responses from the server what if we instruct campers to host a local server on their machine, we can give them a downloadable zip file with all the code for server & instructions on starting the server as a challenge kinda.

Then we can make calls to that local server. In this way, the app can be run locally and the need for external libs will be eliminated. Also, we will be more focused on the lesson material i.e. AJAX concepts instead of getting their heads around mock-server (I don't know much about mock-server stuff 😅).

What do you think @scissorsneedfoodtoo about this idea?

[scissorsneedfoodtoo]

Hey @vkWeb, glad to hear that you're making good progress on the Yahtzee project.

Creating a local server is a great idea, though I'll have to check on the updated order for the new curriculum with @QuincyLarson. I believe we'll move a few of the Data Visualization projects into the Front End Libraries section of the curriculum. The current plan is to have the practice projects for the first 3 certificates (Responsive Web Design, Algorithms and Data Structures, and Front End Libraries) all on /learn, while the rest of the curriculum will basically run in VSCode.

Given the possible complexity of this project, it might be better to move it into the APIs and Microservices section, though. That will give us the ability to run a local server in VSCode and poll that.

If it's better to have this project in the Front End Libraries section, though, an option might be to host assets on the fCC CDN and use those for the project. Otherwise we could look more into mockserver and set that up behind the scenes. Campers shouldn't have to worry about all of that, just on learning AJAX concepts and perhaps fetch while working through this project.

But what do you think? How does all that sound?

[vkWeb]

The current plan is to have the practice projects for the first 3 certificates (Responsive Web Design, Algorithms, and Data Structures, and Front End Libraries) all on /learn, while the rest of the curriculum will basically run in VSCode.

@scissorsneedfoodtoo Sounds cool. Most developers already use VSCode so it makes sense to run the backend curriculum there. Btw I'm curious as to how we'll run the curriculum in VSCode?

Given the possible complexity of this project, it might be better to move it into the APIs and Microservices section, though. That will give us the ability to run a local server in VSCode and poll that.

In my opinion, APIs and Microservices section will already have a ton of concepts to learn. So AJAX might add some overhead there.

---

If the team plans to put the first three parts - Responsive Web Design, Algorithms and Data Structures, and Front End Libraries to /learn and remaining three to VSCode. Then it makes more sense to keep AJAX in Data visualization i.e. the fourth part as it is in the current curriculum. This way we can run a local server in VSCode and make calls to it.

[scissorsneedfoodtoo]

@vkWeb, sorry, I wasn't clear in my last message. The current plan is to make the Data Visualization a legacy certificate and move some of the planned projects into different certificates. So unfortunately we probably won't have a Data Visualization certificate in the new curriculum.

I'll talk to the others about the best place for this project. If we decide to keep it in one of the three certificates on /learn, then we won't have access to a local server and will have to be a bit more creative.

I'm not sure I can say too much about our plans to run the curriculum in VSCode since it's all in early development. But for the projects that do run in that kind of environment we'll have a lot more freedom.

[vkWeb]

@vkWeb, sorry, I wasn't clear in my last message. The current plan is to make the Data Visualization a legacy certificate and move some of the planned projects into different certificates. So unfortunately we probably won't have a Data Visualization certificate in the new curriculum.

@scissorsneedfoodtoo Ohhh.

I'll talk to the others about the best place for this project. If we decide to keep it in one of the three certificates on /learn, then we won't have access to a local server and will have to be a bit more creative.

I believe we should be able to access the local server from /learn too. But yeah then campers might need to download the server runtime to their system like Node.js for a Node server or Python for flask / Django. Let things get finalized and then we'll see what can be done on this :)