What I learned creating a 45 part tutorial series on how to build Youtube in React
A few days ago, I published the last and 45th part of my build Youtube in React epic length tutorial series.
This is a summary of what I learned throughout the entire process.
There are a lot of things I learned while creating this admittedly extremely long tutorial series. But if I had to pick the three most important ones, I’d say.
- Most people will not see it through
- Creating a very long coherent tutorial series is way more work than I expected
- Redux makes the code base way more complicated. Only use it if it is really absolutely necessary.
1. Most people will not see it through
Although I was pretty sure that this project would get quite a decent amount of interest, I also knew that I’d probably loose a lot of people on the way because following along is really not easy.
Now that all tutorials are out, I have to say that it turned out as expected. Here is a screenshot of my Google Analytics dashboard which lists the total amount of page views.
Click on the image to see it in high resolution.
I started out on the 21st of January 2019 and released the last tutorial at the beginning of March. As you can clearly see, the first few tutorials got quite a few page views, but later on the page views went down steadily.
This also makes sense given the fact following along is quite a notable time commitment.
2. Creating a very long coherent tutorial series is way more work than I expected
While looking at most tutorials, I found that most of them are loosely coupled or just cover one specific topic. In my opinion this is also fine because oftentimes you are only looking for one specific solution or one specific problem solving approach.
However, I was always wondering why there are so few coherent and more complex tutorial series out there. Now I know
Creating a long and coherent tutorial series is at least an order of magnitude more work than creating blog posts about a smaller topic
The issue with coherent tutorial is that they are way harder to create because you always need to remember what you did before. If you write code and notice that there’s a better way of doing it, you just change the code. But if you write a tutorial, you either have to edit all affected tutorials or provide a lengthy description on why you are now changing what was just created two or three tutorials back.
So it’s definitely more work for the content producer.
But, it’s also way more work for the people who actually consume the content. Because they need to remember as well what they did in all previous tutorials before. This makes it harder for them and that’s why a lot of people jump off along the way.
3. Redux makes the code base way more complicated. Only use it if it is really absolutely necessary
When I started out with
React, I only knew the basic stuff. Very soon I ran into some issues where I didn’t know how to solve them elegantly with
React alone such as passing information that is used in many different components. I would describe my journey in the React ecosystem like this
- Learn the basics of
- Ran into the problem of sharing information between multiple components without dirty hacks or prop drill
Reduxto pass data around more easily
- To make sure that the
Reduxstate is not messy, I started picking up selectors (later on
- Due to complex network request code, I replaced redux-thunk with
redux-sagawhich requires understanding a generator functions(the
- Spent a lot of time putting the data I got from network requests with
- Spend a lot of time “
de-normalising” data with my
selectorsbecause my components need data from various parts of my
All these steps above illustrate how complexity grows. If you use
Redux, you strive for a normalised
Redux state. Therefore, inside your
reducer, you will need a decent amount of logic to achieve this.
Redux state is now normalised, it is easy to extend it. That’s nice. But most of your components will need data from various parts of your normalised state. So you will need to invest additional time in writing
selectors that collect the information your components need from various parts of your state.
I also found myself guilty of just storing data inside the
Redux store without thinking whether this is a good idea to begin with. A good rule of thumb is.
If you put data into your Redux store and you would need additional logic to clean it up later on because it just grows and grows, you should probably not store it there.
Don’t get me wrong. I’m not saying
Redux is bad, I’m just saying that you need to be aware to what extent your app’s complexity grows.
If I had to start over again with this project, I’d try to use React hooks all the time and would only use Redux as a last resort. In addition, I’d try to rather avoid it just because it makes things more complicated. It’s just tempting to store all you data inside of it even though it would be way easier for a component to just fetch it on its own.
With the introduction of
React hooks, getting along without Redux is even easier
If you do use
Redux, strive for
synchronous actions if possible. Otherwise you have to deal with handling side effects and will likely use
redux-saga which adds another level of additional complexity.
4 Interesting side notes
- It took me three months to write out all
- Having a few raving fans really helps
Youtube Data APIis rough around the edges. A
GraphQL-based APIwould be way easier to work with
SCSSresults in less code, is a first class citizen in
- I guess I should have sent the entire series to a few proofreaders because a lot of people spotted minor mistakes in them
- Semantic UI has great components, but it’s rather heavy and and its navigation bar (
Menucomponent) is hard to customise and to get responsive. Next time, I’d probably pick Bulma.
5. Why I created this tutorial series
I created this tutorial series because I had worked through many loosely related tutorials in the past. And while some of them were really good, none of them outlined exactly how to build a highly polished, production-ready application. It’s as if you want to be an architect but only being taught what different types of front doors exist. I mean sure, knowing how all these little parts are working is important, but putting them together is totally different story.
Looking back I can say that building a Youtube-like app is actually not that hard, if you have decent experience with
React & friends. However, when I started out, I didn’t 😁. I wanted to prove to myself that I can build highly polished front end applications. So I thought to myself.
How can I measure, how proficient I am with professional front end development?
The answer to that is actually pretty simple.
If you can build a clone of a very popular application where a lot of experienced people work on, you’re probably pretty good.
So I looked at popular websites like Facebook, Instagram, Spotify and so on. I quickly noticed that
Youtube seemed to have a pretty
decent API for third party developers, so the choice wasn’t too hard. I didn’t want to build out the backend as well because the scope would have exploded.
Explaining how and why you solved a problem in a specific way forces you to really understand the technology you are using.
Knowing that you’ll need to explain the system’s architecture and its structure forces you to write readable and well structured code. Although I would state that a lot of things can be improved in the project’s code base, I’m pretty satisfied with its structure and think that it would be easy to extend this project.
6. What’s next
I don’t know yet. But I’ll keep you in the loop. If you have any suggestions, please reach out to me on Twitter @productioncoder.