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.

TL;DR

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.

1. Most people will not see it through
2. Creating a very long coherent tutorial series is way more work than I expected
3. 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

1. Learn the basics of React
2. Ran into the problem of sharing information between multiple components without dirty hacks or prop drill
3. Learned Redux to pass data around more easily
4. To make sure that the Redux state is not messy, I started picking up selectors (later on redux-reselect)
5. Due to complex network request code, I replaced redux-thunk with redux-saga which requires understanding a generator functions(the function* thing…) in Javascript.
6. Spent a lot of time putting the data I got from network requests with Redux-saga into Redux in a normalised way
7. Spend a lot of time “de-normalising” data with my selectors because my components need data from various parts of my normalised state

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.

Since your 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 45 tutorials
• Having a few raving fans really helps
• The Youtube Data API is rough around the edges. A GraphQL-based API would be way easier to work with
• SCSS results in less code, is a first class citizen in create-react-app 2.x
• 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 (Menu component) 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.