-
Notifications
You must be signed in to change notification settings - Fork 15
Plan React module restructure #65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
f0803e4
0fd4c3e
d58a0c5
c3bdd4c
58d19d0
72a5407
7863641
8280267
a273a7a
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,110 @@ | ||
| # 📘 React & Next.js Module Restructuring Plan Proposal | ||
|
|
||
| ## 🎯 Goal | ||
|
|
||
| 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. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 👇
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 | ||
|
|
||
|  | ||
|  | ||
|
|
||
| ## 🧱 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. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This one is "to be researched", to be honest.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I agree! Hence, the "main" topic for each week (see my comment further down 👇) — but yes, finding preparation material is a challenge.
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. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I very much like us to use Vite
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. 😭 |
||
|
|
||
|  | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Week 4 diagram has reducers twice
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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:
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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"
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 (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)
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To the drawing:
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.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Re. Week 4Yes 💯 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
UI libraries
|
||
| - Component libraries (UI libraries) | ||
| -  Routing | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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) | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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:
Just look at this bullet from the app router -> pages router migration guide 🤯 Only saying
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I've tried to explain all of that last time I taught React 2, I lost trainees in about 15 minutes 😆
I don't need we need to tech
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. | ||
|
|
||
|  | ||
|
|
||
| #### 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. | ||

There was a problem hiding this comment.
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.