Content pfp
Content
@
0 reply
0 recast
0 reaction

Colin pfp
Colin
@colin
Began working on a /paragraph redesign and used that as an opportunity to begin using the NextJS app directory. Overall very positive experience: - eager to deprecate redux which contained a lot of complex, archaic state management logic; replacing it with fetches and regular TS at React component leaf nodes - RSCs are awesome - fetch (+ all the built-in caching) is awesome and much better than our huge getStaticProps which blocked the entire page - Suspense is awesome and improves UX (though, encountering a handful of bugs associated with it) - lack of opinionation is OK but leads to a bit of a learning curve (eg manage state via context? or URL params? or via an optional catch-all route?) - still a bit confused about certain next features (intercepting routes? "instant loading" vs regular suspense? etc) though I imagine I'd learn in time Also really enjoying shadcn
6 replies
5 recasts
51 reactions

Zinger ↑ is job hunting pfp
Zinger ↑ is job hunting
@zinger
I would recommend moving as much state to the URL as possible, it's best for server components and automatically enables better link sharing
1 reply
0 recast
2 reactions

Colin pfp
Colin
@colin
I began doing that but encountering an issue with suspense not triggering very quickly upon URL updates. Eg: - user clicks button - RSC fetches data - ~1s later the URL gets updated and immediately the RSCs load (suspense does not get triggered..) if I add a 5s delay in the backend it looks like this: - user clicks button - RSC fetches data - ~2s later the skeleton displays (so suspense is working! Just slow) - after backend delay resolves the URL gets updated and immediately the RSCs load Several issues on GH also discussing this. Not ideal
0 reply
0 recast
1 reaction