"Can you open that button/link in a new tab?" can send (ultimately good) shockwaves through your app state:
- How easy is it for you to put that state in the URL?
- Is it complex/nested?
- Is it type safe?
- Can you update some/all of it?
- While also changing the path/hash?
- Is that state stable between renders?
- Do all routes/paths now need to be aware of that state?
- When do you persist that state automatically? Can you?
- If you update only part of that state, are the parts that remained the same structurally equal?
- How much global/route-level/usage-level control do you have over the links that you are generating?
- Can you apply defaults to said URL state? On specific pages?
- Can you validate the end-resulting URL for correctness?
- Can you fix it if it's not?
These questions are running through my head *all day* and have become indispensable, especially with the work I do on @nozzleio.
@tan_stack's #ReactLocation isn't perfect, but I feel like it has pretty good answers and solutions to all of these questions.
Routes can define data dependencies and the elements they render as asynchronous functions that will be guaranteed to resolve before rendering the next location. The suspense is palpable! 😜
🔀 Parallelized Loaders
"🎶 Don't go chasing waterfalls", not even the data-fetching ones!
Navigating through 3 loaders to a deep link out of the gate? By default, loaders and async elements for matched routes are all parallelized for efficiency. You can fetch serially, too 🤷♂️
@theefer@OliverJAsh I’ll respond more at my keyboard, but the simple solution to this is to adopt invalidation patterns over manual data normalization. Just invalidate all of the queries. They already know how to fetch the exact data they need.
@theefer@OliverJAsh Regardless of React Query or not, normalized caches on the front-end come with the upside of fetching less data and using the responses of mutations as much as possible. When you like a tweet, you just go find that tweet in your store and update it
...
@theefer@OliverJAsh This situation works fine if that action doesn't have any side effects on the rest of the system. Imagine tweet deck that is showing only liked tweets, or a list that is sorted by time of liking. This now means that you either have to replicate all of the logic on your server
Lots of talk about React suspense today. I’m very excited about it.
However, I feel like the patterns I’ve seen in #ReactQuery (and friends like SWR) have alone been more transformative for my own dev process and users and have even prepped me for suspense in a lot of ways.
Of course, Suspense isn’t out yet, and the ecosystem will likely experience a smash of collective inovation around it when it comes out. That’s the exciting part. But what I feel like I’m starting to realize after playing around with it is that in the end,
The biggest thing that suspense is going to do for me is just one thing: avoiding that flash of loading/placeholder for newly mounted components. Suspense doesn’t fetch, it doesn’t codesplit, it doesn’t preload for you and it doesn’t cache for you.