Skip to content
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
110 changes: 110 additions & 0 deletions contributing/proposals/react-restructure.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,110 @@
# 📘 React & Next.js Module Restructuring Plan Proposal

## 🎯 Goal

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall very nice proposal. You present the idea very clearly and I think it all looks good. ⭐ Also great overview with the diagrams.


The purpose of this restructuring is to enhance trainees' learning experience by clearly distinguishing foundational React concepts from the advanced features provided by Next.js. The current structure mixes fundamental and framework-specific topics, which has caused confusion and hindered deeper understanding. By separating these topics into two distinct, focused modules—one dedicated to mastering core React concepts and another specifically for exploring Next.js—we aim to improve comprehension, reinforce skills through targeted exercises, and ultimately empower trainees to confidently build real-world applications using modern development practices.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find the analysis of the issues of the Next.js version of the curriculum very concise. It is a mix of framework-specific and React-related topics. And the level of difficulty is very mixed as well, making it hard to follow and teach.


The only thing I will mention positively from using Next.js is the file-based router ✅ . It took 20 minutes to explain this to trainees (and they didn't notice how this works before explicit explanation), but once they understood that it's just like when they were writing html files and you could find them by their name when serving a directory, it clicked for them (path variables were another story, though).

The decoupling of routing and files can be very hard to understand for a beginner. And typos, routing priority, wildcards etc. do not make this any easier.

That being said, I'm not aware of any React Router-ish modules that could do something similar (translate a folder structure to a router setup), which would give us the benefit without needing to introduce Next.js and all of its intricacies?


A thing to keep in mind is that – at least in Aarhus – we've been using Next.js for the final project to simplify setup 🏁. I'm not sure if it actually accomplishes that goal. I do know that trainees were very frustrated when we didn't use Next.js, but express and React, and they didn't know why the backend was started on port x and frontend on port y etc. With Next.js we didn't have these problems, but other problems, like the two different file-based routing models Next.js has and how Lambda functions work for API calls etc. So, there's that...

Update: So, I read the whole proposal now, and Next.js is in the end. See my comment there 👇

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is actually some examples of file-based routers in https://github.com/vitejs/awesome-vite 🤔 We can think of using those, but this is up to a discussion, I think


---

## ORIGINAL MODULE STRUCTURE

![draw io 2025-05-10 15 15 20](https://github.com/user-attachments/assets/1129af41-d894-422a-8b56-b7ef8fd42d07)
![draw io 2025-05-10 15 15 30](https://github.com/user-attachments/assets/b3cee13d-472e-4e47-ac66-689b3b840ee1)

## 🧱 PROPOSED MODULE STRUCTURE

### React Module (4 Weeks)

**Description:**
Covers everything essential about React and building React applications, including component lifecycle, state management, and routing. After completion, trainees should be able to create simple applications and websites using React

**Teaching Methodology:**

- **Flipped classroom:** With preparation materials, class sessions are dedicated to solving problems and practical implementation rather than theoretical explanations. \[From my experience, this amount of matherial might become 4-hours-lecture instead of 4-hours-practice]
- **Preparation Materials:** Improve beyond React documentation for effective flipped classroom learning.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What kind of material are you referring to here? videos, blogs etc. any specific links you have in mind?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one is "to be researched", to be honest.
I don't know much resources besides official documentation (I rarely use something besides official documentation in general), but I know that people learn different ways, and maybe have video/blog/etc explaining React basics could benefit for a lot for trainees

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From my experience, this amount of matherial might become 4-hours-lecture instead of 4-hours-practice

I agree! Hence, the "main" topic for each week (see my comment further down 👇) — but yes, finding preparation material is a challenge.

Improve beyond React documentation

I do find https://react.dev very good, though. I have used exercises from the site in Sunday sessions, as they can be solved inline and come with a "reveal solution" button. However, for more visual learners a video or two for each week would be great. Maybe it could be a compilation of YouTube tutorials that reach the bar of being up-to-date, easy to understand and therefore good for preparation?


**Technical Recommendations:**

- Use Vite or similar library for a client-only React setup to simplify configuration and focus more on React itself.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I very much like us to use Vite

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that's a good take. Even in the very last session of React 2 we always had to write "use client" in page files, as SSR in Next.js is challenging at best, and does not use the concepts we teach (e.g. hooks).

I don't like to rely on client-side only, but I find that the ecosystem is still stuck there. SSR is still not a first-class citizen and therefore teaching React client-side seems like a good place to start and absolutely in-line with teaching job-landing skills.


**Homework Strategy:**

- "Meal Sharing" project can be integrated progressively during the course, rather than post-module only.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that it makes sense to integrate the meal sharing app with this module. Maybe the homework could be related to the meal sharing.
I had the initial idea with React that:

  • Week 1 - make a very simple static page from a few components. Could be an "about" page.
  • Week 2 - make a more complex static page where some components are reusable. I.e. a landing page with a more advanced layout of content etc.
    • For the sake of making the exercises more engaging maybe we should introduce just a button onclick so the trainees can see things happen and see React "Reacting".
  • Week 3 - Add more complex interactivety to the page, form inputs, loading wheel and api integration. i.e. the main feature page
  • Week 4 - Tie it all together, add routing and make it "shine" (or put out burning fires from previous weeks).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is similar to the way it works today. Some of the assignments are related to Meal Sharing. One issue I found as the mentor, is the disconnect between lesson plan / exercises and Meal Sharing. I have no overview of when trainees are working on what and am entirely unprepared when they ask some Meal Sharing related question in or after the sessions. I don't have a good solution to fixing this (as I could probably invest the time to follow the Meal Sharing project, which would improve the situation), but it comes up every time I teach React. 😭


![draw io 2025-05-10 15 15 50](https://github.com/user-attachments/assets/8c98a4ae-aeed-41d1-afc2-33667ff6bd44)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Week 4 diagram has reducers twice

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think state management libraries falls in the same category as Reducers. I don't think it is required to land your first job and it is quite hard to teach why all the added overhead of the library is good to the trainees who has never seen a large project before. I would rather focus on:

  • Context
  • Routing
  • Icon libraries
  • (optionally, component libraries if time allows)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I agree. Under "state management libraries" I meant only mentioning that Context is not the only way to solve the problem and maybe drop a couple of names they might hear here and there. They'll research if they are interested. The same approach I suggest to "component libraries"

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I previously mentioned SWR for data fetching and state management, but trainees mostly didn't get why I would introduce it and got confused.

They see useEffect + useState online and it mostly works, so that's what I show now. (Even though, following the React team, we're supposed to move away from using useEffect for anything other than syncing with external systems ... 😬)

I'm still waiting for useFetch natively in React 🙏

(And really, this is the only "state management" most applications really need – fetching and caching data from the source of truth, which most often is a JSON API. All other state can be managed within useState of pages, components, and context, if needed)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To the drawing:

  • What do you mean by "Use {} in JSX"?
  • What do you have in mind for "Sharing state"?

In general, I feel like there is too much "main" content in every week. I'd take one or two main topics for the week and then do some asides to cover necessary tangents.

In my experience it's very overwhelming when we present a long list of topics for a day. When presented with "Today we're going to learn about "State"", trainees seem more engaged, as they don't have to keep a laundrylist of topics in mind, but instead we naturally land onto things like "fetching from an API into the state". Those would be "sub-topcis" in my opinion.

But branding the day with one or two overarching learning goal(s) seems like a good strategy in my experience. You've kinda done this in Week 2.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is the same staff we have in the plan right now: "Use {} in JSX" is Embedding Expressions in JSX, "Sharing state" is about props drilling.

I agree that it is overwhelming, but I don't see how we can structure differently without drastically removing content 🤔 If you have something in mind, that would be amazing


#### Weekly Goals and Topics

**Week 1:** Everything about rendering a single component.

- React Introduction
- JSX fundamentals
- Components, props, CSS imports

**Week 2:** Master state management (passing, storing, updating state).

- useState Hook
- Conditional rendering, dynamic rendering

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we could add "render Props" and JSX props? I find they can make a beginner happy, when they first understand that they can pass JSX or a function returning JSX as a prop down the tree. It's just very powerful and you can do creative stuff with it, once you understand it. But maybe too advanced as well?


**Week 3:** Component lifecycle, data management (events, API), and refs.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would consider if refs are required. I am not experienced in it but it seems more of an advanced feature only needed in edge cases.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is so React-specific thing, that it worths at least mentioning.
Also it kind of builds the bridge between what they know about browser and what React does. Last time I explained it like "constant that saved between renderings without causing updates" :D Didn't have much questions about it

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I introduced refs in React 2 and it was not very successful. Trainees did not see the point of using Refs. In my opinion, Refs are something you learn when you have a need for them. It's a very specific feature of React and not standard knowledge. I'd vote to remove them from the curriculum.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I, actually, showed a couple of examples from my real repo at work, and it felt like it had more sence for them after that (there was work with timers, when you store result to be able to cancel them without component update)


- Event handlers, form management
- useEffect Hook
- API integration

**Week 4:** Context, Routing, Libraries, handling real-world cases.

- React Context
- (Optional): Reducers (I haven’t seen it used in production a lot), advanced state management

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Re. Week 4

Yes 💯 to your comments! I'd personally make the case for dropping Reducers and UI libraries.

Context would be my main topic of choice for that week.

Reducers

  • They introduce complexity that only pays off in rare use-cases
  • They include a lot of boilerplate (even with the newer, more lightweight libraries)
  • You have to buy into the reducer pattern in the first place. I don't think it is a good way to handle state or data flow. (Instead abstraction should be reduced, pun intended, and you should update your state consistently using functions, and share state using prop-drilling, a cache or React Context.) … just my 5 🪙
  • As you may assume, I avoid them, so it's very hard to explain and demo how to use them and what they even are good for

UI libraries

  • Yes, they are being used in some workplaces
  • Yes, they make it easier for the trainees to make their fist React apps and reach their goals
  • It's hard for me to showcase them, as I'm not familiar with most UI libraries
  • I feel like you can spend your entire career becoming an expert in UI library "X"
  • Trainees can easily explore them outside of Sunday sessions, on their own time
  • I would mention they exist (and highlight npmjs.com as well, if they are not too familiar with the module ecosystem), but not more. No crazy long exercises implementing themes and translation in Material UI 😬

- Component libraries (UI libraries)
-  Routing

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How would you approach Routing, now that we're not using Next.js? Plain React Router setup, following their "Getting Started"?

- Introduction to easy deployment (Vercel)
Comment on lines +57 to +61

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am leaning towards not teaching Reducers. I don't think a new joiner would be expected to know that and it is hard to really teach them why using such a pattern is good if they haven't worked with a large app.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How much effort is required to deploy to the cloud somewhere? If possible, I would love to move this to week 1 to really hammer it in early.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It takes a couple of clicks in Vercel + can be integrated with PRs without additional settings (so we have "free" deployment for every homework for both modules, yay)

And Vercel is developing Next.js, so it is definitely go-to instrument for easily deploying it

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe that for free deploys repositories need to be public, but otherwise, yes, we should demo this. It's like magic and a moment of success for everyone, to have a "hello world" up and running.


---

### Next.js Module (1 Week)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very nice proposal. I agree with the topics.

Can we design a mini project for this module which highlights the benefits of Server side rendering or static site generation?

@te-online te-online May 27, 2025

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes! I like this section a lot. Next.js should be the cherry on top 🍒, not a thick and chewy bottom layer 🍰

Some thoughts:

  • SSR & SSG — It was very hard for me to explain these concepts as they require some knowledge on the part of the trainees about how a browser works, how servers work, the history of the internet, SPAs, SEO, 100 more abbreviations and such. It's a bit of a mouthful to explain this all in one go.
  • That being said, I think they got the gist of "you can pre-render your website and get HTML" and "you can have a server render your website on every request". But that is the (surface) level at which we stopped, basically.
  • Now, using these techniques in Next.js is a whole other beast. Since they don't use the same mechanisms (especially hooks), it's like a whole new world to start in.
  • Additionally, things like getServerSideProps are just no fun when using plain JavaScript, so that's very hard to visualize how the data flows when Next.js renders the page on the server
  • Making an app with SSR require quite some planning, e.g.
    • Which data do I want to be there on first load?
    • Do I want interactivity on the client-side? How do I combine this with SSR?
    • Is my data accessible on the server?
    • What features of Next.js in the realm of SSR and SSG do I want to use? How do I opt-in to those? How do I configure them properly?
  • This is basically a master class, in my opinion 🤷

Just look at this bullet from the app router -> pages router migration guide 🤯
image

Only saying getServerSideProps, getStaticProps, getStaticPaths and generateStaticParams without mixing them up takes me five minutes, and I haven't yet explained what they do, or what the new APIs do they have been replaced with and, how these APIs work and what fantastic names they have...


  • Next.js App Router — we need to make sure to communicate what approach we're using and what the difference between the app router / pages router models is (what is the difference?!). The Next.js docs can still switch between the two approaches they have, and you can land on a page through a search engine that is for the wrong mode. I haven't been using Next.js at work since this was introduced, so I was completely lost the first time and am almost completely lost still 😬 (might be a me problem, though)
  • API Routes can be nice to show, because this is quite transferable to how Lambdas etc. at many Cloud Providers work as well
  • I love Server Actions, because they tie back neatly to how <form> from HTML + CSS works, but they seem more like master class material to me too … 🥮

@markitosha markitosha May 28, 2025

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how a browser works, how servers work, the history of the internet, SPAs, SEO, 100 more abbreviations and such

I've tried to explain all of that last time I taught React 2, I lost trainees in about 15 minutes 😆

app router / pages router models is (what is the difference?!)

I don't need we need to tech pages router, it is kind of deprecated at this point.

I love Server Actions, because they tie back neatly to how <form> from HTML + CSS works, but they seem more like master class material to me too …

It is nearly impossible to create a real application without using Server Actions, I'm afraid. As soon as you have to update any data -- you either have to use hooks and do the old client way, or you use Server Actions. I use them all the time when I'm too lazy to have a proper API endpoint, tbh 😅


**Description:** An advanced module specifically for Next.js and advanced topics it coveres: server-side rendering (SSR), static site generation (SSG), differentiating between client and server components. It clearly explains how Next.js solves problems previously encountered in React.

Since trainees has already seen most of fundamental concepts and how they solved in pure React (fx Routing), it should be easier to explain how Next.js solves it, without focusing on what it is in general.

**Teaching Methodology:**

- **Preparation Materials:** Use “Next.js” original introduction course.

![draw io 2025-05-10 15 16 06](https://github.com/user-attachments/assets/bece24ea-418c-436d-b6d3-89da91b631e4)

#### Topics

- Introduction to Next.js (why Next.js, recommended by React)
- SSR & SSG
- Next.js App Router
- When to use client vs server components
- Optional Advanced: Server Actions, API Routes

## Proposal discussion notes

Overall, I think we can accept this proposal with some noted (also added to the document).

Agreed on:

- Restucture itself: separate React and Next
- Fallback to Vite in React module -- [Discussion](https://github.com/HackYourFuture-CPH/programme/pull/65/files#r2087473349)
- We DO NOT introduce any state libraries -- [Discussion](https://github.com/HackYourFuture-CPH/programme/pull/65/files#r2087502733)
- We DO NOT introduce reducers -- [Discussion](https://github.com/HackYourFuture-CPH/programme/pull/65/files#r2109923071) [Discussion](https://github.com/HackYourFuture-CPH/programme/pull/65/files#r2087489631)
- We DO NOT introduce UI Libraries, only mention that they're exist, so they can research is they want to -- [Discussion](https://github.com/HackYourFuture-CPH/programme/pull/65/files#r2109923071)

Todo:

- Research and add more preparation materials -- [Discussion](https://github.com/HackYourFuture-CPH/programme/pull/65/files#r2087472475)
- Integrate MealSharing better with new structure: do it in React module, check that steps are coverting the lesson plan -- [Discussion](https://github.com/HackYourFuture-CPH/programme/pull/65/files#r2087483027)
- IF we introduce refs, we need to add good examples when they might be non-avoidable (fx timers) -- [Discussion](https://github.com/HackYourFuture-CPH/programme/pull/65/files#r2087521327)
- Add introction for any 1-click-deploy, fx Vercel -- [Discussion](https://github.com/HackYourFuture-CPH/programme/pull/65/files#r2087491241)
- Figure out an example with good example of server rendering -- [Discussion](https://github.com/HackYourFuture-CPH/programme/pull/65/files#r2087497199)

Up to a discussion:

- Which router to take with Vite? How we approach Routing now? -- [Discussion](https://github.com/HackYourFuture-CPH/programme/pull/65/files#r2109832621)
- Should we cover render props? -- [Discussion](https://github.com/HackYourFuture-CPH/programme/pull/65/files#r2109934479)
- Should we introduce refs? -- [Discussion](https://github.com/HackYourFuture-CPH/programme/pull/65/files#r2087521327)
- If we remove most of the content in week 4, we probably can move there everything we found as "not exactly fit with goal" for other weeks. Or use session for questions.