Please think about a question: if there is a HTML tag, and React has two hook around it, then this tag must be very important for the future development of React . Is that all right? The tag is-- form . React around form , there are two new hook : useOptimistic useFormStatus this article will talk about the layout and development of React around form . the development of Next.js speaking of the future development of React , we must start with Next.js . After all, React team members either join the Next team or are on their way. web the parts of development that involve front-end interaction mainly include: render the front-end page based on the back-end data Save data to the backend according to the input of the front-end user The development of Next.js mainly focuses on the above two points. render the front-end page based on the back-end data in the earlier stage, the main features of Next.js are SSR , SSG . That is, the process of rendering the front-end page based on the back-end data is moved from the front-end to the back-end. the Next.js route for this period is called Pages Router . time comes to Next.js v13 . App Router with RSC (React Server Component) as the core replaces Pages Router as the default configuration. many friends are not familiar with RSC and regard it as an experimental feature. In fact, RSC has landed via Next.js . one sentence understanding RSC -client components ( React components rendered in the browser) can be…

Let's talk about the conclusion first useCallback, useMemo, memo, shouldUpdate, performance optimized API, you should not use it without performance problems. Blind use will lead to negative optimization and even delay closure bug. This conclusion is a consensus. but this is only one aspect. I mainly want to talk about it to the point, except for the ideas that API,React really reduces rerender. the coarse granularity of React may hurt innocent people. The agility of jsx, the culprit, makes it difficult for props to distinguish between change and immutability App is a component and Box is a subcomponent const App = ()=>{ return <Box h="200px" w="200px" {/*.....*/}>hello</Box> } // after jsx is compiled const App = ()=>{ return /*#__PURE__*/ React.createElement(Box, { h: "200px", w: "200px" }, "hello"); }; The strategy adopted by React is congruent comparison. Props compares {h: "200px", w: "200px"} in the first time with {h: "200px", w: "200px"} in the second round. Although it seems to be the same, function creates a new object type every time, with a different address, rendering even empty objects, like flood discharge, rendering from the top of the head to the soles of the feet. Box will be rendered const App = () => { return <Box>hello</Box> // Box without memo, still render } // after jsx is compiled const App = () => { // props is an empty object here return /*#__PURE__*/ React.createElement(Box, {}, "hello"); }; this is React's App-level update policy. Why do you adopt such a strategy? Because there are too many props, suppose it is a…

there is a sentence that I believe everyone has heard: the replacement of instant noodles is not the more advanced instant noodles, but the rise of takeout the same phenomenon exists in the front-end domain. As a leader in the front-end cache, React-Query has always had a large audience, and the official React-Query courses have sold 8w + copies. but it is such a hit product that there is a risk of being eliminated. Why on earth? Nature of the front-end cache React-Query is located as front-end cache . If you understand the library from a front-end perspective, you might think of it as an enhanced version of axios . but to understand the nature of this library, we need to start from a back-end perspective. in the view of the back end, the back end is responsible for providing the data, and the front end is responsible for displaying the data, so: how should the front end render after the data is updated? After data invalidation, how should the front end render? In essence, this is a data / cache synchronization problem, but in the SPA era, this problem happens to be left to the front end. however, the back end is inherently closer to the data, and it has an advantage to solve this problem. So as rendering tasks gradually move to the back end, React-Query (or similar libraries) gradually lose market. To sum up: what replaces React-Query is not a more advanced competition, but that the soil in which it exists is gradually disappearing. change of SSR…