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

Editor to share with you what Redux is, I believe that most people do not know much about it, so share this article for your reference, I hope you will learn a lot after reading this article, let's go to understand it!

Redux is a revolutionary technology in the React ecosystem. It enables us to store immutable data globally and solves the problem of prop-drilling in the component tree. When you need to share immutable data between applications, it is still an excellent tool that can be easily extended.

Problems with single-page applications

The emergence of single-page applications (SPA) such as React has brought many changes to the way we develop Web applications. It separates our back-end from the front-end code, allowing us to focus and separate our concerns. It also introduces a lot of complexity around the state.

Now, getting data asynchronously means that the data must be located in two places: the front end and the back end. We must consider how best to store this data globally so that it is available to all of our components while keeping the data cached to reduce network latency. Now, a large part of the burden of front-end development comes from the maintenance of our global storage, and we also need to ensure that these stores are not plagued by state errors, data non-normalization, and stale data.

Redux is not a cache

One of the big problems that most people encounter when using Redux and similar state management libraries is that we think of it as a cache of back-end state. We take the data, add it to the storage through reducer/action, and retrieve it periodically to make sure it is up-to-date.

We do so much with Redux that we even see it as a comprehensive solution to the problem.

The point is that our front-end and back-end states are never really synchronized, and at best we can create the illusion that they are synchronized. This is one of the shortcomings of the client-server model, and that's why we need caching. However, synchronizing caching and holding state is very complex, so we should not recreate this back-end state from scratch, as Redux encourages.

When we started recreating the database at the front end, the boundaries of responsibility between the back end and the front end quickly became blurred. As front-end developers, we don't need a complete understanding of tables and their relationships to create a simple UI.

Nor do we need to know how to standardize our data at a high level. This responsibility should fall on those who design the table (back-end developers). Back-end developers can then provide abstractions to front-end developers in a documented form of API.

Now, countless libraries (redux-observable, redux-saga, redux-thunk, etc.) have been built around Redux to help us manage back-end data, each of which adds another layer of complexity to already tedious libraries. I believe most of them have failed to achieve their goals. Sometimes in order to move forward. We need to take a step back.

What if we no longer manage the back-end state in the front-end code and just think of it as a cache that needs to be updated regularly? When we think of the front end as a simple display layer that reads content from the cache, our code becomes easier to use and more suitable for pure front-end developers to read. We reaped all the benefits of separating concerns while avoiding most of the disadvantages of building SPA.

A simpler approach to back-end state

I think there are two libraries that are much easier to use than using Redux (or similar state management libraries) to store back-end state.

React Query

I've been using React Query on most of my personal and work projects for months. This library has a very simple API and several hooks for managing queries (getting data) and mutations (changing data).

Since using React Query, I have not only improved my efficiency, but also ended up writing 90% less boilerplate code than Redux. I find it easier to focus on the UI/UX of the front-end application instead of worrying about the entire back-end state all the time.

To compare this library with Redux, let's look at a code example of both methods. I implemented a simple TODO list fetched from the server using regular JS, React Hooks, and axios.

First, Redux implementation: import React, {useEffect} from "react"; import {useSelector, useDispatch} from "react-redux"; import axios from 'axios';const SET_TODOS = "SET_TODOS"; export const rootReducer = (state = {todos: []}, action) = > {switch (action.type) {case SET_TODOS: return {... state, todos: action.payload}; default: return state;}} Export const App = () = > {const todos = useSelector ((state) = > state.todos); const dispatch = useDispatch (); useEffect () = > {const fetchPosts = async () = > {const {data} = await axios.get ("/ api/todos"); dispatch ({type: SET_TODOS, payload: data});}; fetchPosts ();}, []) Return ({todos.length > 0 & & todos.map ((todo) = > {{todo.text}}));}

Note that you haven't even started to deal with refetching, caching, and invalidation at this point, just loading the data and storing it in global storage at load time.

The same example of React Query implementation: import React from "react"; import {useQuery} from "react-query"; import axios from "axios"; const fetchTodos = () = > {const {data} = axios.get ("/ api/todos"); return data;}; const App = () = > {const {data} = useQuery ("todos", fetchTodos); return data? ({data.length > 0 & data.map ((todo) = > {todo.text})}): null;}

By default, the above examples include data retrieval with reasonable default values, caching, and obsolete content invalidation. You can set the cache configuration at the global level, and then you can forget about it-- generally speaking, it's enough to do the job you want.

Now, no matter what data you need, you can use useQuery hook with the unique key you set ("todos" in this case) and use asynchronous calls to get the data.

React Query provides useMutation hook when you want to change the state of the interface.

Once you start using this library, you will find that Redux is too cumbersome in most projects. After processing the data acquisition / caching portion of the application, the front end has almost no global state to process. You can use Context or useContext+useReducer to deal with the rest of the content instead of Redux.

Or better yet, use React's built-in state as your simple front-end state, which is certainly fine.

/ / clean, beautiful, and simpleconst [state, setState] = useState ()

We should separate the back end from the front end more thoroughly, rather than being caught in the middle of this ambiguity.

The above is all the content of this article "what is Redux?" thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to 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.