Introduce modularity via components in JS apps

[dearshrewdwit]

Lewis wrote a good exemplar for students: https://github.com/boolean-uk/js-dom-greengrocers-examplar/blob/lewis/index.js

The problem here is it contradicts some of the ideas they're starting to understand about cohesion and responsibility -> It seems as if this approach continues up until React. I want to introduce modularity by encapsulating 'component' behaviour using ES6 modules, laying on top of their understanding of encapsulation using classes.

Here's a test branch to inspect: https://github.com/boolean-uk/js-dom-pokemon-crud/tree/test-components/

Goals

• Reinforce modularity as a fundamental concept throughout the course (currently long, messy JS files)
• Reinforce development process to include planning, and refactoring (what components will we need?)
• Smoother sequence from vanilla JS to react
  • (why, what components?)
• Introduce concept of app runner, remove starting HTML, rely more on insertion into DOM

Schedule

• Pilot: 1-2 days of content at the end of JS DOM before React.
• intended: move to this approach for after brewery tours Challenge (?)

Anchor skills

• ES6 (modules, async/await)
• global state

Possible skills

• immutable state
• props v state

Tradeoffs

• global v local state
• different (additional) state pattern: no 'render' method, instead removes and redraws entire component with new state

[mikemherron]

My initial reaction is again this. I think the point we introduce React is a natrual inflection point towards components and timing works well. I see the current JS DOM work as similar to JS Fundamentals - it's laying the foundational understanding of core technology concepts rather than "how do we do this well". We could talk about a cleaner more modular approach by writing our own component framework, but in reality isn't that one of the problem that React solves? I think we can achive the same LO's using React rather than showing them a DIY approach that is unlikely to be used anywhere in industry. We can frame React as "isn't all that DOM code messy, what happened to encapsulation -> here's a solution to that". In a similar way, we don't create our own web framework on the server, we just use express. It's going to be more time to create, test and refine this content that could be better spent elsewhere.

[vherus]

I see Mike's point but my worry with lumping encapsulation in with React is that students will associate it with React forever more. A similar situation happened with C1/2 and the fetch function vs HTTP requests.

I see a lot of value in...

"isn't all that DOM code messy, what happened to encapsulation -> here's a solution to that"

...but I don't think the solution should be React - it should be applying encapsulation in vanilla JS to understand the concepts and build it as a transferrable skill. Then we can say "Now we've organised our code and its easier to maintain, look at all these horrible DOM manipulations that we still have -> here's a solution to that: React".

[Auenc]

So I think my biggest issue is how the students will try and re-render the app when changes to state happen. In the example provided, it does this somewhat interestingly. When live-server doesn't refresh the page (Thanks @mikemherron for the comment about that in the delivery log. It was driving me insane trying to figure out why the page was reloading) - we actually change the whole layout of the page.

On initial load, the DOM looks like this:

<div class="app">
   <h2>PokeCRUD</h2>
   <form class="poke-form">...</form>
   <ul class="poke-list">
      ...
   </ul>
</div>

However, when we add a pokemon, we re-order the DOM elements.

<div class="app">
   <h2>PokeCRUD</h2>
   <form class="poke-form">
     ... form inputs...
   <ul class="poke-list">
      ...
   </ul>
   </form>
</div>

I'm assuming this is done because we have no reference to the pokemon-list component inside form component. I think this would be confusing for students to see, and even more so to reason. It would be better if the pokemon-list was always a child of the pokemon-form, however, I would argue that it would be an odd place for the pokemon-list to live in a normal app.

I think the better approach would be for the form to bubble up an event / use a callback function to get the main app to rerender the list. However, I think that would be potentially confusing for students as they haven't seen callbacks yet.

This is why I worry about introducing components without introducing a framework to help with the rendering of components when state changes. At best, we will introduce an odd way of doing things that will be forgotten when we get to react. At worst it'll be confusing to try and teach, especially considering it won't be the easiest thing to google/research as it's somewhat bespoke, and potentially confuse even more when it comes to learning react's way of doing state changes.

I think it's a good idea to try and work towards a modular component architexture, and it would be beneficial to ease students into the react module. I just think it needs to be quite structured and well thought out in how we do it. If we can find some common practices doing this in vanilla js, that would be ideal, so we can provide resources to read over as well as it would mean students are able to google if they want to try and unblock themselves..

[dearshrewdwit]

@mikemherron I hear you - some good points to think about. Here are some of my thoughts.

I think the point we introduce React is a natrual inflection point towards components and timing works well.

I'm not sure this is true. What evidence do you have/thinking about for this? Showing a better approach is definitely by this point needed, I agree!

in reality isn't that one of the problem that React solves

It can do, but it's not a primary problem for React- we can solve that without React. React solves the problems of

• repetitive boiler plate code for DOM manipulation
• a cleaner more standardised API to follow when building and reasoning about front end apps (esp useful for beginners, though not nearly restrictive enough for them...)

rather than showing them a DIY approach that is unlikely to be used anywhere in industry.

Two curriculum values I think about: fundamental principles, job-skills focused.

There's a tension here- does work on fundamental principles get students quicker jobs than only job-skills (aka why not spend the entire course on UIs and functional React?). This is to say DIY approach is valuable if we're highlighting fundamental principles, but it's not valuable if it's too contrived/veers away from fundamental principles

"potentially confuse even more when it comes to learning react's way of doing state changes."

Agreed. Is this tradeoff useful? It's potential closer to a global state store which might be an interesting approach, but clashes with the beginning of react is all local state within components.

FYI the whole course follows the pattern of sequencing important anchor skills to reduce cognitive load at one time -> spreading them out. The question is how well does it do this at times?

Some specific approaches that are more "DIY"

• using the nodejs postgres adapter directly to query the DB, before moving onto using Prisma to handle this.
• manual rather than automated deployments

Sequencing is important. Sequencing is the idea of identifying the necessary skills for a student to learn to be successful for objective ABC. And then chunking the identified skills and sequencing the chunks rather than doing them all at the same time.

The question really I'm trying to get information about -> what's the ideal tradeoff between smooth sequence of skills and context-switching for the front end module?

Can we introduce modules and components, without the complexity of react and its build tools?

we don't create our own web framework on the server, we just use express

have I shown you my plans for this... 😂

It's going to be more time to create, test and refine this content that could be better spent elsewhere.

This is a valid point - something always on my mind. The discussion/review process helps me get information to prioritise work

[dearshrewdwit]

@Auenc Agreed - those two points re: state management and re-rendering need some thinking. I'll have some time on Friday to have a look again at the render process. Partly might just be my messy work 😂

They will have experienced callbacks - so there might be a possibility.

The availability of resources for students is also a great point.

Remember, the intention is that this would be a stepping stone, not an approach we ask them to spend a lot of time doing - two days probably.