Learning new things can be challenging. I keep hearing:
What is the best tutorial for making a spreadsheet processor in React?
Is there a good tutorial on how to make a survey system?
and other variations of “best tutorial for making X?”, where X is some super concrete application.
It seems like the most obvious thing to ask, right?
So in this post, I’m going to cover a myriad of possible apps and write the ultimate tutorial for making all of it. Cmd+F to find yours.
Just kidding. But also, not really.
I’m not going to demonstrate every possible application along with the sources; best case, that’s simply impossible. But I want to try to change the way you think about the question itself, about “what’s the best tutorial for making X?”
The other way to see the question
Change how I see the question? How could you possibly say that, Gosha?
A question for you: is it possible to have a tutorial, any tutorial, let alone the best, for every X application?
If you think about it, you realize
X could take on infinitely many values…
Are there enough people on the Earth to cover them all?
Are there enough people on the Earth who can code to cover them all?
Are there enough people on the Earth who can code in React and can write tutorials and have the time, to cover them all?
You see where I’m going, don’t you?
There are several constraints at play here:
- an infinite amount of possible applications… and even more variations of each one
- a small amount of people capable of producing these
- limited spare time to produce these
It’s not feasible to have a tutorial for everything
Um, that’s bad! What am I supposed to do now?!
You are kind of getting the hang of this hip thing called React. (If not, the official docs are the best place to get started.)
You have an idea of what you want to build to practice your knowledge. (Or, at least, you should.)
And then, you are looking for the perfect tutorial to build the exact app you want.
Do you spot an issue here? It’s like knowing 2+2=4, but researching on what 3+(2+2) would be.
Sure, it seems like a separate problem worth looking into — different numbers and all that. But doing that is indicative of something else… entirely.
Not applying your knowledge to different contexts. It’s just like math: you learn what addition is, and you can do it on any numbers, not only these that your teacher had shown. Similarly, with React, you learn what components are, and you should be able to see “in components” into all kinds of apps.
Not knowing how to split up a big, unmanageable problem into smaller chunks. A big problem might feel daunting to attack… I mean, where do you even start? The thing is messy, aw. Wouldn’t it be better to solve several smaller problems instead?
Not knowing how to help yourself, or at least how to make it easier for others to help you. Learning to help yourself is one of the best things you can do for yourself. There will be times when the docs are lacking, or some problem was never discussed online before. You should be able to know where to look.
At the very least, you should be able to ask questions that are easy for other developers to answer.
Abstract from the specifics
In a way, programming is like stacking pieces of Lego to build something. You have several distinct parts, and you combine them in various ways.
Likewise, with React, you get the basic blocks of knowledge: components, props & state, and JSX. You can get a basic understanding of them by going through the docs. In the end, you should be able to:
- “see in components,” given a screen mockup
- be able to make and render simple components
These skills are needed to build any React application. And if you have them, you will have at least a primitive idea on how to approach some particular app, even if you never built one like it before.
Programming is all about abstracting from specific examples and applying your knowledge to different problems.
Why split up a problem
I mean, your problem doesn’t seem so significant. The X application. Simple, right?
Hold your horses.
The “X application” is a very loaded and assumptive term. It’s entirely possible that what you imagine as the “X app” will be different from how I see it, for example.
It’s very implicit. It’s not specific enough.
If you are looking to make a project, even if it’s “just for learning,” sogginess is not your friend.
Try to visualize the end result. Maybe draw a few mockups where the core functionality is demonstrated. Think about the user flow. Think about the features.
The more thought-through, the better.
But I have it all in my head!
It… might be true, but while it’s in your head, you will think about X and feel discouraged immediately. Because X seems big, unmanageable, and you don’t even know how to build it!
Materializing your ideas: on screen or paper, can have a big impact. You will not see just a big X. You will see the tiny parts that X is made of.
And that is awesome. That makes it way easier to ask for help and to build.
Take this list of tasks for a todo app:
- render a list of todos
- make each todo clickable
- on click, mark the todo as completed
- render a text field
- on enter, add the todo and so on.
It will be easier for you to work through it, than through “I need a todo app.” Checking off every small item will make you feel your progress. You will have a clear idea of what to do next.
Learn to help yourself
Most importantly, this formalization of your app will make helping yourself easier.
You already know how to handle at least a couple of items from your list. Do that!
And for what you don’t know, seeking help is now a thousand times easier. Because behind these small bits are the concepts that are used in many, many applications.
Rendering a list? Well, it’s more about rendering arrays, and that is a solved problem. You can google “react render array” easily!
Make each item as clickable? No problem! “React on click” comes in handy.
How to take text from a text field and add it to your array of todos? Again, way easier to find a solution to.
And you see where this is going.
From “finding the perfect tutorial,” you are now down to action! You know exactly what you don’t know, and know how to research on that.
Does it not feel liberating? I know it does.
It opens up a whole new level of thinking and learning. The difference between a newbie developer and an experienced developer is not that the experienced developer knows everything, of course not; the difference is primarily about knowing what to look for, and where.
Are tutorials dead now?
Of course not. But tutorials have a different point. They are not about X, they are about something else.
They are about common “slices” that make up an application:
- user authentication and permission management
- form handling
- a real-world example of a new web standard
- a library or an entire framework, which is like the “base ground”
- et cetera…
The application itself which is built in the tutorial is mostly a byproduct. The concepts, the knowledge, and the practice are the point, however.
The idea is that you will be able to abstract from one individual app and understand the concepts, through practice, and apply them to your unique needs.
- Spec the result you are aiming for.
- Break it down into smaller things.
- Identify what you know how to do, and what you don’t.
- Build what you know; research on what you don’t, and then build it too.
- Use tutorials to learn the concepts.