Usually getting started with a new technology is not so easy. The newcomer falls into the boundless sea of tutorials and articles. Moreover, behind each of these materials is the personal opinion of its author, and each author declares that it is through his mouth that the truth speaks.
From the point of view of common sense, it is clear that not all articles published on the Internet can bring real benefits, so those who are trying to learn something new have to evaluate publications in an attempt to find an answer to the question of whether to spend on them. your time
Before leaving with the head to study, the programmer needs to understand bases of the technology interesting him. Then you need to create your own vision of this technology, learn to think in categories. As a result, if someone starts to learn React, he must first learn to “think in the React language”. And after he develops this quality in himself, he will be able to intelligently get acquainted with the opinions of other people and, selecting the most valuable, to develop in the chosen direction.
The author of the article, the translation of which we publish today, wants to share with everyone so that he was able to learn about React during the formation of his own vision of this technology, during its study and the accumulation of experience in this area. Here he will talk about what he managed to understand in a year, working as a React-programmer, working on his own projects in his spare time and sharing his ideas at one JavaScript conference.
React is a constantly evolving technology.
Since React is in a process of continuous development, anyone who wants to master this technology must be prepared to keep their knowledge and skills up to date. If you remember the announcement of React 16.3.0, then you know about the enthusiasm in the community of programmers, which caused new opportunities. Among them - the official API Context, API createRef and forwardRef, strict mode, changes in the life cycle of components. The core team of React developers and all those who made a feasible contribution to the development of the project did an amazing job, trying to improve our favorite framework with all of us. This work does not stop. So, for example, in version 16.4.0 there appeared support for
pointer events .
The development of React continues, the emergence of innovations is only a matter of time. Among such innovations are asynchronous rendering, caching, many changes expected in React 17.0.0, and something that no one knows about yet.
Given the above, it is clear that if you want to stay at the forefront of React-development, you need to be aware of the innovations. This means that you need to know how the new framework mechanisms work, and why they were created. You need to understand what problems they solve and how they simplify development.
Do not be afraid to break your code into small pieces.
React is based on components. This suggests that this concept should be used and boldly break large pieces of code into smaller parts. Sometimes a simple component can consist of only 4-5 lines of code, and, in some cases, this is completely normal.
Code fragmentation should be approached so that if a new developer joins your project, he would not have to spend many days trying to understand how this project works and how it works.
// , ? return ( [ <ChangeButton onClick={this.changeUserApprovalStatus} text="Let's switch it!" />, <UserInformation status={status}/> ] );
You are not required to create huge components containing all the logic necessary for their work. A component, for example, can only describe a visual representation of an entity. If the use of small components improves the readability of the code, makes it easier to test and makes it easier to support the project in the future, then systematically applying this approach is a great solution that will positively affect the work of each team member.
import ErrorMessage from './ErrorMessage'; const NotFound = () => ( <ErrorMessage title="Oops! Page not found." message="The page you are looking for does not exist!" className="test_404-page" /> );
In the above example, static properties are applied. Before us is a pure component that is responsible for displaying the
Not Found error message and for nothing else.
Also, if you don’t want CSS classes and class names everywhere in your code, I would recommend using stylized components. This can significantly improve the readability of the code.
const Number = styled.h1` font-size: 36px; line-height: 40px; margin-right: 5px; padding: 0px; `; //.. <Container> <Number>{skipRatePre}</Number> <InfoName>Skip Rate</InfoName> </Container>
If you are afraid of creating too many small components due to the fact that it seems to you that their files clutter up folders with project materials, think about how to structure your code in a different way. I used the
fractal structure of the project to organize the materials, and I must say that this is simply wonderful.
Don't stop there after you get the basics right.
Sometimes you may feel that you do not understand something well enough to move on to learning and using more advanced things. Usually, as a rule, you shouldn’t worry about it especially - just start learning what seems to be too difficult for you and prove to yourself that you can figure it out and use it.
For example, if you are at the beginning of a React developer’s path, you may find a lot of seemingly difficult design patterns that you should explore. Among them are Compound Components, High Order Components, Render Props, Smart Components, Dumb Components and much more (for example, it is recommended to master the technology of component performance profiling).
Master all these technologies and you will understand why and why they are used. As a result of their study, you will find that now it is more convenient for you to develop projects for React.
// ? // , , . render() { const children = React.Children.map(this.props.children, (child, index) => { return React.cloneElement(child, { onSelect: () => this.props.onTabSelect(index) }); }); return children; }
In addition, do not be afraid to use something new in the course of work, of course, within reasonable limits. At the same time, you should not limit the use of new approaches only to experiments in projects that you do in your spare time.
If those with whom you work have any questions about your innovations, be aware that this is completely normal. Be prepared to protect your decisions with solid arguments in their favor.
Your goal should be to solve an existing problem, simplify further development, or simply improve the readability of code that used to look untidy. Even if your proposals, as a result of discussions with the team, are rejected, you will at least learn something new, and this is much better than not offering anything new and not developing as a developer.
Do not seek to over-complicate projects.
Perhaps this recommendation will seem to you going against the previous one, devoted to experiments with new technologies, but, in fact, it is not. Everywhere, in life, in programming, we need a balance. Do not over-complicate something just in order to demonstrate to others their own advancement. It is best to approach what is happening in terms of practicality. Write code that is easy to understand and that solves the tasks assigned to it.
For example, if you don’t need Redux in your project, but you only want to use this library because everyone uses it, and you don’t think much about the purpose of using Redux, don’t do it. Better - understand Redux, build an understanding of this technology, and if you see that what is happening in your project runs counter to what you understand, be prepared to defend your point of view.
Sometimes it may seem to you that using the latest technologies and creating complex code, you declare the following to the whole world: “I’m not a novice developer, I’m becoming a professional. Here is the code I'm writing!
Honestly, I myself was so at the beginning of my developer career. But over time, it comes to the realization that the code that is written without the desire to prove something to someone, the code in which technologies are not used only because they can be used in it, without serious reasons, resort to these technologies, makes it much easier life of any developer. This is what it means:
- The project, which is not over complicated, can work not only for those who understand the structure of this project, but also for other members of the team. As a result, the task of development, error correction, testing, and many others, can be solved not only by the creator of this project.
- Other programmers can understand what you are doing without spending too much time listening to your explanations. You can bring them up to date in a couple of minutes.
- When the main developer, say, goes on a two-week vacation, others are free to take on his tasks, while they do not have to sit a whole working day over what is being done for a couple of hours.
People are good to those who do not complicate their lives. Thus, if you want the team to be respected and to be in good standing with the bosses, try writing code for the team, not for yourself. As a result, you will become a person with whom it is easy and pleasant to work.
Refactoring is normal
You, in the course of working on a certain project, can change the point of view on some things dozens of times, and the project manager may revise his views more often. Someone criticizes what you have done, and you, if the criticism is justified, begin to change something; you criticize the work of others, and they, by listening to you, redo what they have written. As a result, the code has to constantly rewrite.
You should not take this as something negative. Given that programmers constantly have to learn something new, refactoring is perfectly normal. Development is usually the path of trial and error. And the more often someone stumbles, moving along this path, the easier it will be for him to cope with difficulties and move on.
However, in order that refactoring does not turn into a nightmare, it is recommended that sufficient attention be paid to tests. Feel free to test everything you can reach. Perhaps every programmer has either already encountered or else will encounter a situation in which good tests will help him save a lot of time. And if you, like many others, believe that tests are a waste of time, try to perceive them not in the same way as before. Namely, here are the benefits that a developer and his team receive from good tests:
- You do not have to sit with colleagues for a long time, explaining to them how everything works.
- You do not have to explain the reasons for which something went wrong.
- You do not have to correct the mistakes of others.
- You do not have to correct errors that appeared a few weeks after the release.
- Thanks to the precise organization of the project checks, you have time to solve various tasks that are not related to debugging from unknown errors.
In fact, here is just a small list of advantages that a programmer and his colleagues receive from a well-organized project testing system.
Love to work is the basis of success.
A year ago, I decided to become a more advanced React developer. I wanted, among other things, to speak at various events, to share the joy of learning new things with other people.
I can spend all night at the computer, doing my favorite thing and enjoying every minute of what is happening. The point here is that if a person truly aspires to something, then, in one way or another, everything around helps him go towards the goal. For example, I recently spoke at a small conference in front of two hundred spectators for the first time.
During this time, I grew up as a React-developer, I learned a lot of new things. In particular, this applies to various design patterns, principles for developing projects, and the internal mechanisms of the framework. Now I can communicate on topics that previously seemed inaccessible to me, and, moreover, I can teach others what I did not dare to look at earlier. At the same time today I feel the same delight and pleasure as a year ago.
Therefore, I would recommend everyone to ask themselves: “Do you like what you are doing?”. If the answer to this question is negative - find what you really like, something that you can talk about for hours, something that you can do all day and night, feeling completely happy. In order to grow and develop in any field, everyone needs to find what he likes. Man cannot be made to succeed in anything. A person can achieve success only when he consciously and with pleasure does what he likes.
If I could come back a year ago and meet myself there, I would say to myself exactly that in order to prepare myself for the long and interesting journey that awaits me.
Dear readers! What tips, suggested experiences, could you share with aspiring web developers?
