Live data from Hacker News

Next.js App Router Update

nextjs.org

91–93 of 93 posts

Re: Next.js App Router Update

#91

Earlier quoted context omitted.

In general, any model that uses fine grained reactivity (Vue, Preact, Solid, Svelte) will be more "forgiving" then one that uses coarse grained reactivity (React) because it triggers smaller component tree updates. This tends to reduce certain classes of bugs like side effects from unexpected re-renders and performance issues like over rendering. The thing with React and Next is that it's great if your team is relati…

If re-renders are causing bugs, you are 100% holding the tool wrong Like having data corruption issues from GET requests. --- I prefer explicit, but if implicit fine grained reactivity is the sole point of concern, you might be interested in React+MobX.

Every React team I've worked with has held the tool wrong because on every project I've been on in 3 VC backed startups, I've had to track down unintended side effects.

MobX and Valtio create an illusion of fine-grained reactivity but do not change the underlying render cycle of React itself.

Re: Next.js App Router Update

#92

What are the viable alternatives for those who don't care about the API routes but still want some level of pre-rendering / SSR? Staying in the React ecosystem that is. Remix is always touted as the alternative but it seems like a whole new approach to learn and it's own strong opinions. I've been using Next for 3+ years but I don't feel confident to start a new project today. Do I go to the dying page router? Or tra…

API routes are nothing new, and not a big part of the new App router (also, called "route handlers" there). Are you confusing features here?

Nope, just saying it's not something I need in the alternative. Doesn't need to be a full stack/backend framework - just focus on frontend and SSR.

Re: Next.js App Router Update

#93
post #48
post #29

Earlier quoted context omitted.

You can continue to use state management libraries that take advantage of React hooks or other client-side logic inside of client components. Alternatively, you can move state management entirely to the server. That could be state in your database, URL state, or something else.

Hey Lee! Thanks so much for responding. What's not clear to me is where do the providers go (ReduxProvider, ReactQueryProvider etc)? Can they be instantiated up tree in a server component somewhere? And if that's the case, what data do they hold when on the server and what happens a client component tries to interact with the provider? Or should I render as much as possible via RSC and put the providers in the first…

Sorry for the late reply, but we have docs here! https://nextjs.org/docs/getting-started/react-essentials#con...
Post reply on HN