Hi Campers,
Please see my stock price checker on Repl.it
https://repl.it/talk/share/Stock-Price-Checker-FCC/123300
Some comments on this challenge:
This one took me about a couple days(spread out, after work hours) to complete, and the biggest “practice” here is integrating a REST API call with a Mongoose Server. How you integrate those promise calls together is key to solving everything. I would review promise chaining and fetch, async/await in Javascript. What I like about FCC is how knowledge in one module builds upon knowledge in another module, and things aren’t always super clear, so that really encourages folks to read documentation.
For the key takeaways, let me know if I’m getting any concepts wrong, so I’m not going to confuse others (still trying to piece this together myself).
Key Takeaways:
- Async/Await - Return Statements & Loops
Async functions can be a challenging concept in JS (at least for me), and it’s hard to find good explanation of this on the internet that is really clear. Basically, ‘async’-tagged functions calls a remote server and takes time to respond, and ‘await’ makes sure that the remote call happens BEFORE the rest of the code runs. This whole process is a ‘Promise’. This happens a lot in this challenge, because calling the REST API and the database are both async calls, and connecting them requires you to think clearly about the ‘logic flow’ of the problem. In the context of all of this, you can separate out different logics into separate functions to keep the code clear, and keep testing (console-logging) to make sure that the promises are not ‘tripping’ over one another. Also, make sure that you have your ‘return’ statements written in all the right places, so that the functions know what to return and when to return them.
- Javascript - Promise Racing
Continuing on the async discussion is the concept of ‘Promise Racing’. Sometimes you may have to loop some async calls, and perhaps the promises need to happen one after another. Other times, maybe the promises need to all be completed BEFORE moving on to other code logic. This is when ‘promise racing’ kicks in. Something like ‘Promise.all’ makes sure that all promises are completed before resolving a variable/expression.
- Setting the IP so you can only ‘like’ if its a fresh IP
A nuanced part of this challenge is to make sure that users can only ‘like’ a stock once, per each individual IP. To solve this, I had to create a new property in the db document to keep track of all the IP addresses coming onto the site, and verifying if that IP has come before and liked something. This is probably not the greatest solution(?), but the only one I can think of that seems to make sense (you’d have to track each like, and see if that person’s IP has liked before). Let me know if there are better ways to do this.
- Chai Testing - ‘Set’ HTTP Header
Because I wanted to track IP information, the Chai Testing will break unless you also set an HTTP header attribute for each request to the server. In order to do this, use:
.set({'some custom attribute': 'some value'})
as part of your chai request call.