Dropping SSR support

[nandorojo]

I'm considering dropping SSR support. It's built on top of many hacks, all of which are entirely circumventing the recommendations of react-native-web.

I've elaborated on this problem at length on many issues and PRs in the past.

If you need Dripsy in production with SSR support, feel free to mention it here.

At the moment, supporting SSR means the web API is complex, kind of confusing, and adds more DOM nodes.

I've been using Dripsy with SSR "disabled" (i.e. we return null at the root of the app and then setMounted(true)) on the beatgig.com. No issues for us with performance.

[cmaycumber]

I'm in favor of this.

I think if there's better support for another method down the line that's in line with react-native-web it can always be added.

[nandorojo]

I'm thinking we add an ssr option to the provider. If true, then it'll handle blocking rendering on web for you until it's mounted. You could pass a Placeholder component too.

[nandorojo]

This seems similar to the PWA/Twitter style.

[nandorojo]

I thought this was a good piece explaining why SSR doesn't work with RNW.

https://lihautan.com/hydrating-text-content/

React's hydration expects the initial render to match what's on the server. However, if we're using JS Dimensions, this isn't possible.

[nandorojo]

This also means that custom breakpoints should be easy to implement, since we don't need to use them with Fresnel.

[nandorojo]

I'm working on this update now. It'll be a major version bump.

The only "breaking" changes from the user's standpoint:

• If you are using SSR, you can pass ssr={true} to DripsyProvider. In this case, it'll delay rendering until the app mounts. If you already have a gate of your own, then this isn't needed.
• I'm removing the already-deprecated ThemeProvider.

All other changes are under the hood.

This will automatically enable custom breakpoints.

In case we, for some reason, change our minds, I'm putting this behind an internal SUPPORT_FRESNEL_SSR boolean for now.

[nandorojo]

This also opens the door to a lot of additions. We can now allow components to pass custom props to styled. Or a useSx hook. I'm excited for the doors it opens.

[nandorojo]

If you could test this, it would be great.

yarn add dripsy@canary

That should install 2.0.0-alpha.0

[nandorojo]

I added notes for making this work well for SEO at the PR: #101

[nandorojo]

I wish I'd done this sooner. It is simply amazing. So many doors are suddenly open for responsive styles. No more hacks 🔥

[cmaycumber]

Yeah, I'm excited. I think if I need anything with responsive styling I'm just going to fall back to a theme-ui component on web which is working great for me.

[nandorojo]

Yeah, I've been doing the same. Do you mean the one that I shared a while ago?

[nandorojo]

I'm probably going to just stick to the normal API and block the SSR. Maybe we could add docs for the theme-ui Div component if someone really needs to render on the server. But I'll consider it officially unsupported as a userland solution

[cmaycumber]

Yeah, I've been doing the same. Do you mean the one that I shared a while ago?

I've used that one for inspiration with a few tweaks and am also doing it for text bc I find that usually on layout component and text are the ones that I really need to use responsive styling for.

I'm probably going to just stick to the normal API and block the SSR. Maybe we could add docs for the theme-ui Div component if someone really needs to render on the server. But I'll consider it officially unsupported as a userland solution

Nice, I might do the same down the line once I get a chance to look through my app bit. Quick question do you still see a benefit for using Next Js over just base expo web without SSR support. The first thing that comes to mind is code-splitting so pages have smaller bundle sizes but I'm curious about your take.