Original author: Jolyon Russ
This article is compiled:Big beardTranslated original text:/blog/posts/detail?postId=58e83f01a58c240ae35bb8e1
English connection:11 lessons learned as a React contractor
Please indicate the source when reprinting, retain the original link and author information.
When I was struggling on React, I didn’t know what to look for, but over the years, I have only found that what I was looking for was already in my mind after summarizing my experience. Below are some key points of my own learning React, as well as some of my background.
- I've written code for 18 years, and 13 of them are full-time professional veteran drivers;
- For 6 years, he focused on Flash development;
- Until Steve Jobs’ open letter stated that he did not support Flash;
- I've tried HTML, CSS and JS skills;
- I once had a long time to worry about the research on mainstream JavaScript frameworks, and I felt that they hid a lot of logic behind it;
- Resigned and started outsourcing life, mainly making prototypes;
- Have seen a lot of React Demos;
- In October 2015, I officially started my React project career and fell in love with it;
- In January 2016, I changed my Title: React Developer on LinkedIn.
Next is some of the experiences I have summarized, I hope they will be helpful to you.
1. Multiple simple components are better than one highly customized component
Changing the behavior of React components depends on the props you pass, which is a useful feature. Developing a good programming habit early in the project is good for the future: creating common components that can be used elsewhere.
After you start a project, you may continue to expand the usage extension of a component for a component. After a period of time, you will find that you will be tired of fixing bugs. After fixing in scene A, you will find that you have found bugs in scene B and scene C.
My advice: If a combined component causes a bug, then breaking it down into several simple components, even if the code is repeated, it is worth it.
2. If you find a bug in the library, try to mention Issue and Pull Request
As long as you use React, you will definitely use open source software, whether it is the React core or more than 1,000 available NPM modules. If you find a bug in the library, then bring up the Issue. Better yet, if you fix a bug, you must mention Pull Request to integrate the fixed code, because using this library and encountering bugs is not the only one who encounters bugs, doing so will make the whole ecosystem better.
My advice: Give back to the community, even if you just fix the spelling error in the document.
3. Complete the build process first, and then write React code
I know this is not a common scenario, but I have encountered it when I started an outsourcing project and started building, I found that some packages that depend on compilation do not exist. Then I found out that this React is actually used in a Backbone project. Implementing React components in Backbone is actually very simple, and using Redux to communicate between these two. Communication between them must be compiled together through Browserify or Webpack.
My advice: If you apply React in an existing project, it is better to use Browserify or Webpack to build the process first.
4. For simple data visualization, native SVG >= D3
D3 does a great job of data visualization, but if you are just doing some simple data visualization, rendering native SVG can meet your work needs.
My advice: Learn some SVG basics, which is enough before you need more complex features. Youtube'sFront-end center channelIt happened to be played a few days agoShows about SVG, worth a look.
5. If you only have a two-week project deadline, keep the functions simple
If all you want to do is render, React and React-DOM are enough.
Redux's processing is time-consuming and effort-consuming, and it is useful for handling multi-layer UI in large projects. But if your project is simple, it's good to pass props and callback, and there's no need to use Redux.
My advice: Template projects are very useful, but starting with React and React-DOM is a great option if you want to keep your project streamlined.
6. It will be slow to move elements depending on CSS animation alone
I can't tell you exactly when you'll see a significant drop in frame rates, maybe when there are 30 elements, maybe when there are 300 elements. But you can tell me some experiences that will help you. Make full use of React's virtual DOM and ensure that it is rendered and re-rendered only when needed.
That is to say, only those components that are visible in the view window are rendered.
My advice: Test on low-end machines, and also test boundary data to see how your program performs under restricted circumstances.
7. Researching templates is a great way to start, but...
If you are learning a new library or a new framework, starting with a template project is a better way. It would be even better if your company had its own template.
But don't think that template projects can solve all problems. In actual work, you will find that what it achieves is not what you want. If you don't build a project from scratch yourself, there may be many problems later. Also, if you don't know much about the various features of a template project, you'll likely refactor a feature that already exists.
My advice: Use template projects where they do best – start projects quickly. Don't be afraid to refactor them, you want them to operate according to your will, and it's better to know the characteristics of the template project you are using in advance.
8. Keep components, connected components and containers controllable
When using Redux to build, it is best to limit the number of components, and try to ensure the reusability of actions/reducers.
Components should only rely on their own props.
Connected components should access application data through Redux and should render only their own DOM and child components.
The container acts as a player, fetches data and renders components.
My advice: Be careful to keep naming and functionality consistent.
9. Strict code checking is a double-edged sword
I have developed various projects and experienced various forms of code checking. From projects that have no code check at all, to projects that even a dangling comma refuses to submit.
I think most of us would agree that code quality is not just about you using the right space characters and tab characters. When opening a file, the code gives you the pleasing feeling that makes you comfortable writing code, and your focus can be focused on your code logic.
Code checking can also help you find some errors, such as constant allocation and writing errors, and even the classic "Undefined is not a function" error.
My advice: Embrace the code review rules your team requires. I'm using ESLint in JS and scss-lint in Sass project Atom. You can also set rules to facilitate conversion. If you have strict requirements and don't want bad code to be submitted,pre-pushAn npm script will be executed to do the check before pushing.
10. React rendering in Express projects is feasible
There are many blog posts about how to install a normal application, but most of them assume that you want a single page application, and few articles about how to render a single React component in a multi-page Express application.
My advice: In this case, ReactDOMServer will become your friend. You can treat all components as page fragments and pass them to a template to render.
11. Saga makes my brain muddy
Saga is a Redux middleware, a new feature of ES6-based generator. "The generator defines an iterative algorithm that can maintain its own state." In practice, it is different from normal JavaScript workflows, because when another Promise-based code is executed, this function can be paused during execution.
I shouldn't be the first, nor the last to say this, Saga made my brain smother. It was a mess when I first studied Saga, but in the end I conquered it. But looking back, if I understood the generator from the beginning, things might have gone a little better.
My advice: If you are using Saga for the first time and no one on the team has relevant experience, it is better to understand Promise and Generator first, which will be helpful.
The above are some of the experiences I have summarized since I studied React. Last year was a very different year for me. I came into contact with different types of projects and learned a lot. Looking forward to continuing to explore new things in the coming time. For example, React Native. I'm glad you've finished reading this article and hope it will be helpful to you.
If you think there is anything else to pay attention to in the article or add it,Please let me know。
I'm writing a book recentlySmall book》, Children's shoes that are interested in