Hello everyone, I am Casson.
ReactThe current stable version is 18.2, which was released in June 22. After that, no new stable version was released.
It was not until February 15 this year that the official blog revealed the plan for the next stable version. Yes, he is React19.
Why did it take more than a year to announce the plan for the next stable version?
Why did the next version jump directly to 19?
I haven’t even been promoted to 18 yet, but I’m here at 19. Do I have to learn a lot?
This article will answer these questions for you in detail.
Contents
Starting from React16
ReactThe most talked about version in recent years should be 16.8the introduction of this version Hooks, which Reacthas injected new vitality into (and even the entire front-end framework field).
v17No new features will be introduced after that . Since no new features are introduced, why release a major version (from 16 to 17)?
This is because there is an intermediate step from synchronous update to concurrent update .Reactbreaking change
For such a large framework, the upgrade process needs to be as smooth as possible. This is not only a sign of professionalism and responsibility, but more importantly, version split will cause a large number of user losses (refer to the time of the ng1upgrade anuglar2).
After upgrading to 18, I found that not many developers React团队actually upgraded to 18 and made extensive use of concurrency features (for example ).useTransition
A more common scenario is that well-known open source libraries integrate concurrency features, and developers then use these libraries directly.
Therefore, React团队change the strategy and shift the focus of iteration from empowering developers to empowering open source libraries . So, what kind of library has the largest audience? Obviously the frame.
Therefore, Reactthe focus gradually becomes – empowering the upper-layer framework, which developers use indirectly by using the upper-layer framework React.
Why do I say that React团队the strategy has been changed, instead of React团队the original plan being to empower the upper-level framework ?
If the initial plan is to empower the upper-layer framework , React团队a lot of energy will not be spent on the gradual upgrade of the version – anyway, developers will eventually use the upper-layer framework (instead of React), and the version separation of the upper-layer framework will be solved, and there is no need at all Guide developers to upgrade React.
Impact of strategic changes
The impact of the strategic change is far-reaching and widespread, which is why no new stable version has appeared for more than a year after 18.2.
The most basic impact is that the feature iteration process has changed.
ReactThe original intention of its birth was to solve Metacomplex internal front-end applications, so Reactthe previous feature iteration process was:
- New feature development completed
- New features
Reactare trialled internally in product and eventually reach a stable state - Open source for developers to use
But as the strategy changes to empowering upper-level frameworksNext.js , it is bound to require close cooperation with (mainly) mainstream upper-level framework teams .
If the original iteration process is followed, the upper-layer framework team belongs to Metaan external third-party team and can only use the new features after they are open sourced. This cooperation model is obviously too inefficient.
Therefore, Reactthe team proposed a new feature release channel – canary, that is, after the new feature is developed, it can be released canary版本的Reactfor external trial first, and then it will be considered to be added to the stable version after the feature is stable.
There may be some canaryfeatures that exist in the version that will never appear in the stable version React, but this does not prevent some open source libraries from locking canarythe version Reactand using these features.
So, why did it take more than a year to announce the plan for the next stable version? There are 4 main reasons.
Reason 1: New features mainly serve Next and there is no need to appear in the stable version.
In addition to affecting the iterative process of features , the change in strategy also puts React团队成员us in a dilemma – should I prioritize serving the upper framework or not Meta?
We can find that in the previous iteration process, everything Metarevolved around our own needs. React团队成员As Metaan employee, this iterative process comes naturally.
However, the new iteration process requires close Nextcooperation with the team, so the question arises – as Metaan employee, should new features take priority Nextor Metathe needs of employees?
In order to complete the task of empowering the upper-level framework , it is obvious that more Nextneeds should be considered. We could see some React团队成员eventually jumping ship Verceland joining Nextthe team.
Therefore, the features produced during this period (such as server action, useFormStatus, useFormState) serve more Nextthan React.
If a new stable version is released based on these features, Nextdevelopers who do not use them will not be able to use these features, and Nextdevelopers who do use them will rely on them canary React, so it is meaningless to upgrade the stable version at this time.
Reason 2: New features must meet various scenarios, and delivery is difficult
NextYes web框架, the new features created around him Reactonly need to be considered webin this scenario.
But Reactits positioning is 宿主环境无关的UI库that there are still a large number of developers 非webusing it in environments React(for example React Native), so for these features to appear in the stable version React, it must be ensured that it can adapt to all environments.
For example, Server Actionsthis feature is used to simplify the process of sending data between the client and the server . It is currently mainly used in the Nextmode App Router.
For example, for the component in the code below MyForm, when the form is submitted, the logic of the function will be executed on the server side, so that operations (such as operating the database) serverActioncan be easily performed :IO
// Server side code
async function serverAction ( event ) {
'use server'
// Process server-side logic here, such as database operations, reading and writing, etc.
}
function MyForm () {
return (
< form action = {serverAction} >
< input name = "query" />
< button type = "submit" > Search </ button >
</ form >
);
}
App RouterThe scene is mainly RSC(React Server Component). In addition RSC, SSRis there also a form in the scene? Without using server-side functions and simply using Reactclient-side rendering, is there also a form scenario?
Therefore, Server Actionsthe feature was later renamed Actionsbecause not only Serverscenes but other scenes must be supported Actions.
For example, in the following code, the scene rendered on the client uses Actionsfeatures:
//Front-end code
const search = async ( event ) => {
event. preventDefault ();
const formData = new FormData (event. target );
const query = formData. get ( 'query' );
// Use fetch or other methods to send data
const response = await fetch ( '/search' , /*omitted*/ );
// ...process the response
};
function MyForm () {
return (
< form action = {search} >
< input name = "query" />
< button type = "submit" > Search </ button >
</ form >
);
}
Do you think this is the end? Still early. formComponent support Actions, can developer-defined components support Actionsthis front-end and back-end interaction mode ?
For example, the following Calendarcomponent previously onSelectinteracted through event response:
< Calendar onSelect = {eventHandler} >
Can we use Actionsthe following modes to respond to interactions in the future:
< Calendar selectAction = {action} >
How do you turn a mundane interaction into Actions交互one? React团队The answer given is – use useTransitionpackages. Therefore, this later involves useTransitionmodification of functions.
ActionsThis is just an example. It can be found that although new features start webwith the , in order to appear in the stable version, they need to end up covering the entire scenario , which naturally increases the difficulty of delivery.
Reason 3: There are more and more scenarios where old features need to be compatible, which requires a lot of work.
There are more and more new features, and old features must be modified to be compatible with these new features, which requires a lot of time to develop and test.
To give two examples, Suspenseintroduced in v16.6, it allows components to “wait” for some content to become available and display a loading indicator (or other fallback content) during this time .
SuspenseInitially, only lazy loading of components ( React.lazy) is supported. As Reactnew features continue to emerge, Suspensethey are gradually compatible with the following scenarios:
ActionsWaiting scene after submission- Waiting scenarios for concurrent updates
Selective Hydrationloading sceneRSCStreaming waiting scenario- any
data fetchingscene
In order to be compatible with these scenarios, Suspensethe amount of code is already very scary, but developers are unaware of this.
SuspenseLet ’s give another useEffectexample related to these two characteristics.
SuspenseWhy can I switch between the intermediate state and the completed state ? It’s because in Suspensethe source code, there is an internal Offscreencomponent that is used to complete Fiber树the switching of the two pieces.
React团队I hope to Offscreenseparate the component into a separate new feature (the new name is Activitycomponent), which will play a similar role Vueto Keep-Alivethe component.
ActivitySince the component can make the component visible/hidden, it will inevitably affect useEffectthe triggering timing of the component. After all, useEffect createit would be weird if a component is hidden but its function is triggered.
Therefore, in order to implement Activitycomponents, useEffectthe triggering logic will become more complicated.
Reason 4: Features must form a system before they can be delivered
React团队Although many features have been developed this year , many features cannot be delivered individually and must be formed into a system before being delivered uniformly.
useFormStatusFor example , the ones just mentioned useFormStateserve Actionsthe characteristics, Actionsare Server Actionsevolved, Server Actionsand are RSCcharacteristics under the (React server component) system.
useFormStatusIt makes no sense to release it in the stable version alone , it is RSCpart of the system.
Therefore, even if the new features are ready, if the system it is in is not ready, all the features under the system cannot be delivered in the stable version.
Summarize
Why did it take more than a year to announce the plan for the next stable version? Mainly for 4 reasons:
- New features mainly serve Next and do not need to appear in the stable version.
- New features must meet various scenarios and are difficult to deliver
- There are more and more scenarios where old features need to be compatible, which requires a lot of work.
- Features must form a system before they can be delivered
So why is the next stable version not v18.x but v19? This is because some new features (mainly Asset Loadingthese Document Metadatatwo types of features) will be produced for some applications breaking change, so a major version needs to be released.
From the fourth point among the above four reasons, we can know that since there is news about v19, it must be because there are already a system of new features that can be delivered . Does that mean that there is a lot to learn?
Don’t worry about this. If you don’t use it Next, you will most likely not be exposed to it RSC. Since you won’t be exposed to it RSC, RSCyou won’t be able to use the new features in the system.
The biggest impact v19 will have on you may be the impact of new features on old APIs, such as:
useContextbecomeuse(promise)ActivityComponents makeuseEffectthe triggering timing more complex (should not be in the first version of v19)
The cost of learning these is not high.
Further news about v19 will be announced at React Conf on May 15th and 16th this year .