Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

How to deal with data flow in React

2025-01-19 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Development >

Share

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

Most people do not understand the knowledge points of this article "how to deal with data flow in React", so the editor summarizes the following content, detailed content, clear steps, and has a certain reference value. I hope you can get something after reading this article. Let's take a look at this "how to deal with data flow in React" article.

Background

I believe that in the project development, in the case of more complex pages, we will often encounter a problem, that is, communication between page components will be very difficult.

For example, a list of items and a list of added items:

If the two lists are separate components, they will share a data "selected item". Selecting an item in the item list will affect the added item list and delete an item from the added list. it also affects the selected status of the item list.

They are two sibling components, without the help of the data flow framework, when there are changes in the data within the component, data can only be transmitted through the parent component, and there is often a function like onSelectedDataChange. In this case, it is still bearable. If the components are deeply nested, the pain can be imagined, so there are various frameworks to solve the data flow.

Essential analysis

We know that React is the V in MVC and is a data-driven view. To put it simply, it is a data = > view, which is a data-based rendering result:

V = f (M)

When the data is updated, before entering the rendering, it will be changed into Virtual DOM, and the data will be compared before and after the rendering, and then the real rendering will be carried out only when there are changes.

V + Δ V = f (M + Δ M)

There are two ways of data-driven view change, one is setState, which changes the state of the page, and the other is to trigger the change of props.

We know that data will not change itself, so there must be "external forces" to promote it, often remote requests for data return or interactive behaviors on UI, which are collectively referred to as action:

Δ M = perform (action)

Each action will change the data, so the data (state) obtained by the view is the superimposed change of all the action.

State = actions.reduce (reducer, initState)

So the real scene will be as follows or more complex:

The problem lies in that it is troublesome and confusing to update the data. Every time we update the data, we have to transfer it layer by layer. When the interaction of the page is complex, it is impossible to control the data.

Is there a way to centrally manage data and centrally deal with the receipt, modification and distribution of data? The answer is obviously yes, the data flow framework is to do this thing, if you are familiar with Redux, you will know that what is mentioned above is the core idea of Redux, which matches the data-driven principle of React.

Data flow framework

Redux

At present, the data flow framework is dominated by Redux, which provides a global Store to deal with the reception, modification and distribution of application data.

Its principle is relatively simple. If there is any interaction in the View that needs to change the data, first send an action, the action is received by the Store and handed over to the corresponding reducer for processing, and then the updated data is passed to the View. Redux does not depend on any framework, it just defines a way to control the flow of data, which can be applied to any scenario.

Although a set of data transfer methods are defined, there will be a lot of problems in actual use. I personally summarize that there are mainly two problems:

The definition is too cumbersome and there are many documents, which can easily lead to a leap in thinking.

There is no elegant solution to the handling of asynchronous flow.

Let's take a look at an example of writing a data request, which is a very typical case:

Actions.js

Export const FETCH_DATA_START = 'FETCH_DATA_START'

Export const FETCH_DATA_SUCCESS = 'FETCH_DATA_SUCCESS'

Export const FETCH_DATA_ERROR = 'FETCH_DATA_ERROR'

Export function fetchData () {

Return dispatch = > {

Dispatch (fetchDataStart ())

Axios.get ('xxx') .then ((data) = > {

Dispatch (fetchDataSuccess (data))

}) .catch ((error) = > {

Dispatch (fetchDataError (error))

});

}

}

Export function fetchDataStart () {

Return {

Type: FETCH_DATA_START

}

}

... FETCH_DATA_SUCCESS

... FETCH_DATA_ERROR

Reducer.js

Import {FETCH_DATA_START, FETCH_DATA_SUCCESS, FETCH_DATA_ERROR} from 'actions.js'

Export default (state = {data: null}, action) = > {

Switch (action.type) {

Case FETCH_DATA_START:

...

Case FETCH_DATA_SUCCESS:

...

Case FETCH_DATA_ERROR:

...

Default:

Return state

}

}

View.js

Import {createStore, applyMiddleware} from 'redux'

Import thunk from 'redux-thunk'

Import reducer from 'reducer.js'

Import {fetchData} from 'actions.js'

Const store = createStore (reducer, applyMiddleware (thunk))

Store.dispatch (fetchData ())

The first question is to send a request, because you need to host all the states of the request, so you need to define a lot of action, so it's easy to get dizzy, and even if someone tries to encapsulate these states again, it will be full of template code. Some people will challenge that although it is troublesome and tedious at the beginning, it is friendly to the maintainability and expansibility of the project. I don't quite agree with this view. At present, it is still simple. When the real business logic is complex, it will look even more disgusting, inefficient and have a poor reading experience. I believe you have written or read such code. If you look back later, you need to search the actions file for the name of action. Inquire about the reducer file and read it around slowly.

The second problem, according to the officially recommended method of using redux-thunk to achieve asynchronous action, as long as a function is returned in action, which is simply unbearable for people with obsessive-compulsive disorder. Actions file appears to be very impure. Originally, it is only to define action, but it is interspersed with data requests and even interactions on UI.

The above is about the content of this article on "how to deal with data flow in React". I believe we all have a certain understanding. I hope the content shared by the editor will be helpful to you. If you want to know more about the relevant knowledge, please follow the industry information channel.

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.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Development

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report