3 ms·
(I'm on the Next.js team) I appreciate Lenz's feedback and writing all of this down. I can empathize with how they and other library maintainers are feeling. Th
by leerob 3y ago
(I'm on the Next.js team) I appreciate Lenz's feedback and writing all of this down. I can empathize with how they and other library maintainers are feeling. There's more we can do on the Next.js side to help ease the transition (and this feedback will help us there, so thank you).
One point of confusion in the community has been around client components. If server components are new and exciting, does that mean client components are bad and we shouldn't use them anymore? No, it's okay to continue using them, but definitely want to acknowledge that can be draining for library maintainers to have to deliver that message. The client/server evolution of React is still in the early innings, so maybe this will be less of an education issue going forward. Client components = able to use the existing React ecosystem.
There's also some confusion about the React canary releases (https://react.dev/blog/2023/05/03/react-canaries https://react.dev/blog/2023/05/03/react-canaries). These features are ready for frameworks to adopt. The normal semver rules still apply for frameworks when they add experimental features (ideally behind flags). There is a separate experimental channel for React, that uses experimental features (like Server Actions). The infinite loop issue mentioned (marking a client component as `async`) now causes an ESLint error in Next.js.
Appreciate all of the suggestions in the post. A good conversation to have!
- deminature 3y agoToday when creating a new next app, you get this: > Would you like to use App Router? (recommended) It seems like users shouldn't yet be funnelled by default into using RSC.