Upcoming JS3 threads 🧵 Weeks 9 - 12

[Dedekind561]

Hello folks,
Here follows a proposal for the content in the remaining weeks of JavaScript.
The topics will be similarly focused to what is on the current curriculum but with some rearrangements. Let me know what you think.

[Dedekind561]

Week 9

Learning threads 🧵

Let’s build a mental model for mapping data to the user interface
Let’s build a mental model for understanding how and why we use higher order functions

Broadly speaking, it goes data or state -> render UI

The focus of this session will be to focus on how we can map data ( stored in-memory ) to the elements that are rendered in the UI. In particular, how we can go from an array of data like an array of objects to a list of items that are rendered on the page. At first, we can introduce the idea of taking a datum ( JS object) and mapping that to an element on the UI ( using document.createElement etc ). Then we can develop this idea by introducing an array of data and thinking about how we can list them on the UI. Could show the for...of implementation . Then introduce the concept of a map as there is a one-to-one mapping between the data and the UI elements on the page.

Provisional section headings:

Data to UI, Working with a single datum, Handling multiple items of data, for.. of loop implementation, Introducing map , Call stack

[40thieves]

Firstly, sorry for being really late to the party here :/ My general thoughts are that the general concepts you've outlined here work, so if you've already made headway into writing this I think we can tweak it later.

I'd like to explicitly introduce render as the action of applying state to the DOM, as I think that's pretty standard across the industry now. I even wonder if it should go in as an explicit thread/LO, something along the lines of

Let's build a mental model for rendering data to the user interface

---

In general I like the concept of moving from a for..of loop to a map. However I think there is a tricky piece to navigate.

I'm going to assume that you'd start with something like this:

const state = ['a', 'b', 'c'];
const parent = document.querySelector('ul')

for (const letter of state) {
  const elem = document.createElement('li')
  elem.textContent = letter
  parent.append(elem)
}

The difficulty here though is that this uses a side-effect (appending the child), if we were to directly switch this to a map:

const state = ['a', 'b', 'c'];
const parent = document.querySelector('ul')

state.map((letter) => {
  const elem = document.createElement('li')
  elem.textContent = letter
  parent.append(elem)
})

then it works but it doesn't really make sense to use a map, since forEach is identical. This has always been the difficult part to teach with map: what is a side-effect and why should you avoid them when mapping.

(As a bit of an aside, I've used an analogy of a real-world physical map when introducing map, a good example is the London A-Z and the London tube map, both very different but based on the same "input data". I've just never had the time to write that up properly)

You could avoid this problem by avoiding side-effects in the for..of example, i.e. like this:

const state = ['a', 'b', 'c'];
const parent = document.querySelector('ul')

const output = []
for (const letter of state) {
  const elem = document.createElement('li')
  elem.textContent = letter
  output.push(elem)
}

parent.append(output)

However, I have a strong suspicion that trainees will ask why not just append directly in the loop, and then you're back to the same question about what is a side-effect and why it should be avoided.

[Dedekind561]

Week 10

Learning threads 🧵

Let’s build a mental model for understanding how data is transferred across the internet
Let's build a mental model for fetching data from a remote source
Let’s build a mental model for making sense of the Promise API

Broadly speaking, it goes fetch data from remote source -> store state -> render UI

After seeing how to map data (in-memory) to the UI this week we want to motivate and develop the idea of fetching data across the network. Trainees can develop their understanding of HTTP requests ( focused particularly on GET ) and then lead on to using fetch to consume resources on some remote domain. This will then lead to the idea of using the Promise API to

Provisional section headings:

How the internet works - intro to networks, HTTP etc we can reuse this content here: https://www.youtube.com/watch?v=Dxcc6ycZ73M&list=PLzdnOPI1iJNfMRZm5DDxco3UdsFegvuB7, Web APIs, Reading data from a remote Web API, Using fetch, asynchrony in JavaScript, What is a promise, Making sense of .then(), Chaining promises

[40thieves]

If we decide to reorder & split the content that's in week 11 currently, then this week does look quite crammed (which I imagine is why you structured it like this before). However as I said below, I do think that connecting the concepts of async with state updates is relatively straight-forward, so I think we could fit that into this week.

I'd also suggest that performing a state update/render in a .then() does make it more idiomatic than just logging out or updating the DOM (which I'd even go as far as suggesting that it's an anti-pattern, if we've already introduced state + render).

---

When I've taught HTTP before, the thing I've really tried to emphasise is that the internet is distributed very widely geographically, and specifically the idea that we're likely communicating with a computer literally on the other side of the world. Trainees are not used to the idea that code isn't always instantaneous, so leaning into the sheer distance has been helpful.

I have a sketch of a workshop that I've sort of run before (and I think others have run flavours of this), where the idea is to model HTTP requests by setting up two trainees as "client" and "server" on each side of the room, another trainee as a "request", who then moves from the "client" to the "server" and back to carry some data, and finally onto another trainee as the "UI" - who has to wait until the data has been transferred before they can do anything.

If I find some time then I can write that up as a workshop 🙂

[Dedekind561]

Week 11

Learning threads 🧵

Let's build a mental model for reacting to user events
Let's build a mental model for updating state and re-rendering the UI

Broadly speaking, it goes fetching data -> storing state -> user event -> update state -> re-render the UI

I think for week 11 we can tie together some of the threads from previous weeks. We could focus on updating the state and re-rendering the UI: this will allow us to bring together events, handling state and mapping data to the UI.

Provisional section headings:

Problem: reacting to user adding [search input], Break down the problem, Capturing the user event, Updating state, Re-rendering the UI

[40thieves]

I think I agree with @illicitonion's point below, I think we should swap (parts of) this week with week 10.

I think there's several lessons to learn from the React module here. Firstly, we might want to recap the concept of reacting to events - basically touching on event listeners again. I've found that this often needs a refresh in the React module (although it is possible that it'll be fresher in their heads at this point)

I would also point out that technically event handlers are higher order functions too. I find that we tend not to think of them this way though. I only really raise this since in week 9 one of the threads is higher order functions.

But I will also add that the concept of event handlers as higher order function is a really important in React since we often pass functions as props, so I would definitely lean towards keeping that section in the React module because it's such a stumbling block for trainees.

---

The other lesson from the React module is that we teach state updates before introducing data fetching. I've found that this is a simpler model to start with, for a few reasons:

• It's easier to directly connect the concept of user input with state updates. You can more easily demonstrate the UI getting "out-of-sync" with the user actions by adding a button but not connecting it to a state update
• You don't need to deal with asynchrony, which I think is a significant mental hurdle for trainees to get over. Generally I've found once they understand async and state updates independently, joining them together is not too much of a stretch

So I'd propose moving the state update part of this content into week 10, possibly with a recap on event listeners.

[SallyMcGrath]

We can move this around for sure, but for NOW I've done this one here #401

[Dedekind561]

Week 12

I think we should use this week for trainees to do a hackathon / project making use of their knowledge of DOM, and fetch etc.

[40thieves]

If there's no space in week 11, I think we could spill over the concept of data fetch -> state update -> render into here. However I do like the clean cutoff into a project 👍🏻

[illicitonion]

I think these generally look really solid!

I'm curious how far down the "state -> render" road you're thinking of going. Right now in JS3 we don't teach the idea of state (or rendering based on state) at all, we just show how to imperatively create elements, and that sometimes we need to delete some elements.

I would love it if when we got to React, the idea of state + render was already in people's minds, and they could see more obviously "React is just a way of simplifying and adding supporting structure to what we're already doing".

But I'm worried that each of the weeks we have already has way too many new concepts to be able to cover this.

I wonder if we could steal a week from React? If we add a week 13 (or week 12 and move week 12 to 13) where we just focus on the state -> render pattern, maybe it simplifies what we need to teach in React a bit (and also will help deeper understanding when it's introduced)?

[40thieves]

the idea of state + render was already in people's minds, and they could see more obviously "React is just a way of simplifying and adding supporting structure to what we're already doing".

I think we discussed this in a team meeting - I agree with this idea, and generally that's how I've framed introduced why React is helpful, although obviously more implicitly since we haven't had the concept of state + render in JS3 previously.

Another point in it's favour is that state + render is a more generalised frontend concept, in that essentially all JS frameworks rely on this now. So I think it opens the door for trainees to look at other frameworks, or even vanilla web components, not locking us into React (although I still think we should explicitly teach React for employability reasons).

---

It does obviously raise the question of how should the React module change in response to this and whether we can fit in some extra stuff because - but I think that's a discussion for another time.

[illicitonion]

I would consider swapping weeks 10 and 11.

This is realistically our first introduction to callbacks and asynchrony, and "I clicked and something happened" has many fewer new moving parts than "I did something called fetch and at some later point something maybe happened or maybe there was an error or maybe I didn't wire up my promises correctly and nothing happened"...

[SallyMcGrath]

Now we have drafts of 10 and 11 I agree. And I see there are upvotes too.

Shall I switch them? #403 #401 . I'm proposing to deploy a first version of JS3 tonight so this question is pressing.

[SallyMcGrath]

#405