Upcoming JS curriculum threads 🧵 Weeks 5 - 8

[Dedekind561]

⚠️ FYI: Already posted this info in Slack but should have really put this here first and then linked to it - apologies!

Hello folks,
Following the most recent curriculum meeting I’ve come up with the high-level ordering of threads ( and some rough headings too ) to give an idea of the proposed road ahead.
I definitely agree that we need to bring “JS in the browser” content forwards as early as possible: however, after reflection, I do think we need to bring in iteration before “JS in the browser” for some reasons that I’ll sketch out here briefly. The problem can be summed up thus: now we’re threading concepts together it means we can end up with entanglement, i.e. it can become more challenging to separate content out into distinct standalone modules. There was a feeling that iteration should be interlinked with “JS in the browser” where it can be better contextualised ( which makes sense ). But if iteration is included then it makes iteration ( a fundamental concept ) tied up with the “JS in the browser” section of the course and thus more difficult to extract. In the rewrite, I feel like the first 6 weeks of JS are now becoming more akin to programming fundamentals ( in JS ) and so it feels increasingly like it ought to be a standalone module. Ideally, I would prefer iteration to be part of this module and not have its introduction tied into the “JS in the browser” so we have more flexibility later on. ( Of course, the iteration thread would definitely be continued in the “JS in the browser” section of the course a few weeks later so I don’t think this is a massive deal. )
Other reasons for introducing iteration in week 5:

• I definitely think ordered lists should be the next main thread in week 5 and given an ordered collection then repeating some task on the list is a very natural thing to introduce alongside this topic
• We can still introduce a useful application for iteration ( e.g. computing a sum, extracting certain elements etc ) at this stage

If we started with the browser runtime from the very beginning of the JS module then I think it would be easier to introduce iteration + DOM side effect but I think that’s out of scope for now. Although I do think it would be easier to re-structure it this way if we wanted to in the future. Sorry for this rambling explanation.

[Dedekind561]

Week 5

Learning threads 🧵

Let’s build a mental model for grouping and acting upon related data
Let’s build a mental model for managing ordered lists
Let's build a mental model to understand how to repeat an action

Provisional section headings:

Related pieces of data - limitations of many variables - grouping data - strings as ordered lists of characters - indexing - limitations of strings - ordered lists of other types - list mutation - computing values from lists - need for iteration - mechanics of for loop - “playing computer” through a loop

[illicitonion]

How many of while loops, for loops, for-of loops are we going to consider?

I'd maybe suggest we just start off with for-of loops, and worry about for loops when we have a more motivating use-case for them (e.g. wanting to know the index of the element during iteration, or mutating the list during iteration)?

I know in the past we've tried to go while -> for because that introduces concepts one at a time, and tries to explain why for loops take the initializer/limit/iteration syntax that they do, but honestly it feels like for-of should cover most of what our trainees actually need to do for quite a while...

---

Unrelated: Are you thinking of going through array methods here at all? Or just indexing and for-ing over?

[Dedekind561]

I completely agree - just keeping it to for...of covers pretty much everything they need at this stage. As you said, we can introduce other patterns as and when required.

---

However at some point ( not in this week ) we may need to think about cases of iteration where it doesn't involve progressing through a collection in a linear fashion. They may end up with a sense that iteration is only this thing that takes place in a linear, moving-up-a-list fashion. We just need to ensure we've got enough problems that involve iteration in a non-linear non-array-based context ( I'm sure there are some of these on Code Wars already ). I'm thinking of more involved problems where the iteration might mean jumping around a list or a loop that runs based on a condition unrelated to an incrementing value. But we don't need to worry about it too much at this stage.

[Dedekind561]

Week 6

Learning threads 🧵

Let's build a mental model to understand how to key a value
Let’s build a mental model for grouping and acting upon limited data
Let's build a mental model about actions having side effects
( particularly mutation )

Provisional section headings:

Limitations of ordered lists - key-value pairs - value vs reference - mutating objects - side effect functions - nested structures - iterating lists and key value pairs - ??

[Dedekind561]

I was thinking of a situation ( like tv show project for example) where you might have an array/object in an outer scope and then a function that takes a reference to this array/object and then calls sort or some other mutating method.
I'm thinking of functions like this: mutating function in tv show project

[Dedekind561]

And using this as a more friendly way into the notion that functions effect stuff outside their scope and sometimes this is necessary

[Dedekind561]

And also a very bad thing in many cases 😂

[illicitonion]

Aha, yeah, we should 100% introduce the mutating vs pure thing in week 5 about arrays, and reinforce it in week 6 in maps.

(And we will all continue to be frustrated that while in other languages, and for most array methods in JS, they either mutate and return void or don't mutate and return a new collection, except Array.sort in JS does both because why not).

[carl0FF]

javascript, yay!

Jokes aside, value vs reference is a concept I find very hard to explain myself to trainees (I'm not even sure I've ever been able to make anyone truly understand it), so I'm very interested to see how it's laid out 👍

[Dedekind561]

Week 7

Learning threads 🧵

Let’s build a mental model for understanding different execution environments
Let’s build a mental model for programmatically modifying an HTML page
Let's build a mental model to understand how elements appear on a web page and how these elements can change based on user interaction
Let's build a mental model to understand how we can inspect and manipulate a web page ( programmatically and otherwise )

Provisional section headings:

Interacting with web page - inspecting elements on the page - Document Object Model - Interacting with DOM elements in dev tool - linking scripts to HTML page - locally hosted web page - Using the DOM API - global objects ( window ) - looking for elements using selectors, tree structures - DOM traversal - checking the page

( this week contains content very similar to week 7 in the current syllabus! - but with more emphasis on the interface and using DevTools as another interface too )

[illicitonion]

Follow-up from syllabus team meeting: Making sure we build into the execution environments thread that something (a runtime, whether we call it that or not) decides to call our code, and that sometimes it gives us control, and sometimes it keeps control. Our file gets run in the first place because it chooses to call it, and it may choose to call our code (e.g. an onClick handler, a setTimeout, etc) independent of our control.

[Dedekind561]

Week 8

Learning threads 🧵

Let's build a mental model around giving the computer code to run at a later time (e.g. onClick handlers)
Let's build a mental model to understand how elements appear on a web page and how these elements can change based on user interaction
Let’s build a mental model to understand asynchronicity

Context

This week we should pay particular attention to introducing the idea of passing functionality to other functions and asynchronicity. We should focus on event handlers at this stage - we can have a nice intuitive example of some user interaction firing event that leads to a handler being invoked. This is the entry point into higher-order functions and asynchronicity.

[Dedekind561]

Ideally I think it would be good to introduce them side by side too so they notice those similarities. My only reservation stems from the fact that fetch returns a Promise. Provided we use a simple fetch example and we're happy to hand wave the .then() part, then we could introduce them side by side but with the main focus on the onClick, perhaps? We could then say that we'll return to explore the fetch API in more detail in later weeks.

But we could definitely have 2 framing examples in the beginning, something like this:

Scenario 1

fetch("some URL")
.then(function () {
})

Scenario 2

button.addEventListener('click',function () {
})

We can invite people to reflect on when these functions are called ( and "who" calls them ). This is probably how I would start the notes for this week.
Then we can segue into the click event example in more depth.
Or do you think we should cover both of these scenarios in depth in the same week?

[illicitonion]

In general I think we're aligned, and I don't think we should cover fetch in much depth, just to show a parallel of callbacks and asynchrony and follow up later on.

That said, finding a way to bring in "here's a motivating example for all this objects/maps stuff" ("This data we just fetched from an API needs to be structured somehow, look how objects are really useful for that structure") early would be really useful :) I know in the current curriculum there's some examples of grouping e.g. records of books, but taking that further would be great. For some reason Event doesn't seem to show this very well (probably because our trainees realistically only ever look at ~two properties from an event in the first place, so don't really see data being grouped together very usefully)

[illicitonion]

(And in particular, if we do talk about fetch here, I don't think we should talk about errors / potential for failure at all - that's a concern for "focus on fetch" / "focus on errors", and not "introduce the idea of callbacks" :))

[carl0FF]

I'd say introducing fetch here would do more harm than good :) I find writing code to react to UI events a very simple way to introduce async programming, in the sense that trainees start using the async paradigm without even knowing it. My suggestion would be to use event handlers to set a solid mental model of asynchronous programming, so that it can be revisited later on when fetch is introduced. I'd say that's the point where we can establish the parallelism between fetch and event handlers as you were suggesting above. Probably we want to be careful with the terms we use here so that we can reuse them when introducing fetch and promises.

[illicitonion]

I think I'm won over to deferring fetch to a later week - onClick, Array.map, and Array.find probably supply enough parallels at this point :)