React week 2 in-class exercises

[LucyMac]

What does this change?

Module: React Week(s): 2

Description

• I took the liberty of swapping out IDs for classes to avoid any confusion and limit CSS bad practices (the IDs weren’t being used for anything other than giving a friendly name to buttons)
• I updated the code for the Martian photo example, and created a sandbox for it. @40thieves you might want to copy that to live in the same domain as the other sandboxes? https://codesandbox.io/s/the-useeffect-hook-jtz5u?file=/src/MartianPhotoFetcher.js
• I changed the pokemon state variable name to be called bestPokemon instead, so we avoid the pattern pokemon={pokemon} which I find causes confusion as to which is which. Speaking of which, I'm thinking we could do without the 'hint' in the final exercise which spells out how to pass the pokemon state down as a pokemon prop. I haven't made this change, it's just a suggestion, but I feel like it spoon-feeds it all a bit.
• The final exercise with the pokemon data fetch feels unfinished. Should we add an instruction to pass down the pokemon from the API response and change the image + also the abilities? We can leave it quite vague and see what they come up with, but I feel we should explicitly say what bits of data they should be using at least.
• Removed a reference to class components down the bottom.

[40thieves]

I'm thinking we could do without the 'hint' in the final exercise which spells out how to pass the pokemon state down as a pokemon prop. I haven't made this change, it's just a suggestion, but I feel like it spoon-feeds it all a bit.

This is always a tricky balance. My experience is that stronger students don't really read the hints so aren't bothered by them. But weaker students need more hand holding (even if they refer to the example code we've just gone through).

I'd propose we keep spoon-feeding and see how it goes? EDIT: another alternative could be to put more things in <details> blocks as this hides them by default: stronger students shouldn't need to reveal them.

If we do keep it, would you be against breaking up the state exercise a bit into smaller steps.

[40thieves]

you might want to copy that to live in the same domain as the other sandboxes?

I can fork it and move it myself but that would require changing the URL. I believe you should be able to do it yourself. If you go to the dashboard, then you should see you're part of the CYF "team".

You can then drag the sandbox from "My Sandboxes" into this folder:

This gives everyone on the CYF team edit permissions (and saves lots of URL updates).

[40thieves]

The final exercise with the pokemon data fetch feels unfinished. Should we add an instruction to pass down the pokemon from the API response and change the image + also the abilities? We can leave it quite vague and see what they come up with, but I feel we should explicitly say what bits of data they should be using at least.

Hmm yes, that is perhaps in conflict with my "break every step down" philosophy. I would be in favour of adding a hint to say exactly what to pass (perhaps could "hide" it using the <details> trick?)

[40thieves]

Looking through it, I'm not sure where we could add more, but it feels like only 4 exercises during the day is not enough?

As noted in this thread: https://github.com/CodeYourFuture/syllabus/pull/448#discussion_r429762378, I removed the content about destructuring arrays (and just linked to a blog post). We could do a quick exercise on it (maybe just in CodeSandbox/JSBin/where-ever)?

@nbogie I think suggested something about not mutating state? Idk though, after that section feels like the natural place for the first state exercise.

Perhaps "when to use props or state" too? Although to me this section also doesn't feel "important" enough to merit exercise time.

[LucyMac]

In haste, it's late 💤 I've split exercises and added some more, plus clarified some instructions. I've also added a section on conditionals + a blurb on the useState setter function naming convention.

@40thieves / @nbogie / @mozartdiniz