dripsy VS detect-responsive-traits

Dripsy unstyled UI primitives which are responsive (at the expense of SSR support though).

Here are libs to help you share code between web and mobile: - Shared UI primitives + style: https://github.com/nandorojo/dripsy

Try using dripsy. It allows you to create responsive themes a lot like the web.

Dripsy is a good solution for styling: https://github.com/nandorojo/dripsy

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).

Does NOT currently support SSR. Even though it still works with NextJS for other reasons such as code splitting and navigation, and SSG.

Dripsy is very declarative: it allows you to provide object and array values to add mobile-first responsive styles. Instead of manually using the Dimension API (on native), and adding media queries and nested styles throughout your code (on web). This API is very inspired by Chakra UI's array syntax for declaring responsiveness. (Which Magnus UI also is inspired by).

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.

Before, Dripsy used a library called Fresnel to achieve achieve Responsivity with CSS media queries. CSS breakpoints on web will rely on the mobile device's user agent for most cases. But since this can be inaccurate, Fresnel also uses pre-emptive server-side breakpoint generation. Basically, if the mobile user-agent cannot be accurately detected (if you combine Fresnel with its sister library, detect-responsive-traits), then Fresnel will render all media query breakpoints on the server (a bit of extra work for the server, since it might lead to rendering more components). So the client's browser will receive all breakpoints on first render and can immediately start rendering according to the correct ones. Instead of waiting for React to rehydrate before only then running the media queries with CSS-in-JS, which would have given latency and potentially unwanted visual side-effects. This becomes most acute when you are using SSR, and thus don't want to wait for rehydration on the client to start showing the responsively laid out content.