Adoption strategies for meta-frameworks

[wardpeet]

React 18 is packed with new features and goodies. There is a lot to unpack, which can lead to information overload. To make the transition to React 18 smoother for everyone, we should keep adoption strategies consistent in frameworks (Create react app, Gatsby, NextJS, ...). It would help developers adopt React 18 in any framework of their choosing and gather as much feedback as possible to make React 18 even better!

Let's break down each feature and adoption strategy so developers can switch frameworks without too much hassle.

New Root API

It is enabled by default when React 18 is installed. Developers can opt-out by disabling it with REACT_LEGACY_ROOT=true.

Streaming SSR

I'm also inclined to enable it by default when React 18 is available. The only problem that I see is that tools like emotion, styled-components, react-helmet capture data while rendering. They do support streaming, but it's not as optimized as renderToString. (for CSS-in-JS as every new "style" tag triggers a layout)

My suggestion is to keep it simple and have the same REACT_LEGACY_ROOT flag/option to opt-out.

New Hooks (useTransition, useDeferredValue, ...)

The new hooks will most likely live in userland, so a framework doesn't need to take care of it directly. However, if frameworks start implementing these hooks inside their router, form abstractions, data abstractions, it will also be automatically enabled by default. Opting out of these features will use need "custom" flags/options. For example, REACT_USE_TRANSITION=false doesn't make much sense, but GATSBY_CONCURRENT_ROUTER=false hopefully does.

We should align on how we call these features. In the example case, do we call it CONCURRENT_ROUTER, or is there a better name than CONCURRENT for these features?

Server Components

I haven't played enough with server components to actually understand how "breaking" it is for our users when developing applications. So I don't have any opinion yet on which opt-in/opt-out strategy to use here.

What features did I not mention? Any recommendations on the name, strategies would be fantastic! I'll update this post with pieces that come up from the discussion.

[markerikson]

It's not clear what these flags are that you're referring to. Are you proposing that different frameworks should each create some kind of identical environment variables for consistency?

[gaearon]

Ideally it would be good to align on overall strategy between frameworks, even if flag names are different.

[markerikson]

Agreed, I'm just not sure what's actually being proposed here. Like, what is REACT_LEGACY_ROOT? An environment variable? A config flag? Who defines it? What uses it? Where does it get set?

[wardpeet]

I updated the discussion to reflect frameworks a little bit more. Flag names are not super important, but if the jargon is equal, things will be easier. If Gatsby calls prefixes everything with LEGACY and NextJS with CONCURRENT I do think it gets confusing what features are enabled

[wardpeet]

Agreed, I'm just not sure what's actually being proposed here. Like, what is REACT_LEGACY_ROOT? An environment variable? A config flag? Who defines it? What uses it? Where does it get set?

That depends on how the framework has its triggers. For Gatsby it's flags, for NextJS it's flags (I think), and for CRA it's env vars

[devknoll]

In Next.js, we have a config.reactRoot flag to opt-in to use createRoot. This defaults to false for now but will warn when using React 18 and default to true when it's detected in the future. This only controls whether we use the new API. It was important that we don't enable any additional new functionality with this flag, as we want as many applications as possible to enable it, and any other behavior or API changes could potentially block that (e.g. their CSS-in-JS library isn't supported, or they need to wait until they can design new loading states because the router started suspending).

It's important for Next.js that applications are able to selectively and/or gradually roll out concurrent features to their pages, or in the case of legacy, unsupported pages, potentially never. This means that a single flag to enable transitions isn't enough for us. Instead, the current plan is to provide a <LegacySync> component that always forces a subtree to render synchronously, even if it was part of a transition. This would be used to selectively and dynamically opt out parts or pages of an app that don't work with time-slicing (at the cost of a bit of loss in performance).

Finally, we're planning to have a single config.concurrentFeatures flag in addition to config.reactRoot that is used to opt-in to using transitions in the router, suspense in the framework, and so on, and we'll encourage you to enable it and guide you through the process when React 18 and config.reactRoot: true.

[devknoll]

For Server Components in Next.js, we're still actively working with the React team to figure this out, so this is highly subject to change.

That said, our current plan is that there will be no changes for applications (actually, most of the changes will already be done by adopting Suspense). Instead, you opt-in to using Server Components on a page-by-page basis by simply creating a pages/foo.server.js instead of pages/foo.js. Under the hood, we'd automatically generate a Server Component for "legacy" pages.

[wardpeet]

We're thinking in the same vane here 👍