Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Dropping SSR support
See original GitHub issueI’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.
Issue Analytics
- State:
- Created 2 years ago
- Reactions:2
- Comments:37 (37 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
I meant that every time we used responsive styles, we used fresnel, which added an extra DOM node per-breakpoint.
I’m only using static generation, not SSR, which can’t conditionally render pages anyway.
Maybe your solution would work. You’d have to set the window dimensions yourself somehow, and Dripsy would read from that if it’s a crawler.
Just FYI, this isn’t something I find a priority at the moment. I spent too much time optimizing for this and ultimately saw no benefit to our site for it. But if you can come up with a solution that’s easy to drop in, I’m open to it.