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
Fredrik Höglund retweeted
There has been a lot of talk recently on Redux in terms of its place and future in React. Thread on my thoughts.
2
18
41
I believe recommending everyone to go straight for fetch-as-you-render regardless of complexity costs is endorsing premature optimization.
This was going to be a nuanced blog post, but I don’t have time to write it, so you get a thread 👇
2
9
74
Oh, and if anyone even remotely related to the project reads this, amazing work on both the new features and the docs for them! 👏 It should also be noted that some of this nuance has kind of been captured in ”For Library Authors”.
”Unless you have an..”
reactjs.org/docs/concurrent-…
2
1
11
Since I wrote this I've reversed positions on a bunch of stuff in this thread (not the part about all this work being amazing though!). See new thread for details.
I no longer believe recommending fetch-as-you-render as the default solution is endorsing premature optimization. I still believe there are some warranted concerns in that thread, but I'm reversing my position for a couple of reasons. A new thread. 👇
I no longer believe recommending fetch-as-you-render as the default solution is endorsing premature optimization. I still believe there are some warranted concerns in that thread, but I'm reversing my position for a couple of reasons. A new thread. 👇
I believe recommending everyone to go straight for fetch-as-you-render regardless of complexity costs is endorsing premature optimization.
This was going to be a nuanced blog post, but I don’t have time to write it, so you get a thread 👇
2
5
10
I guess coming from a fetch-then-render background makes it easy to focus on the DX/complexity problems around that, while coming from fetch-on-render it's easy to focus on the UX problems around that. We need to solve both.
1
5
Trying to solve AOT data-fetching and routing as separate problems seems off to me. What would a plugin-based routing framework look like? SSR+Client+build time extraction of co-located data dependencies built in, you plugin your data solution, maybe code splitting etc?
1
2
Fredrik Höglund retweeted
in real life twitter solves my problem thanks to all the amazing people @swyx @gaijinity @EphemeralCircle and #learninpublic
updated notes aworkinprogress.dev/play-con…
no more excuse to not use concurrent react in gatsby sites now
No problem, TIL that Gatsby has a replaceHydrationFunction, I'm just glad I could help with one of the other puzzle pieces! Feels fitting that we #learninpublic in thread started by @swyx 😀
2
4
12
