- When Does a Project Need React?
- Originally by CHRIS COYIER
- The Nuggets translation Project
- Translator: Yang Yingfeng, dragon Rider general
- Proofreader: Guangyuan (Charlie) Yang, Schrodinger’s cat
When does a project need a React framework?
You know when a project needs HTML and CSS, because that’s the foundation of the project. It’s also clear when to use JavaScript: when you need interactive functionality that only iT can provide. It was also clear in the past when we should use a code base: we needed jQuery to help us simplify DOM manipulation, make Ajax calls, and handle browser compatibility issues; We need Underscore to provide helper functions that JavaScript does not have.
But as the need for these code bases faded away, we saw the growth of many new frameworks. I think it is not so easy to determine when they are needed. For example, when do we need the React framework?
Among the many JavaScript frameworks — Vue, Ember, Svelte… Either way, I want to use the React framework as an example to see where it fits in. I understand that these frameworks are not identical, but there should be some commonality in the timing of their use.
This is my suggestion.
✅ when there is a large number of states in a project
Even the word “state” doesn’t quite capture what I mean. Imagine these scenarios:
- Which column of the navigation bar is active
- Whether a button is disabled
- The value of the input box
- Which drop – down box is the pop-up state
- When to load a region
- How do login users control their permissions
- Whether the user-written article is in published or draft state
“Business logic” — the sort of thing we deal with all the time. States can also be directly related to content:
- All the comments on an article, and the bits and pieces that make them up.
- The article you are currently viewing, along with some properties of the article
- A series of related articles, and the attributes of those articles
- A list of authors
- An activity log that records recent user actions
The React framework doesn’t help you organize these states, it just says: I know you need to deal with states, so let’s set it to state and programmatically read and write.
Before the React framework, we might have considered the definition of state, but for the most part we didn’t manage it as a straightforward concept.
Perhaps you’ve heard the phrase “single data source”? Most of the time we use DOM as our single data source. For example, you need to know if you can submit a form. You might want to check with $(“.form input[type=’submit’]).is(“:disabled”), because all business logic that affects whether the form can be submitted will eventually change the disable attribute of the button. So buttons become the de facto data source for your app.
Or, if you need to know the name of the first commenter on a post, you might write $(“.comments > ul > li:first > h3.com-author).text() because DOM is the only place you can get this information.
The React framework tells us:
-
We think of all of these things as states.
-
I’ll do one thing for you: convert the state to a string of JSON objects, so that it’s easy to handle, and maybe your server can handle it beautifully.
-
What’s even better: you can use these states to build HTML directly. You don’t need to manipulate the DOM at all. I do it for you (probably faster and better than you would have done it yourself).
✅ Fight Spaghetti code
This has a lot to do with the states that we just talked about.
Spaghetti code is code that is out of your control. Again, imagine a form that has some business logic dedicated to processing input boxes within the form. The form has a numeric input box that, when the value of the input box changes, displays the result of some calculation based on that value. This form can be submitted to the server and therefore requires a validation check, which may be in a validation library somewhere else. You might want to disable this form until you’re sure that the JavaScript code somewhere is fully loaded, and the logic is elsewhere. Maybe you need to deal with some return values when the form is submitted. There’s nothing particularly surprising about the features, but together they’re easy to confuse. If a new developer takes over the project, how will he be able to figure out the logic when he sees the form?
The React framework encourages the encapsulation of logic into components. So the form is either a component by itself or made up of other widgets. Each component handles only the logic that is directly related to it.
The React framework says: Well, you won’t see the DOM change directly, because THE DOM is mine and you can’t manipulate it directly. Why don’t you think of these things as part of the state and change the state when needed? I’ll take care of the other things and re-render the interface that needs to be rendered.
It should be said that the React framework alone is not enough to solve noodle code. Because states can show up in all sorts of weird places, or they can be called badly, or they can be called in a weird way.
In my limited experience, the Redux library really solves the problem of spaghetti code. I deal with all the important states, which are global and not component-dependent, Redux said. I’m the only source of data. If you need to change your state, adopt a certain ritual (I’ve heard it called that, and I like to call it that). All changes follow this ritual through reducers and dispatched Actions.
If you’re going to include Redux (or a variant of Redux) in your project, you can kiss hard coding goodbye. By adding the Redux framework, components become highly cohesive and it is easy to figure out the logic of the requirements.
✅ has a lot of DOM to manage
Handling the DOM manually is probably the biggest cause of spaghetti code.
-
Insert a paragraph of HTML here!
-
Separate something out here!
-
Listen for specific events in specific areas!
-
Bind a new event here!
-
Here’s something new. Insert it into the HTML again and make sure it binds the correct event!
This kind of thing can happen anywhere in an app, at any time, which makes spaghetti code. Manual management is not a good idea, because doing so will turn you back into a DOM data source. It’s hard to know exactly what’s going on with a given element, so everyone just queries the DOM, does what they have to do, and hopes to God they’re not disturbing anyone else.
The React framework says: You don’t need to manipulate the DOM directly. I use the virtual DOM to work with the real DOM. If you want to manipulate the DOM, you can do it directly in the virtual DOM. In this way, all logic is traceable.
Managing the complex DOM is another thing that suits the React framework. Imagine a chat application where when the database receives new chat messages from other chatters, the new messages should be displayed in the chat window. Otherwise you’ll have to talk to yourself! Or when the chat page is first loaded, you can pull out a few old messages from your local database and display them so you have something to look at immediately. Take the Twitter example.
❌ simply because the React framework is currently the most popular.
Learning new things is cool, so learn!
Building projects to meet user needs requires a little more caution.
For example, a blog might not have complex logic and would not fit the React framework at all. So if it doesn’t fit well, it probably doesn’t fit well with the React framework. Because it introduces complex technology and relies on a lot of things that are not available.
Between a good fit and a bad fit, if the blog is a SPA (” single page application “, no browser refresh required), the blog is built with data from a Headless CMS, and has excellent server-side rendering… Well, maybe it’s the domain of the React framework.
What if a Web App CMS created this blog? Maybe React is a good choice because it also has a bunch of states.
❌ I just love JavaScript and just want to write anything with it.
I often amway around people: learning JavaScript. Because there’s so much JavaScript knowledge. It does a lot of things, and there are a lot of jobs, so learning JavaScript well will never go out of style.
Only in the recent history of web technology has Javascript been able to do everything. You build the server from Node.js, and there are many projects that handle CSS through JavaScript. Now with the React framework, you can also write HTML in JavaScript.
Everything belongs to JavaScript! JavaScript, live forever!
React is awesome, but just because you can use React doesn’t mean you have to. Not all projects need to use it, and in fact, quite a few may not need it at all.
☯️ that’s all I know.
(Yes or no ICONS can be found, but the meaning of maybe is more complicated.)
You’re learning. That’s great. Everyone is learning, so keep learning. The more you know, the better you know what technology to use.
But a lot of times you can only build projects with existing technology, so I’m not going to hammer this point home.
☯️ This is the job.
Not everyone has the right to decide what technology should be used in any given project. Hopefully, over time, you’ll be able to influence decisions on a larger scale. Eden says she spent two years studying Ember because that’s what she does. No offense, but if you take a man’s money, you take a man’s evil. Ember might be a good fit.
- What projects need React? All need! The translator sun
The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. Android, iOS, React, front end, back end, product, design, etc. Keep an eye on the Nuggets Translation project for more quality translations.