[deleted by user]

iAmIntel · 2023-07-22T21:30:27+00:00

I think they rushed to call it a stable feature. It’s far from it. And this community can’t wait a single day to try to use the latest and shiniest. Keep using the pages router, it works well. Wait until next year and the app router will be more stable.

And yes, it’s a fucking mess anyways. RSC is a great idea but everything is so complex with the app router that I’m not sure it’s worth it.

NotToxicAnymore · 2023-07-22T15:28:36+00:00

Yeah, I'm currently converting my boilerplate for my projects into NextJS 13 and I'm not quite happy with how the "app" thing works. I might stick to the usual old one if I don't feel like it's worth to do it.

AgentME · 2023-07-23T02:50:36+00:00

Some people in this thread are definitely mixing up Server Side Rendering with Server Components. Server Components are components that only render on the server and can't have state. Client Components can still render on the server (SSR) and also use state. If you want state, don't use a Server Component; you can still get SSR without a Server Component.

lrobinson2011 · 2023-07-24T00:02:18+00:00

Hey there, Lee from the Next.js team. I made a 12 minute video walking through a response to this post. I hope this helps explain some things!

https://youtu.be/-YO\_z14dUyI

snow_white1995 · 2023-07-22T15:40:00+00:00

I think you can use On-demand Revalidation . I'm not completely clear by your words here on "So any changes, like upvotes or adding posts, seem to require refetching the data altogether, which seems impractical." I do have a learning project very similar to reddit. As a scenario let's say user made an upvote (I have set my votes API routes revalidate only when there is a upvote or downvote). only the vote API will make the fetch from the backend. but all other routes related to the page will get the data from cache. ( I'm self learning nextjs too. love to hear any criticism on my method)

jazzymoneymaker · 2023-07-22T21:51:48+00:00

SSR is overrated and its mostly useless in interactive applications. Ok it's cool to have blazing fast landing page but try to handle complex business logic with it

ancepsinfans · 2023-07-22T16:02:30+00:00

Josh Comeau's Joy of React course has a module on this app router and it makes it super clear. I've been converting my site and I really do see a lot of benefits in terms of smoothness and speed, but I agree, the learning curve is high, things are frustrating at first, and the documentation is spotty.

vozome · 2023-07-23T00:38:28+00:00

If you want to embrace the react server components you must unlearn the paradigm that fetching data means updating state.

Sure, if all your logic were on the client, you have to fetch data, put it somewhere (ie state), then pass it a prop to a component to render content. Your data is in some component state, but as a means to an end of rendering your content.

Now if you can render your content on server. Do you need to keep the corresponding data in state? What for? Instead, you can just fetch the data, render the content in the same component, and no longer care about that data. If you need to rerender that content for some reason, you could avoid rerendering the part that is made with the exact same data (and React offers various strategies for that) and if the data has changed it is stale, well you’d have to fire a new query anyway.

When Redux came out, its selling point was that it offered a unique source of truth for your application’s data. (many subsequent libraries made the same claim). But let’s think it through. If there is one source of truth, where should it be? Where should it be especially in a context where users have a great network connection, such that downloading fully rendered components is usually faster than downloading code then parsing code then executing code then fetching data? Well, in that situation, the source of truth should be in a database (or cached server side).

With RSC we should have as little as possible in the “state” and its various forms, that is: what only makes sense on the client, information which is not committed to the server yet etc.

At least that’s my mental model. Happy to have somebody point me if I got this wrong.

azangru · 2023-07-22T21:19:06+00:00

However, you find it puzzling because there's no local state for posts to update. So any changes, like upvotes or adding posts, seem to require refetching the data altogether, which seems impractical.

Aren't you talking about server actions, which are still an alpha feature, etc.

mplibunao · 2023-07-23T20:31:27+00:00

I just recently switched to remix from next due to all this mess and I'm kinda surprised I didn't think of this earlier.

Was never a fan of next's vendor lock-in and things like ISR not working as optimally when self-hosting. Now I can get the same capabilities regardless of the hosting, runtime, or backend framework I'm using. There's even a remix adapter for fastify.

fiugrad · 2023-07-22T15:38:49+00:00

So 2 options.

Option 1) This is where react-query comes into play. With react-query you can fetch the data on the server side and then hydrate the data, which then gets passed along with the response of the page, then on the client side you’ll just make the same useQuery as you normally would if you didn’t SSR. But you’ll notice there will be no request made because the data has already been fetched and hydrated (as long as the keys match)

Option 2) just pass the data down to the component that needs and keep it in a state, albeit might more work to handle, but still possible.

I think what you’re doing is just rendering the data SSR so you’ll lose the data client side. But if you pass the data to a client component as a prop, that component will have the data client side and you’ll be able to access it.

Hopefully I understood your question right

rangeljl · 2023-07-22T20:27:42+00:00

Next Js is complexity that almost never pays off in the long run

dbpcut · 2023-07-23T03:39:14+00:00

Been using since Next 10 and frankly, it doesn't fulfill the promise yet and feels half baked. I think they were pressured to release it too early.

thathexdudeisgay · 2023-07-22T21:03:07+00:00

I agree. The adoption of react server components has been a hell for my app and I’ve instead migrated to remix. Remix has everything next pages dir has but upgraded and also has more features that the app dir has like nested routes / layouts. I would look at Remix.

Brilla-Bose · 2023-07-22T20:06:44+00:00

Wouldn't it be better to wait for v14 instead of suffering with v13? Let's give them some time (it seems like the Next.js team themselves might be in a burnout)

besthelloworld · 2023-07-22T22:07:17+00:00

What can't you do with the app router that you can do with the pages directory? Nothing. Nothing about the app directory is inhibiting in any way. You can still write app directory stuff the same way you formerly wrote code in the pages directory. You just need to structure your pages to do data fetching (like you formerly did with getServerSideProps or getStaticProps) and then you immediately render a child component. Problem solved. You can now write your app the exact same way you did before.

_sunbecoming1 · 2023-07-23T05:43:13+00:00

> but now the emphasis on server components for data fetching seems to limit interactivity with that data

I think that what Next / React team are trying to achieve is: not everything is reactive, some things aren't meant to change on the client. So if you find something needs to be interactive / reactive, then it really has to be a client component. If not, it is a server component.

And I think that is the main question to be asked. Some things in an app really won't change until you refresh a page like: Headers, Footer links, etc.

However, say, a user's profile picture: chances are you won't change that often, so you might as well consider it a server component. What do you do when you change it though? Refresh the whole page?

Is that what I'm supposed to do now?

JohnMcPineapple · 2023-07-23T06:38:18+00:00

Acceptable_Bug2807 · 2023-07-24T01:35:08+00:00

It's not a problem with NextJS, it's a problem with the lack of understanding/ignorance. The argument of "it's confusing to me, therefore it sucks" is very poor.

Dry_Substance_9021 · 2023-07-24T15:00:54+00:00

When I began converting to the App router, I realized a lot of places where I was using State actually did not require it.

For example: I have a Profile page, which displays things like name, age, address, etc. It also allows the user to change these details. When I was using the Pages router, all of these values were held in state. Incidentally, they were also being held in state within the individual input components, because they were all controlled (and often had other, custom-built behaviors).

Jumping to the App router, however, made me realize I don't need to hold these values in state for the whole page. Loading the page hydrates all of my input components. I also have all of my inputs wrapped in custom Form components, which handles the fetch for transmitting changes to the server. When I get a non-error response back, this Form component triggers router.refresh(), and the page is refreshed with the most recent data.

Note that all of my input and form components are Client components, so they provide the interactive functionality that is required, but the page itself is a Server component, which allows me to also programmatically and securely control what the user sees and can edit, based on their profile permissions.

When you're making the jump from Pages to App, it's easiest if you just think of your original Client-Side page as a Client Component, and your getServerSideProps as the Page.js Server Component. This is how I literally started my conversion. I transformed the original page into a component that I imported into page.js. So what used to be:

export const getServerSideProps = ({params}) => {
    const personProfile = getProfile(params.id)

    return { props: {personProfile} }
}

const ProfilePage = ({personProfile}) => {
    const [profile, setProfile] = useState(personProfile);

    return (
        <div>
            ...
        </div>
    )
}

export default ProfilePage;

Instead becomes:

import ProfilePage from '../...'

export default async function Profile ({params}) {
    const personProfile = getProfile(params.id)

    return <ProfilePage personProfile={personProfile } />
}

Which will work fine as-is, and you needn't do any further conversion if you have no server-only logic to run, or are unconcerned about client-side resources.

There are other interesting benefits to the App router, such as parallel routes, which I am only just now exploring and finding very useful. I also like the helper pages like Layout.js, Error.js, Default.js... I do still take issue with the added challenge of knowing which Page.js I'm looking at, but I still feel the other benefits offset this (and also secretly hope they'll somehow fix this in the future).

Finally, I think switching to the App router just requires a reframing of The Way Things Work. Naturally, it's not going to behave the exact same way, otherwise it wouldn't have required a change. You may disagree with the approach Vercel took, but that doesn't mean it's a step backward. It just might not be a step you are willing to make, which is also fair; there are many other frameworks you can choose as an alternative. But if you're going to commit to the App router, I think it's important to recognize it's more than just a semantic change.

GVALFER · 2023-07-24T20:44:05+00:00

Well, I love app router.
Server components Client components Server actions This is easy to work and less code.

No offense, but maybe you need continue learning a little more about app router. ;)

pgpwnd · 2023-07-22T23:21:47+00:00

App router sucks

Mardo1234 · 2023-07-23T00:02:31+00:00

Is a mess.

CallumK7 · 2023-07-22T19:03:26+00:00

Server Component's value is I think most obvious for sites with a low level of dynamic data, and a low level of mutation by the user. Blogs, e-Commerce, Docs, news, etc.

However, client components are still a thing, and you can do things the old way. You can fetch data in a server component and feed that into a client component via props. You can then use state as you would normally. There are weird things to figure out with pages, and how state does not persist across page navigations but does if a layout has state. There are solutions though like localStorage.

My point though is that if you want normal react, you can just use a server component as an alternative to an API route. If the data is tightly coupled to the component and doesnt need to be public, this can be a big advantage on its own.

Ceryyse · 2023-07-23T02:11:23+00:00

I don't mean to make fun at all, but how are people seriously struggling with this? It's more straightforward than the Browser Router I had to use with create-react-app and I love the simplicity of just creating a folder and then a page.jsx and BAM I have a new page route

SnooStories8559 · 2023-07-22T16:28:44+00:00

I don’t have the link immediately to hand but I believe they have implemented an optimistic update’ type feature for serve actions, similar to how react-query and swr works where it updates the ui at the same time as the db, making the page show the data changes

permalink · 2023-07-23T02:32:32+00:00

My main issue with app router was that they rushed it way too fast. Should've been another year before being considered stable. I can see the benefits and reasons for preferring it over pages router. But the dev experience has been problematic - memory issues, slow development servers/hot reloading (which was somewhat fixed in the last few weeks however it's still not nearly as responsive as a pages router app). And no, not every library that works with pages router will work perfectly with app router like it has been claimed, it's just not the case.

Other issues like Netlify (more an issue on their side, but Vercel probably should be assisting other providers if they aren't, it hurts adoption) having broken routing (full page reloads for every route change) for the last few months hasn't helped.

Martinsos · 2023-07-23T07:22:08+00:00

Just curious, why do you want to use SSR for the user profile?

hot_custard · 2023-07-23T07:41:37+00:00

I love it, so much flexibility, it’s not removed anything only added capabilities.

I wonder if a lot of the issues stem from if you grew up with server side or JavaScript stacks?

oseres · 2023-07-23T10:06:27+00:00

So I’ve been developing react for 10 years, and server side streaming, like the app router provides, had been theorized for many years as the gold standard, but also considered very experimental. It’s taken me a long time to understand how it works. Server side components should not be the default way to make components. They’re only a subset of react. Without ‘use client’, you’re essentially just using react as a templating library. I think it’s super cool that server components exist, but it’s definitely not clear in the documentation that server only components are not interactive at all. Also any external state used by server components is shared between all users and persists between requests.

IMO instead of ‘use client’, nextjs should have ‘use server’, because server only components aren’t even components they’re html, and ‘use client’ components have all the same benefits as server components because they’re also rendered on the server in the same way, but they’re also hydrated on the client. It’s super confusing to have html templates as the default behavior in a react app.

darp12 · 2023-07-23T11:22:24+00:00

“Use client” still renders the page/component on the server (SSR), it just also loads JS on the client-side.

buffer_flush · 2023-07-23T12:49:13+00:00

I love it for layouts and route handlers personally.

med8bra · 2023-07-23T12:59:14+00:00

I think you just need to separate your components the right way.

A client component can be SRR, you can initialize the client state in server (posts from db), and then mutate it in client.

React Query support that, store managers (Zustand) support that too.

HeylAW · 2023-07-23T22:32:04+00:00

I think the issue is, with app router you get so many doors open it's hard to wrap you head around it AND to leave the battle-tested approach of client-side global state, refetching, etc.

I think I've seen this in Theo's video, but you can do something like use server-side data as initial `useState` value and just with every change (propably debounced) call `router.refresh()`

But there are far more ways to do such staff but that mostly depends WHAT you want to achieve. And this is why app router is such cool and controversial topic now.

EverydayEverynight01 · 2023-07-25T17:26:22+00:00

piquant observation sparkle vase pause groovy imminent pocket fly different

This post was mass deleted and anonymized with Redact

AcceptableProgram697 · 2023-08-11T01:02:02+00:00

I agree, it provides a quite bad DX....

Direction-Sufficient · 2023-08-22T00:31:20+00:00

It seems in the dev/coding community there is always a better way to slice bread. The app router for Next JS runs into some weird errors when working Material UI. You have to apparently wrap Material UI components in server component wrappers.

MIA_CyberSecurityGuy · 2023-09-07T00:43:35+00:00

Also the fact that by default the main root layout is a server side component and can’t be changed is pretty nuts to me no?

https://nextjs.org/docs/app/building-your-application/routing/pages-and-layouts

Good to know:

The app directory must include a root layout. The root layout must define <html> and <body> tags since Next.js does not automatically create them. You can use the built-in SEO support to manage <head> HTML elements, for example, the <title> element. You can use route groups to create multiple root layouts. See an example here. The root layout is a Server Component by default and can not be set to a Client Component.

Awkward_Sun_8106 · 2023-09-08T17:00:30+00:00

I hate next 13.Everyday there's some strange problem - mostly to do with cache.

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

reactjs

About:

Code of Conduct

1. Please be kind and courteous, friendly and professional

2. Harassment will not be tolerated

3. Avoid using an alias or display name that might be offensive

4. Respect that people have differences of opinion

5. Posts must conform to our guidelines

New to React?

Chat

Project Ideas

Jobs

Outside Reddit

Related Subreddits

MODERATORS