For reasons such as efficiency (4) and SEO, we want to do server-side rendering in such a way that the response sent to the client is immediately usable without the need to re-render.

Alas our current solution, which essentially boils down to if/else branching per breakpoint, doesn’t fulfil these needs as it is practically impossible (1) to know what the breakpoint is that the client will want to display at SSR time.

Additionally, even when getting the initial breakpoint right, the performance of changing breakpoints will be worse when a browser has to evaluate JS, recalculate a component tree, diff DOM elements, and update the DOM; as opposed to the browser only needing to re-render the styling without any DOM changes. (2)

Example

Consider a desktop browser requesting a page that is rendered as follows:

<Responsive>
  {({ xs }) => {
    if (xs) {
      return <Box width={1} />
    } else {
      return <Box width={1/2} />
    }
  }}
</Responsive>

On the server we’ll render a xs version (because that’s currently our default), then once the browser receives the response it may start to render that version.

However, once React is fully booted it starts to render a virtual DOM version based on an actual media query that may result in a different breakpoint than xs. If that vDOM does not match what the server sent, the server version is thrown away and the new version is used instead.

Options

Note that these are just some bare-bones examples. Where possible it would be great to come up with prettier declarative APIs that use these techniques under the hood.

Pure CSS

In cases where all differences in layout can be expressed in styling, we should be able to do something like:

const ResponsiveBox = styled.div`
  @media screen and (max-width: 767px) {
    width: 100%;
  }
  @media screen and (min-width: 768px) {
    width: 50%;
  }
`
<ResponsiveBox />

When some components should only render on certain breakpoints, these may simply be hidden on those breakpoints using CSS. (3)

styled-system

We’re using styled-system, which out of the box comes with responsive options that, I assume–and we should verify this, do exactly what the above option does. For instance, rather than the above example, we should write <Box width={[1, 1/2]} />.

More…

Please suggest yours!

Notes

1. That is, without resorting to added complexity such as sniffing user-agent and even then it won’t be foolproof.
2. While this performance penalty is even noticeable on desktop machines, it’s even more important for mobile devices.
3. In the case of mobile devices, this may lead to documents being sent to the client that include markup that will never be used, which presumably could add up for large pages. Seeing as in some of these cases, such as iPhones, we can pretty reliably determine the client never needs larger breakpoints, it would be great to have an API that could omit certain breakpoints completely.
4. Besides the aforementioned re-rendering of the browser, there are also examples such as page caching, which could be done for all unauthenticated requests of some pages.