Shulou(Shulou.com)06/01 Report--

This article mainly introduces the relevant knowledge of "react use case analysis". The editor shows you the operation process through the actual case, and the operation method is simple, fast and practical. I hope this "react use case analysis" article can help you solve the problem.

Why introduce React?

When writing React, you might write code like this:

Import React from 'react'function A () {/ /... other code return front end Taoyuan}

You must have wondered why React is introduced when none of the following code uses React.

If you delete import React from 'react', you will still report an error.

So what exactly is the use of this React, leading to the introduction of React will report an error, do not understand this reason, then JSX is not too clear.

You can convert the above code (ignoring the import statement) into an online babel and find that babel will convert the above code into:

Function A () {/ /... other code return React.createElement ("H2", null, "Front-end Taoyuan");}

Because in essence, JSX is just a syntactic sugar for React.createElement (component, props,... children) functions.

Why use className instead of class

The original idea of React was to stay with the browser's DOM API rather than HTML, because JSX is an extension of JS, not a substitute for HTML, which is closer to the creation of elements. To set class on an element, you need to use the API of className:

Const element = document.createElement ("div") element.className = "hello"

Browser problem, reserved words cannot be used in objects before ES5. The following code will throw an error in IE8:

Const element = {attributes: {class: "hello"}}

Deconstructing problems, when you are deconstructing attributes, there will be problems if you assign a class variable:

Const {class} = {class: 'foo'} / / Uncaught SyntaxError: Unexpected token} const {className} = {className:' foo'} const {class: className} = {class: 'foo'}

Other discussions can be seen: the interesting topic, why jsx uses className instead of class

Why do attributes use small humps?

Because JSX is syntactically closer to JavaScript than HTML, React DOM uses camelCase (small hump naming) to define the name of the attribute rather than the naming convention for HTML attribute names.

From introduction to JSX

Why call super and pass props in constructor

This is a piece of code from the official website. For details, see State and Lifecycle.

Class Clock extends React.Component {constructor (props) {super (props); this.state = {date: new Date ()};} render () {return (Hello, world! It is {this.state.date.toLocaleTimeString ()}. );}}

And there is a passage that lets us not only call super but also pass props in, but it doesn't tell us why.

I don't know if you've ever wondered why you called super and passed props, but let's solve the puzzle.

Why call super?

In fact, this is not the restriction of React, this is the restriction of JavaScript. In the constructor, if you want to call this, you have to call super in advance. In React, we often initialize state,this.state = xxx in the constructor, so you need to call super.

Why pass props

You may think that you must pass props to super, otherwise React.Component will not be able to initialize this.props:

Class Component {constructor (props) {this.props = props; / /...}}

However, if you accidentally omit props and call super () directly, you can still access this.props in render and other methods (try it if you don't believe it).

Why is this okay? Because React will assign props to the instance object you just created after the constructor is called:

Const instance = new YourComponent (props); instance.props = props

There is a reason why props can be used without passing it.

But does this mean that you can use super () instead of super (props) when using React?

That still won't work, otherwise the official website won't advise you to call props. Although React assigns a value to this.props after the constructor runs, this.props still doesn't work after the super () call and before the constructor ends.

/ / Inside Reactclass Component {constructor (props) {this.props = props; / /...}} / / Inside your codeclass Button extends React.Component {constructor (props) {super (); / / forgot to pass in props console.log (props); / / {} console.log (this.props); / / undefined} / /.}

If a method that accesses the props is called in the constructor, the bug is even more difficult to locate. So I strongly recommend that you always use super (props), even if it is not necessary:

Class Button extends React.Component {constructor (props) {super (props); / / We passed props console.log (props); / / {} console.log (this.props); / / {}} / /.}

The above code ensures that this.props always has a value.

If you want to avoid the above problems, you can simplify the code through the class attribute proposal:

Class Clock extends React.Component {state = {date: new Date ()}; render () {return (Hello, world! It is {this.state.date.toLocaleTimeString ()}. );}}

For more details, see Dan's blog.

Why do components start with uppercase

As mentioned earlier, JSX is React.createElement (component, props, … Children). The type of component is: string/ReactClass type. Let's take a look at when the string type will be used and when the ReactClass type type will be used.

The string type react will think he is a native dom node.

ReactClass type type custom component

For example (string): in jsx we write a

When converted to js, it becomes

React.createElement ("div", null)

For example (ReactClass type): in jsx we write a

Function MyDiv () {return ()}

When converted to js, it becomes

Function MyDiv () {return React.createElement ("div", null);} React.createElement (MyDiv, null)

In the example above, if you lowercase the first letter in MyDiv, as follows

Function myDiv () {return ()}

When converted to js, it becomes

Function MyDiv () {return React.createElement ("div", null);} React.createElement ("myDiv", null)

Because the dom of myDiv cannot be found, an error will be reported.

Why do you need bind this to call a method

Premise knowledge: a deep understanding of this in JavaScript

I believe that when I first wrote React, many friends might write code like this:

Class Foo extends React.Component {handleClick () {this.setState ({xxx: aaa})} render () {return (Click me)}}

If you find that you will report that this is undefined's fault, then you may be confused about event handling, and then go to the official website for event handling. There is the following paragraph:

You must be careful with the this in the JSX callback function. In JavaScript, the class method is not bound to this by default. If you forget to bind this.handleClick and pass it into onClick, the value of this is undefined when you call this function.

This is not specific to React; it really has something to do with how the JavaScript function works. In general, if you don't add () to the method, such as onClick= {this.handleClick}, you should bind this to the method.

Then, after looking at the examples and suggestions on the official website, you know that you need to bind this to the event handler to solve the problem, like this:

Class Foo extends React.Component {handleClick () {this.setState ({xxx: aaa})} render () {return (Click me)}}

But maybe you haven't thought about why you need bind this? If you can't understand it, the foundation of js is not well laid.

How does React handle events?

Let's first take a look at how React handles events.

The event of React is a synthetic event, and the internal principle is very complex. I will only introduce the key part of the principle that can be used to solve this question (I will write an article on the event principle of react later, please look forward to it).

As mentioned in the previous article, jsx is actually React.createElement (component, props, … The syntax sugar provided by the children) function, then this jsx code:

Click me

Will be converted into:

React.createElement ("button", {onClick: this.handleClick}, "Click me")

Understand the above, and then simply understand how react handles events. When React loads (mount) and updates (update) components, it registers events on document through addEventListener, and then there is an event pool that stores all events. When events are triggered, events are distributed through dispatchEvent.

So you can simply understand that eventually this.handleClick will be called as a callback function.

Understand this, and then look at why the callback function loses this.

A brief Review of this

Within the function, the value of this depends on how the function is called.

If you can't understand the above sentence, then you may need to stop to read the article and check the relevant information, otherwise you may not understand the following, if you are lazy, look at the MDN prepared for you.

Through the introduction to event handling above, we simulate that in the render function of a class component, it is somewhat similar to doing something like this:

Class Foo {sayThis () {console.log (this); / / who does `this` here point to? } exec (cb) {cb ();} render () {this.exec (this.sayThis);}} var foo = new Foo (); foo.render (); / / what is the output?

You will find that the final output is undefined, if you do not understand why the output is undefined, then it is still mentioned above, you need to have a deep understanding of the principle of this. If you can understand that the output is undefined, then I think you can understand why you need bind this.

So you might ask: why doesn't React automatically integrate bind into the render method? Bind it when exec calls the callback, like this:

Class Foo {sayThis () {console.log (this); / / who does `this` here point to? } exec (cb) {cb () .bind (this);} render () {this.exec (this.sayThis);}} var foo = new Foo (); foo.render (); / / what is the output?

Because bind is required for multiple calls to render will affect performance, it is officially recommended that you manually bind in constructor to achieve performance optimization.

Comparison of four kinds of event handling

There are also several ways to write event handling, let's compare it:

1. Direct bind this type

As the article begins, bind this directly at the event.

Class Foo extends React.Component {handleClick () {this.setState ({xxx: aaa})} render () {return (Click me)}}

Pros: it's easy to write, and you can write this logic in one breath without having to move the cursor to another place.

Disadvantages: the performance is not very good, this way is the same as react internal help you bind, every time render will be bind, and if there are two elements of the event handling function is the same, but also to bind, this will write more code, and bind twice, the performance is not very good. (in fact, this performance is often not the bottleneck of performance, if you feel comfortable, it is no problem to write this way.)

2. Constuctor manual bind type

Class Foo extends React.Component {constuctor (props) {super (props) this.handleClick = this.handleClick.bind (this)} handleClick () {this.setState ({xxx: aaa})} render () {return (Click me)}}

Pros: better performance than the first, because the constructor is only executed once, then it will only bind once, and if there are multiple elements that need to call this function, there is no need to repeat bind, which basically solves the two shortcomings of the first.

Disadvantages: there are no obvious shortcomings, the words you have to say are too ugly, and then it's not easy (I think it's ugly, just write it if you don't think it's ugly).

3. Arrow function type

Class Foo extends React.Component {handleClick () {this.setState ({xxx: aaa})} render () {return (this.handleClick (e)} > Click me)}}

Advantages: easy to use, good-looking.

Cons: each time render will repeat the creation of functions, the performance will be a little poor.

4. Public class fields type

This kind of class fields is still in the experimental stage and has not been included in the standard as far as I know, which can be found here.

Class Foo extends React.Component {handleClick = () = > {this.setState ({xxx: aaa})} render () {return (Click me)}}

Advantages: good-looking, good performance.

Disadvantages: there are no obvious shortcomings, if you insist, it may be to install an additional babel plug-in to support this syntax.

Summary

I usually use these four writing methods, and I have made a simple comparison of various writing methods from the aesthetics, performance and convenience of the code. In fact, there is no problem with the use of each method in the project, and the performance is basically negligible, and it is subjective for aesthetics and ease of use, so generally speaking, it depends on everyone's preference, if you insist on recommending it. I still recommend the fourth way of writing, which is beautiful and does not affect performance.

Why setState instead of directly this.state.xx = oo

This question is our company's back-end to write React when the question, why can not directly modify the state, to setState. I was thinking that there might be the same problem with moving from vue to React, because the state of vue changes are changed directly.

If we understand the principle of setState, we may be able to answer this question. SetState does not only change the value of this.state, but also, most importantly, it triggers the update mechanism of React, diff, and then updates the patch part to the real dom.

If you directly this.state.xx = = oo, the value of state does change, but the change will not trigger the update of UI, so it is not data-driven.

So why can Vue directly modify data to trigger UI updates? Because Vue collects the data when it creates the UI and overrides the accessor property setter of these data, the update of the UI is triggered in this rewritten method. If you want to know more about the principle of vue, you can buy the analysis of the internal operation mechanism of Vue.js.

Those who do not understand the properties of the accessor can read this article: in-depth understanding of objects in JS

Whether setState is synchronous or asynchronous

1. Is setState synchronous or asynchronous?

My answer is that the execution process code is synchronous, but the call order of composite events and hook functions is not immediately available in composite events and hook functions before updating, in the form of the so-called "asynchronous". So it is sometimes synchronous, sometimes "asynchronous".

two。 When is synchronous and when is asynchronous?

It is "asynchronous" only in composite events and hook functions, and synchronous in native events and native API such as setTimeout/setInterval. It can be simply understood that functions controlled by React will show "async" and vice versa as synchronization.

3. Then why is there an asynchronous situation?

In order to optimize the performance, delaying the update of state to the final batch merge and then rendering is of great benefit to the application's performance optimization. If you re-render the real dom every time the state changes, it will bring huge performance consumption.

4. So how can you accurately get the updated state in a function that shows async?

Get the updated result through the callback in the second parameter setState (partialState, callback).

Or you can show synchronization by passing a function to setState:

This.setState ((state) = > {return {val: newVal}})

5. What about the principle of showing asynchronism?

I will let you understand in the simplest language here: in the implementation of React's setState function, it will determine whether to update this.state directly or put it in the queue for later update based on the isBatchingUpdates (default is false) variable. Then there is a batchedUpdate function that can change isBatchingUpdates to true, and the batchedUpdate function will be called before React calls the event handler, or before the lifecycle function, so that setState will not update the this.state synchronously, but put it in the update queue for subsequent updates.

In this way, you can understand why native events and calling this.state in setTimeout/setinterval are updated synchronously, because the React called through these functions cannot call the batchedUpdate function to set isBatchingUpdates to true, so setState defaults to false at this time, and updates will be synchronized.

This is the end of the content of "react usage case Analysis". Thank you for your reading. If you want to know more about the industry, you can follow the industry information channel. The editor will update different knowledge points for you every day.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.