DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’» is a community of 966,155 amazing developers

We're a place where coders share, stay up-to-date and grow their careers.

Create account Log in
Magne
Magne

Posted on • Updated on

How to combine React Native Web + responsivity + NextJS SSR, to get SEO

Update 2022-06-20:

I recommend using Tamagui which will handle all the necessary parts. It allows you to "write once, run anywhere", even with media queries and NextJS SSR, by using a single React Native Web codebase. It has a tremendous starter repo Tamagui + Solito + Next + Expo Monorepo which gets you started with a cross-platform mobile app, which unifies even navigation across the native app and the web app.

Update 2022-09-29:

NativeWind is now an alternative (if TailwindCSS is your thing), as it can also handle responsivity with SSR. It has some good starter repos: NativeWind + Solito + Next + Expo Monorepo example or create-t3-turbo or create-kaol-app.


How to get SEO on the web by combining:

  1. React Native Web (RNW)
  2. Responsive styles (media queries)
  3. NextJS Server-Side Rendering (SSR)

This article is extracted from this github discussion, which goes into greater detail on how to achieve this with the libraries Dripsy (a component design system) and Fresnel (SSR w/ media queries).

First, you might want to read about the problem of SSR + Responsivity (scroll down to subheading there).

Forking RNW is an option. But if you are worried about maintaining a fork of RNW with potential style inconsistencies, then react-native-media-query is already that fork. It attempts to do media queries inside RNW's StyleSheet.

But in general, I see 3 ways for RNW + media queries + NextJS SSR:

  • Googlebot: SSR a non-responsive mobile version only for the Googlebot User Agent, to get SEO. But do Client-Side Rendering (CSR) for users, to get full responsivity. Could be done with manual user-agent sniffing, or with a GoogleChrome/Rendertron proxy. Though Google may not like being fed something different than users (different initial markup, even though resulting markup after React’s first CSR should be the same). But it might be problematic long-term to SSR only for the Googlebot, since it’s effectively serving the Googlebot something else than what the users get.. Google might crack down on it, since it could be abused. Update: No, Google sees it as legit. Β«Googlebot generally doesn't consider dynamic rendering as cloaking. As long as your dynamic rendering produces similar content, Googlebot won't view dynamic rendering as cloaking.Β» source
  • Fresnel: SSR all breakpoints. If sniffing the user-agent is considered unreliable. Fresnel might have some RNW compatibility issues. Fresnel is currently most worthwhile if one has radically different layouts (including markup/structural changes), not just classic responsivity (styles only).
    • Optimise Fresnel with detect-responsive-traits: SSR based on sniffing user-agent where it can, but all breakpoints if not. To optimise bytes sent over-the-wire.
  • Mobile-first: SSR only mobile page markup, with pre-determined/static breakpoints. Let client choose to "Show desktop version" on first page, then set cookie for all future requests. Avoids rendering multiple layouts/breakpoints/sub-trees, so that less CSS/HTML/JS needs to be sent over-the-wire.



Frankly, Mobile-first seems the simplest way to go, with the current limitations. If you are using RNW you presumably want a native mobile app to also work in the browser as a webapp. To simply get the mobile version in the browser, it doesn’t need to be so responsive it can change the layout completely (incl. markup, like Fresnel presumes), to automatically morph to a desktop version too. (If a page will swap out its HTML, is it still the same page?) You just need media queries to make the styles/css responsive enough to fit all mobile screens. If viewed on desktop it can initially center-display the mobile version. The small tradeoff is that it requires a single click from the user to see the full desktop version, on the first visit from a desktop browser. If clicked, then during SSR, you know definitively (without any user-agent sniffing) to render only the breakpoints and markup related to the desktop version.

But common for all ways to get SSR, is to avoid the JS Dimensions API in favor of media queries, to also get responsivity. Since JS Dimensions API won't have access to window on the server, only on the client.

Top comments (5)

Collapse
 
redbar0n profile image
Magne Author

NativeWind is now an alternative (if TailwindCSS is your thing), as it can also handle responsivity with SSR. It has some good starter repos: NativeWind + Solito + Next + Expo Monorepo example or create-t3-turbo or create-kaol-app.

Collapse
 
redbar0n profile image
Magne Author

Now, NativeBase "are using media queries on web and the SSR is 100% SSR, with all generated CSS and no layout jumps." according to a tweet from one of the nativebase devs.

If it fixes its performance issues: 4302, 1012, and 4176, then it will once again be a top contender with Tamagui.

Collapse
 
redbar0n profile image
Magne Author • Edited on

See dev.to/redbar0n/magnus-ui-vs-drips... for the most recent alternatives.

Some particularly promising alternatives:

Tamagui.dev for a UI library / design system / optimizing compiler, to achieve RNW + responsivity + SSR (with NextJS or similar).

Solito.dev for a unified navigation API across React Native and Web (with NextJS).

Collapse
 
redbar0n profile image
Magne Author

Stitches Native is another recent contender.

Collapse
 
redbar0n profile image
Magne Author

Check out Zero to $10m with React Native + Next.js (youtube)

from over at:

fernandorojo.co/conf

which also has code and resources.

Update Your DEV Experience Level:

Settings

Go to your customization settings to nudge your home feed to show content more relevant to your developer experience level. πŸ›