Freelance developer - React Query maintainer - Occasional OSS contributor - Been putting React on servers for a decade - Father of two - Homebrewer
Stockholm
- Tweets 2,072
- Following 414
- Followers 921
- Likes 3,503
I'm super nervous and excited, and I'll share more as things progress.
I've got some renovating to finish up first and I'll start off with some long overdue OSS work in December.
1
4
I want to spend more time with OSS and the community, not just thinking and talking about things, but building, but with 2 young kids I can't make that work just in my free time.
With my own business I hope to create the flexibility over time to do more of all these things.
1
5
I really do want to teach more. I enjoy it, people say I'm good at it (though I feel I have SO much to get better at..) and I think it's really important.
I also want to do more talks, blog, share.
1
4
I've come to realize a few things. I want to see more stuff. More people, more companies, more products, more interesting problems, more codebases, learning from and teaching more developers.
1
4
Before summer I felt after 4 years at my previous gig that though I enjoyed it, it was time for a change. Since then I've done a bunch of things, vacationing, renovating and spent a lot of time with the kids. It's been nice!
Meanwhile, I've been thinking about the next step.
1
4
I've got some news to share, I'm striking out on my own and I'm becoming a consultant! 🎉
I'm still setting up the business and figuring things out, but I thought I'd share early. You might have noticed I've been pretty much afk the last few months, I'll share why in the 🧵
2
3
30
Note that there is so much nuance and complexity here and while I'm aware of the things that has NOT been possible before, I wanted to focus on some less known things that has. 😀
1
2. A public API that treats transitions between states as a built in primitive and gives the high level tools app developers needs to craft good loading experiences, no matter what libraries you use or what kind of resources you are waiting for.
1
1
React can't solve all of these problems by itself, a lot of it requires especially router integration, but what has changed is that React soon provides:
1. The necessary low level puzzle pieces for frameworks to integrate with, some things has not at all been possible before.
1
1
I could talk all day about this and how you could work around the code->data request waterfall (getServerSideProps, preloading) etc, etc, but my point is that while a lot of things have been possible to do in userland, it's been very, very complex and most apps haven't done it.
1
1
That way, hydration is still quick and when the user scrolls down to the lazy content, you already have the data available. Also, in both cases you could start prefetching the code before needed so everything would be quick.
1
1
3. In some cases, nr 2 above would lead to a bad experience after hydration because you would need to first fetch the code for the lazy content and then the data. One way around this that sometimes makes sense is to DO fetch the data on the server, but not render the components.
1
1
2. Combined with 1 - Lazily render the components that depend on the secondary data, so you don't have to block hydration on that code being available and also get shorter hydration times. (Same variation, always render them for bots)
1
1
Bonus: Three patterns relating to making the best of sync SSR and sync hydration.
1. Only fetch main content on the server, fetch secondary content (often below the fold) on the client. (Variation: Detect bots and fetch all content for them)
1
1
Now you can colocate data close to where it is used, you can avoid request waterfalls, you can provide a cohesive page level loading experience for main content without blocking render on secondary data requirements.
Pretty neat! If only there was a better SSR-story.. But wait!
1
1
Nested routes data loading has been possible even before Remix. Nothing has stopped you from building SSR-enabled nested routes data loading on top of regular React Router since forever, it's just been hard.
If you combine nested routes with nr 3 above, things gets interesting..
1
2
Also, you can't do 2 or 3 with something like getServerSideProps.
Still with me? Okay, now let's shake things up with nested routes! 👇
1
1
For a pre-Suspense world, nr 3 has provided a nice balance between a coherent loading experience and avoiding waterfalls, but juggling the complexity of doing different things on the server and the client has been challenging so it's not a common pattern.
1
1
3. You could mix 1 and 2. Categorise some data as main content and await that in gIP, blocking page render until ready. Meanwhile, start prefetching all data you need for secondary content, but don't await it.
1
1