I'm a developer who was worked professionally since the beginning of 2000 with mostly web development.

Since a few years I've worked quite a lot with React (and React Native) and are REALLY enjoying it!

Recently I got a question from a school to be involved in a React education for people already in the industry (web development) who wants to learn React.

Since I really enjoy React, and also love to spread my knowledge to other developers, I accepted (together with a co-worker) it! How hard could it be?

When it comes to all the details of React, it might not actually be that easy, as it seemed... =) I'll try to explain why.

The history

React has been a open source project by Facebook for quite some years now (since 2013). Me personally is very happy with the current state of things in the React ecosystem. But a lot of things has happened during these years and I can imagine a lot of people being frustrated with ever changing "trends" on how to build stuff.

But except for the much appreciated hooks-update, we at Itiden (were I work) has kind of gathered our favorite libraries around the core React libs, and for the last 1-2 years stuck with that, and been really happy with it.

But this also makes it kind of hard to teach, since I would like to teach the way we work with it. But also understand that not everyone does it that way... I'll try to explain how we do it, and why.

Functional components vs Class components

Short story, we like and only use functional components.

I would like to focus the education on functional components and not go in to Class components to much.

But I guess a basic understanding is "nice to have". Since old documentation and examples might be written with classes. And also, some might get to work in "old" (old is relative in this case =) projects that uses classes.

Global state

In bigger (and it does not even have to be that big) projects you will at sometime need to store state that is globally available (and not sent with props to all components).

Nowadays, this is quite easily done with the Context API and useState hooks.

But when to gets a little bit more complex, you would probably use useReducer or even a third-party library to handle state.

I have never come to like Redux (the most commonly used third-party library). The amount of boilerplate (yeah, I've heard about Redux toolkit and that might fix this) and the difficulty I've had to just read code that used Redux and understand it has just not worked for me. And when it comes to useReducer, it kinda reminds me of Redux and I'm having trouble (might be a native language thing, English is not my native language) understanding the "reducer" part.

And a few years ago, to the rescue came Mobx.
It was kind of a "hallelujah moment" when it was released and me together with my colleagues looked at the documentation and how you would write code with it. Since then, we have used Mobx in almost all projects.

But I understand that we can't just focus on Mobx in the education. I'm aware that more project are using other solutions, then are using Mobx.

Styling

When React was released, there was a debate about how the hell you could suddenly mix logic (the Javascript part) with HTML and styling. We have all learned that these three should all be split up in .html, .js and .css files!

Since then, I would say that most people (that have used React or any other of the major Javascript frameworks) agree on that it actually isn't that bad, and actually quite nice even to keep things together in component file.

Still, there are multiple ways of styling components. While it is fully possible (and I guess quite widely used) to write styling in a separate css (or sass/less) file, with the use of Javascript to write your HTML (JSX in React) along came the idea of writing CSS in Javascript. Quite some libraries have been released to help the developer to accomplish that. But we have agreed (and are enjoying it) to use Styled Components.

But what should you educate? I guess we'll keep the discussion open on what to use, but it will be hard not to prefer Styled Components :-)

The directory structure

When you start your small React project I wouldn't overthink this to much. But when a project grows, I think it is a good idea to think about where you put your files and how to name them.

There are two major "ways" of structuring your files. By type of file (like component, page, util, service etc.) or by features (group components, services etc. that belong together).

While I understand the second way (by feature), we have kind of stuck with the more "basic" (and more widely used I would say) way of just structuring the files by type.

But this is very much a matter of personal opinion.

When it comes to naming you component files, there are also multiple ways. You could keep a directory structure with a folder named after each Component and a index file exporting the components. This I would say work best if you would have multiple files, like tests in the same folder. Otherwise, keep it simple.

Testing

I would like to teach some fundamentals regarding testing your React code. I would use Jest and React Testing Library och teach how to do some basic tests. This was actually harder than I estimated. I guess, coming from a web development background where you haven't written tests (as most student seemed). Also, when trying Typescript or Next.js, it seemed like some have more problems configuring their tests then writing the actual application. And I understand them, setting up your tests is not easy.

But I guess, when figuring out the setup, the next question is what to test and when? It is not an easy question to answer. The answer was, most of the time, test things that would make you feel more secure about your code. Still, not easy...

And I can honestly say, that I build quite some React apps, without or with minimal tests. And that is fine also.

TypeScript

I really enjoy using Typescript (I have probably forgot about the initial learning problems) and nowadays I have problems not using it. But for this course I wanted to focus on the React part, and not let the student get caught on type problems.

But also, since a lot of code written today in React uses TypeScript, I didn't want to completely exclude it.

So, there was an optional part, where the student was able to learn about TypeScript. And I actually think a lot of them actually liked it and understood the pros (and to some degree the cons) of using it.

Summary

The parts that seemed hardest to get (except for getting the tests to run) was the idea of a function that can be run multiple times, but render the "same" components. The idea of a useEffect function and set state function that are not synchronous. Especially the dependency array for useEffect (and useCallback/useMemo) seem to be hard to get a good understanding of. I guess building stuff and making your errors eventually makes you understand =)