Start teaching the abstract concept of state earlier in the course

[illicitonion]

Right now we teach both the idea of state, and React's handling of state, all together in the React module.

This has a few issues:

1. It adds to cognitive load of the React module
2. It means our trainees often struggle to consider the idea of state outside of React (e.g. in an interview question context)
3. It makes it harder to understand what React is doing and how to use it - because e.g. in the TV project they haven't encountered the concept of state, it's harder for them to decompose how to work in React into state/state-transitions/rendering-given-state.

We should work out where we can earlier introduce the concept of state, and do so.

[SallyMcGrath]

I was JUST thinking this. I wondered whether we could go super basic in HTML with just introducing the word eg https://github.com/CodeYourFuture/syllabus/projects/3#card-67657614

And then return to it with... I guess maybe console.log (eg log the present state) in JS1, just give some more language around that

And then again in JS2 once we start manipulating the DOM we could really start fleshing out the concept, perhaps link out to some stuff like https://gomakethings.com/state-based-ui-with-vanilla-js/ https://gomakethings.com/refactoring-a-vanilla-js-app-with-state-based-ui/ ? As a start?

[SallyMcGrath]

....That video is tedious as anything though, so probably not that, just something LIKE that, the refactoring part is what I'm thinking of. But not that. Sheesh!

[illicitonion]

I like it, and I really like the idea of having traffic lights or something similar as one consistent example we use as our state example. Maybe we could do something like:

HTML/CSS: Hover-based traffic lights, or similar. (State can be changed by interaction). JS2W2: Make a traffic light using the DOM which has a button you can press to change it. (State is something you can save after an interaction). JS2W3: Have pressing a button start a count-down to when the traffic light will change. (State is something we can change in the background). React: Model the traffic light as a component (really easy to model current-colour as state, and define a render function accordingly), the counter for when the light will change as state (which we can useEffect, or whatever the weird React timer hack is, to change)

[SallyMcGrath]

Oh I like this a lot! I might just build the traffic lights in html/css now - won't take a moment

[40thieves]

This is great, we do tend to blow through the high level explanation of state in the React module because we're short on time anyway. So front-loading this would be really helpful.

👍🏻 from me on the traffic lights.

Make a traffic light using the DOM which has a button you can press to change it. (State is something you can save after an interaction).

I assume this would be implemented using rendering-given-state paradigm? I.e. clicking the button doesn't just manipulate the DOM to whatever the opposite is, there would be a variable modelling the current colour, from which rendering is derived.

the weird React timer hack is, to change

Yes unfortunately I tend to stay away from timers in React because the relevant APIs are fairly mismatched (see this great, but very long article. This also makes explaining why timers are weird in React quite difficult.

There's a couple of workarounds: a) we ignore the edge cases when using plain setTimeout. In fairly simple components, you don't tend to see the problems; or b) we install a specialised useTimeout hook from NPM and handwave over why this is necessary.

[SallyMcGrath]

Just putting this doodle from our meeting the other week here so I don't lose it https://codepen.io/sallymcgrath/pen/JjJXZZe