[Question] Server Components

[jamesisaac]

Hello!

We're finding React Native Web a very productive tool for building out UI. When a project supports iOS/Android and Web, even if the mobile UI isn't directly reused on the web, the reduced context switching of being able to use the same components and patterns across both is great. Thanks for all the work on it.

In some cases the web experience may be a single-page app, where this setup works perfectly as it is. But in others it may be desirable to take advantage of server-side rendering.

I've been having a look at the latest developments of Server Components in React, and gave it a try in the latest NextJS beta (the framework which the React team are directly collaborating with).

Unfortunately using RNWeb in this setup hits a blocker pretty early on:

• Server Components can't use Context: https://beta.nextjs.org/docs/rendering/server-and-client-components#context (can't say I fully understand this reasoning, but it seems that's the decision).
• Even the lowest level components of RNWeb like Text and View use context to detect RTL layout:

  react-native-web/packages/react-native-web/src/exports/View/index.js

  Line 86 in ca15203

  const { direction: contextDirection } = useLocaleContext();

So my question is: is supporting Server Components likely to be on the roadmap for RNWeb in the future? In which case I could stick with mostly Client Components for now, with an eye to migrate them in future versions to Server Components, and/or locally patch some components now to remove usage of client APIs like Context.

OR, is this a non-goal, and if SSR is a requirement of a project you'd suggest looking at other solutions than RNWeb?

[necolas]

I can't say I know much about server components. But I suppose the issue is related to the need for context to be present in the client.

At Meta almost all the leaf component primitives in design systems use context as well. And Meta doesn't use server components in any meaningful capacity. Even if RNW didn't use context for RTL, it still uses it in every primitive to manage the relationship between View and Text as expected in RN.

You can always SSR RNW code though. Server components are a different, experimental concept focused instead on not shipping "server only" code to the client.

[gaearon]

I think there's a bit of a confusion here.

Server Components can't use Context

Server Components aren't meant to be used "all the way down". The idea is that many of your lower-level components (whether built-ins like Text or your own design system components like MyButton) are probably going to be Client Components. You'd mark them with 'use client'. Then Server Components can compose those Client Components together. So your higher-level FeedStory can be a Server Component which renders a MyButton and Text Client Components. Client Components like MyButton and Text can use Context just fine. Server Components can render both Client Components and other Server Components, but Server Components "disappear" from the resulting bundle.

But from the way the React team talks about Server Components I get the impression it's going to end up being pushed as the idiomatic way to do SSR. So similarly to how you can still use Class Components in React, anyone who didn't follow the push for Hooks is fighting an uphill battle.

Server Components and SSR are two different things. They are complementary. Unfortunately the naming doesn't help resolve the confusion here. SSR is like a second layer that runs after Server Components have already run. SSR runs on Client Components. So say if FeedStory is a Server Component that renders MyButton and Text Client Components, first FeedStory executes. React figures out that the result that needs to be sent to the client is a tree with MyButton and Text.

From that point on, SSR works as usual — MyButton and Text get SSR'd to HTML and then hydrated on the client (because they're in the bundle). Server Components like FeedStory don't participate in SSR (and don't hydrate on the client) because they've already executed by that point. Server Components have "disappeared", the rest is your regular React app.

To sum up.

The point of Server Components is not to make all components Server Components. It is to mix and match Server and Client components as much as you want. Server parts "disappear" and then the Client parts work (and can be SSR'd) as usual.

You can think of Server Components as "disappearing" components. Not all components are "disappearing".

[jamesisaac]

Thank you very much Dan! You're right, I missed the point that SSR to HTML is a separate step after Server Components, which will still continue to run on Client Components.

I got the impression from the documentation existing so far that the everything static was intended to be Server Components, with Client Components just sprinkled in for things with interactivity. E.g. in the introductory video you gave the example of an e-commerce website showing the majority of the tree as server components. But perhaps I misunderstood that example and it was more talking about high-level components.

If you're saying it's perfectly valid to have all Text and View components in the UI remaining as Client Components, that's very reassuring, and sounds like there should be no problem continuing to use RNWeb with the upcoming versions of frameworks like Next.js (except the tradeoff of not being able to take maximum advantage of the performance boosts Server Components could provide).

The idea of thinking of Server Components as "disappearing" components makes a lot of sense, thanks - I'll use that mental model moving forward.

[gaearon]

E.g. in the introductory video you gave the example of an e-commerce website showing the majority of the tree as server components. But perhaps I misunderstood that example and it was more talking about high-level components.

Yeah that might've been an oversimplification. It often makes sense for Client components to be leaves. E.g. even a button can have some interactive states like hover etc and some part might be driven by JS. But the Server parts are your abstractions, component logic, etc. E.g. product list page, product list item. Although they might still be wrapped in some Client thing like a panel that reads theme from context.

[filiptdz]

It seems to me like the biggest issue is that this library produces vastly different styles when doing SSR versus when it hydrates client side.

So this means adopting SSR will either show a completely wrong layout before hydrating to the correct one, or will require extra code to return to the existing behavior of a blank page before loading/hydrating.

[nickderobertis-ch]

Hi @necolas, just wanted to follow up on this now that server components are not only stable in NextJS, but the default as well. We are also now writing applications with server components as the default, only using client components as leaves to add interactivity. This is the optimal structure to minimize client bundle size as pre-rendered HTML can be sent to the client rather than the associated JS. This is likely why server components are now the default in NextJS, while client components require an explicit opt-in ”use client”.

Now that server components are stable in NextJS, it seems unlikely that support for React context will be added. In general it’s not a useful feature for server components aside from compatibility reasons, as server components render only once while context is mainly a mechanism for re-rendering. Without the need to re-render, global state can simply be stored in POJOs.

We are just starting a new NextJS web application now but want to share components with our RN applications. The limitations here are basically forcing us to choose better performance with server components while having to build second copies of our common UI components, or ditch the performance gains and keep everything on the client side with RNW. I suspect this will become a more common scenario now that server components are the default in NextJS.

I understand this may take substantial changes in RNW to support. It would just be helpful for our planning purposes to know if this is something you’ll put on the roadmap now that server components are becoming mainstream. We may be able to help with some of the implementation if so.

[filiptdz]

If anyone happens to run into the same issue, I found the following solution to enable SSR on modern NextJS (13.4.10 using the app router):

 useServerInsertedHTML(() => {
  return createElement('style', {
   dangerouslySetInnerHTML: {
    __html: StyleSheet.getSheet().textContent
   }
  });
 });

Full gist: https://gist.github.com/filiptdz/974aeeb6a52254fc13128a36cdadb226

please let me know if there's something I'm missing

[filiptdz]

@necolas I'd be glad to write a PR to the docs documenting this if you're happy with this approach

[filiptdz]

Another option would be using

AppRegistry.registerComponent(config.name, () => children);
const { getStyleElement } = AppRegistry.getApplication(config.name);
useServerInsertedHTML(() => getStyleElement());

[mikevocalz]

using this with the new pages dir the '_react.createContext is not a function' error
cc: @filiptdz

[shawnmclean]

Where can I find some proper information on what's going on with RNW and NextJs?

Most of us are looking for the scenario of sharing base components across web and mobile.

I was evaluating remix and hit a roadblock, now im evaluating nextjs and running into similar issues.

Who are some of the official voices on this thing?