According to Google Analytics, the Profile Lookup challenge is way too hard, and is taking campers an average of 7 minutes and 25 seconds to finish (if they finish - a lot of them seem to give up).
According to this table, campers spend more time on it than they do on most of the algorithm challenges.
We need to either reword this or simplify the challenge so it can be completed in closer to 3 minutes. Otherwise, we should move it back to the algorithm section.
My suggestion is to add a hint/link to the function .hasOwnProperty() in the instructions.
I remember myself being stuck on it for more than I like to admit the first time I looked at it.
I think this challenge has 3 main difficulties:
no suggested method: this can easily be tackled by adding a link to hasOwnProperty()
as @fivefishstudios suggested.
using square brackets over dot notation: this may be obvious for more experienced coders, but many beginner don't realise the difference. Maybe a link to a SO post or MDN documentation explaining why you chose one over the other.
premature "no such contact" return: this is the issue I see popping out the most in chat. Almost 99% of the people who had problem with this is because they return no such contact
straight into the loop instead of waiting to loop into the whole contact list and if no result shows up means that I can safely assume that the contact is not there.
Maybe this last one is caused by how the instructions are structured:
If both are true, then return the "value" of that property.
If firstName does not correspond to any contacts then return "No such contact"
If prop does not correspond to any valid properties then return "No such property"
I guess that a camper read the instruction as a "manual" (or at list that's what I did until I was more confident in my own critical thinking) as so implements the code mostly as its presented in the instructions.
Perhaps a re-wording on the instruction to help realise the loop/return order may be of a little help.
@Marmiz Excellent - thank you for this detailed analysis. Would you be interested in improving the copy to make it clearer?
Also, would you be interested in creating a hasOwnProperty()
article for our guide? Then we can link to that. There isn't currently a stub for this yet. If you're interested, you can create an article for it. Please let me know if I can help with this. Here's the list of JavaScript articles: https://github.com/freeCodeCamp/guides/tree/master/src/pages/articles/javascript
And here's how to get started with guides: https://github.com/freeCodeCamp/guides/blob/master/README.md
Then I recommend we move this challenge up to the basic algorithm section, since it seems to be too hard to be in the basic JavaScript section, even with the clarified instructions.
@QuincyLarson I would like to work on this if @Marmiz is not working on this.
@QuincyLarson I am happy to help.
I've looked into the JS articles and I believe that, beside an hasOwnProperty()
article we can expand the return
(or write a totally new one) related specifically about early return in looping.
Could also be an excuse to talk a bit about planning your code with performance in mind.
@prateekgoel Let me know what you will be working on and I'll pick up (or step aside 馃槈 ) accordingly.
@Marmiz No need to step aside. You can work on this. :smile: Thanks.
Let me know in case you need any help.
@Marmiz awesome! I agree that this will be a good opportunity to share tips for planning for performance.
@prateekgoel there are a ton of other JavaScript-related concepts we need to cover, if you're interested. This README can help you get started. We could really use your help :)
Thank @QuincyLarson . I am happy to help.
@prateekgoel Awesome! Let me know if there's anything I can do to eliminate ambiguity. My goal is to help you contribute as productively as possible with your scarce time :)
The concept of using square brackets to access a value in an object is a difficult one. Other challenges using this concept also generate a lot of GitHub issues. While we're fixing this one, it might be a good idea to tackle the others as well. #12141 #14879 #11882
@Marmiz @prateekgoel Would you be interested in clearing up those issues?
@systimotic nice job finding all those issues. I think we need more challenges that give campers practice with functions before hand. Would you be interested in helping us design a few additional challenges focused on functions that also cover bracket notation? We could put these before these.
I won't be around for the next two weeks, so if anyone else is interested they can absolutely take this
I'll take it up then!
@Manish-Giri Awesome! Thanks for taking this one up! Looking forward to another one of your thoughtful pull requests :)
I'm closing this issue as stale since it hasn't been active lately. If you think this is still relevant to the newly updated platform, please explain why, then reopen it.
Just working on this exercise and all the aforementioned points completely confused me. It seems as if the copy hasn't been improved since or what's the status?
It would be great if you could add hints such as .hasOwnProperty (so simple, and yet I always forget it), difference between using square brackets over dot notation AND the hint that a return will end the function (and the loop) :)
Most helpful comment
I remember myself being stuck on it for more than I like to admit the first time I looked at it.
I think this challenge has 3 main difficulties:
no suggested method: this can easily be tackled by adding a link to
hasOwnProperty()
as @fivefishstudios suggested.using square brackets over dot notation: this may be obvious for more experienced coders, but many beginner don't realise the difference. Maybe a link to a SO post or MDN documentation explaining why you chose one over the other.
premature "no such contact" return: this is the issue I see popping out the most in chat. Almost 99% of the people who had problem with this is because they return
no such contact
straight into the loop instead of waiting to loop into the whole contact list and if no result shows up means that I can safely assume that the contact is not there.Maybe this last one is caused by how the instructions are structured:
I guess that a camper read the instruction as a "manual" (or at list that's what I did until I was more confident in my own critical thinking) as so implements the code mostly as its presented in the instructions.
Perhaps a re-wording on the instruction to help realise the loop/return order may be of a little help.