No, I didn’t wrote that, but I know it got your attention 🔪

Learning a new skill can be distressing. You often find yourself in a sea of tutorials and articles, along with countless personal opinions. And each claimed to have found “the right and perfect way.”

This leaves us to discern whether the tutorials we choose are a waste of time.

Before diving into the ocean, we must understand the basic concepts of the technology. Then we need to establish a technology-based mindset. If we start learning React, we first have to think like React. Then we can begin to integrate the different modes of thinking.

In this article, I’ll introduce some of the lessons I’ve learned about this kind of thinking from my own experience with React. We’ll review work hours and evenings working on personal projects, and even my presentation at a local JavaScript event.

Let’s get started!

React is evolving and you need to move with The Times

If you remember the first announcement of version 16.3.0, you’ll remember how excited everyone was.

Here are some of the changes and improvements we’ve seen:

  • Official Context API

  • createRef API

  • forwardRef API

  • StrictMode

  • Component Lifecycle Changes

The React core team and all the contributors are doing a great job — working hard to improve the technology we love. In version 16.4.0 we saw Pointer Events.

There’s no doubt more changes are coming, it’s just a matter of time: Async Rendering, Caching, Version 17.0.0, and more unknown.

So if you want to be the best, you have to keep up with the changes in your community.

Understand how things work and why they were developed. Understand the problems being solved and how development is getting easier. This will help you a lot.

Don’t be afraid to break up your code into smaller pieces

React is component-based. So instead of being afraid to break up big modules into smaller ones, you should take advantage of this concept.

Sometimes, a simple component may only have 4-5 lines of code, and in some cases, that’s fine.

By doing this, new people don’t have to spend days understanding how the code works when they join.

You don’t have to have complex logic in your components. They can be just visual components. If this makes the code more readable, easier to test, and reduces the “bad smell” of the code, then it’s a great win for everyone on the team.

In the example above, the properties are fixed. So we can have a pure component control site error message Not Found, that’s all.

Also, if you don’t like CSS class selectors as class names everywhere, I would recommend using the Styled Components. This improves readability.

If you’re worried about creating too many components because too many files pollute the directory, rethink how you structure your code. I’ve been using fractal structrue, and it’s great.

Don’t stop at the basics – move to the advanced

Sometimes you might think you don’t understand enough about something to move on to advanced applications. But usually you don’t have to worry too much — take on the challenge and prove your fears wrong.

By mastering advanced content and pushing yourself, you can understand more of the basics and how to apply them to larger projects.

Here are a number of patterns to try:

  • Compound Components

  • High Order Components

  • Render Props

  • Smart/Dumb Components (Smart/Dumb Components)

  • Etc. (try to analyze)

Study them and you’ll know why and where to use them. React makes you feel more at home.

Also, don’t be afraid to use something new at work — within limits, of course.

Some people might question that, and that’s normal. Your job is to defend your work and decisions with strong evidence.

Your goal should be to fix an existing problem, make future development easier, or clean up some spaghetti code. Even if your proposal is rejected, you will gain more than if you remain silent.

Don’t be overly complicated

This may sound like an opposite view, but it’s different. We need balance everywhere in our lives. Instead of over-designing to show off, we should be pragmatic and write code that is easy to understand and implement.

If you don’t need Redux, but you want to use it, because a lot of people use it without knowing what it’s really for. You can’t do that. Stand up for yourself and don’t be afraid to stand up if someone pushes you down.

Sometimes you might think that by using the latest technology and writing complex code, you can say to the world, “I’m not a beginner, I’m an intermediate/advanced developer. Look what I can do!”

Honestly, that was my mindset at the beginning of my career as a developer. But over time, you’ll learn that it’s easier to live with code that doesn’t show off and “works.”

  • Your colleagues can take over your project; you’re not the only one responsible for development, fixing, and testing.

  • Teams can learn what others are doing without having to go through long meetings. A few minutes of discussion will suffice.

  • Pick up where your colleagues left off when they went on vacation for two weeks. And you don’t have to work eight hours, because you can do it in one.

People respect people who make life easier for others. So if your goal is to gain respect, rank up, and improve yourself, write code for the team, not for yourself.

You’ll be everyone’s favorite team member.

Refactor, refactor, refactor — that’s normal.

You may change your mind dozens of times, although project managers change their minds more often. Someone will judge your work, and you will judge him. So as a result, you’re going to have to change your code a lot.

But don’t worry, it’s a normal learning process. We can’t improve ourselves unless we make mistakes and our code doesn’t make mistakes.

The more times you fall down, the easier it becomes to get back up.

But here’s a word of warning: make sure you test your current software. Smoke testing, unit testing, integration testing, snapshot testing — don’t be shy about testing.

Everyone has seen or will see a scenario where testing saves valuable time.

If you’re like a lot of people who think this is a waste of time, try to think differently.

  • You don’t need to go with your colleague and explain how it works.

  • You don’t need to go with your colleague and explain why something went wrong.

  • You don’t need to fix bugs for your colleagues.

  • You don’t need to fix a bug that took 3 weeks to discover.

  • You’ll have time to do what you want.

There are many benefits to all of this.

If you like it, you will grow

Over the past year, my goal has been to get better at using React. I want to give a talk about it. I think other people enjoy it as much as I do.

I could sit there all night programming, watch presentations and enjoy every minute of it.

The truth is, when you want something, you find that somehow someone will start helping you. Last month, I gave my first talk on React to 200 people.

Over the past year, I’ve become stronger and more comfortable with React — patterns, paradigms and internals. I was able to conduct advanced discussions and teach others about topics I had previously been afraid to touch.

Today I still feel the same excitement and enjoyment I felt a year ago.

So I recommend that everyone ask themselves, “Do you love what you’re doing?”

If not, keep looking for that special thing that you can talk about for hours, study every night, and make you happy.

Because we have to find what’s closest to our hearts. Success can’t be forced, it can be earned.

If I could go back a year, that’s what I would say to myself before embarking on this big journey.

Thank you for reading!


Tomas Eglinskas 英文 : hhking

blog.hhking.cn/2018/09/12/mindset-lessons-from-a-year-with-react/