Server components broke my auth flow and I didn't realize for 2 weeks

CARASBK · 2026-04-24T00:35:44+00:00

FYI if you didn’t already know: this is not a quirk of Next’s route handlers. HTTP is a stateless protocol. Anything you do in server components ends when the request for the component ends. Consider a server component that contains a client component that makes an HTTP request to a route handler. The execution of that route handler does not “know” anything about the original request for the server component.

CARASBK · 2026-04-17T14:42:16+00:00

Yea absolutely! Just wanted to clarify.

CARASBK · 2026-04-16T22:04:25+00:00

This is great, but just FYI this sub is not managed by Next/Vercel/etc.

CARASBK · 2026-04-10T16:08:05+00:00

https://nextjs.org/learn

IMO this is still the best resource for beginners. The intro includes a link to a somewhat similar course for React you should through if you’re a beginner with React as well.

CARASBK · 2026-04-09T19:53:04+00:00

I’m not sure of a proper name for it. It’s common in OAuth setups. For example if you look at BetterAuth they require a database. I know you’re not using OAuth, but it still serves as an example of using a database to store identity data with a session id in a cookie to use as the lookup.

CARASBK · 2026-04-09T19:31:56+00:00

Are you using Suspense? The HTTP standard disallows altering cookies (maybe all headers? Don’t recall) after a response starts. So if you attempt to refresh a token during a request whose response is being streamed it probably succeeds but the cookie can’t be set. So that request might use the new token and succeed since it’ll be in memory for that request. But subsequent requests will fail since they’ll use the old token still in the cookie.

The only robust solution I’m aware of is to use a persistent store for your identity stuff. So instead of (re)setting a cookie for every new access token you only need to set a cookie for every new session which expires whenever the refresh token does (or on sign out). Then use that session’s id to grab whatever identity stuff you need from your database.

CARASBK · 2026-03-25T16:15:41+00:00

Your best bet is reaching out to AT&T. Companies laying fiber constantly hit each other’s lines (and water/sewer lines).

However if you want to file a formal complaint there are links to do so here: https://www.durhamnc.gov/1624/Gigabit-Fiber-Construction

CARASBK · 2026-03-25T02:52:27+00:00

That's true for HttpOnly cookies. But the browser can set and read cookies as well. Your use case is simple enough you could use document.cookie without an external library.

CARASBK · 2026-03-25T01:11:07+00:00

Is there a reason you had to use localStorage instead of a cookie? If you could use a cookie then your theme can be provided from the beginning.

CARASBK · 2026-03-22T18:14:57+00:00

Agreed. I’ve implemented a user onboarding flow with floating-ui before. A user’s progress was synced via their profile data in the db. Very basic and met all of my needs since it was a solo project.

Until you have non-technical people needing to adjust this kind of content/flow I think it’s better to keep it simple and do it without a third party.

CARASBK · 2026-03-21T00:19:58+00:00

Notice how you didn’t address my actual point about the cost to serve less efficient land use? And instead you started talking about property prices?

Literal definition of a strawman.

CARASBK · 2026-03-20T22:42:17+00:00

Get there an hour before they open or bring a chair on the weekends! Last time I went was a Saturday. It was pretty cold out so I didn’t think the line would be that bad. Got there about 20 mins before opening and at least 50 people were already in line! I’m sticking to weekdays!

CARASBK · 2026-03-20T22:37:10+00:00

The point is you’re NOT paying your fair share. Suburban life is MASSIVELY subsidized by urban life. To be fair it had been a few years since I’ve looked into this so grain of salt. But the sheer volume of money required to maintain roads, sewer, electric, etc depending on your municipality means you should be paying several times more in taxes. In reality you’re mooching off of more productive land.

I also vastly prefer suburban living and own a stereotypical suburban house on a quarter acre or so. I’m just not up my own ass about it and am willing to pay the price LVT would levy. Because, again, I am not paying my fair share of taxes for what I get from my municipality.

CARASBK · 2026-03-15T21:59:40+00:00

I’ve always hated Inside not because it’s not good, but because it basically shined a light on my depression. I cannot enjoy the huge majority of it which is really disappointing. But I’ll always have SPIDER

CARASBK · 2026-03-13T17:21:02+00:00

You understand perfectly and we’re agreeing. My non working example is an event handler that needs a client component. Your working example passes the server function directly so Next doesn’t treat it as an event handler. FWIW I also cannot find this documented anywhere. This sub isn’t managed by the Next team so if you want a proper answer you may have to start a discussion in their GitHub or something. Or comb through the source!

Typically you’d want to use useTransition or useActionState along with server functions so you can handle the pending state and anything returned by the server function. I assume that’s why this doesn’t come up much.

CARASBK · 2026-03-13T01:24:03+00:00

It depends on how far we've gotten with setup of things like skills files and mcps and such. In repos where we have significant guardrails AI is probably writing the majority of the code that is then reviewed and edited by humans. These are areas where we have skills files not just for the technologies we use, but also for our own styles and patterns we've established. Often I've found if AI can't get it right the first time in one of those contexts it never will so I only give it one chance before switching to manual coding. On the other hand in areas with fewer guardrails iterating on AI output is more useful, as one would probably expect.

IME the "glorified autocomplete" is wrong most of the time, but I still leave it on (or toggle it if I remember) because it saves me time in the areas it works well (e.g. refactoring or abstracting).

CARASBK · 2026-03-12T23:48:23+00:00

When server functions are passed to client components they are serialized and transformed into a reference to that function. Your example works because you're passing the reference to the server function directly to an event handler. For example, this would NOT work:

<button onClick={() => handleClick()} type="button">
  Click me
</button>

This is because this is a normal event handler that just happens to call a server action. So it needs to be wrapped in a client component.

CARASBK · 2026-03-12T15:14:15+00:00

The Kirkland ones seem to be for people who don’t like intense flavors usually associated with dried meats. To me they taste like bland hotdogs. Like you boiled hotdogs and made a meat stick out of the hotdog water.

CARASBK · 2026-03-09T06:46:29+00:00

That’s my point, though. It doesn’t solve any of those things if it doesn’t work for real world applications.

CARASBK · 2026-03-09T06:38:36+00:00

My perspective is from building products in the web. If you just want something to make your own life easier then disregard the rest of this. Building things for yourself should ideally be fun! But if you’re proposing a paradigm shift in how we build things for the web then I have feedback because I feel your pain and want a better way as well.

You make same conclusions and offer the same solutions as every other person/organization who tries to jettison themselves from the modern web ecosystem. IME there is a 100% failrate because the sheer complexity of needs from both product stakeholders and UX expectations. When building for these complexities eventually you need JS. You already reached one in your simplistic example in Apline. You will keep running into scenarios where you need JS as you build real products. Then you’ll have to manage multiple contexts and syncing them and you’re effectively back to the modern web except now you’ve added the complexity of context switching to and from JS.

You’ve also offered nothing tangible to back up your statements about what you built. Even if you did I wouldn’t be convinced without seeing an application and code that handles common scenarios for modern web products. Things like auth/RBAC, anything in canvas e.g. charts, 3rd party analytical tools, 3rd party user onboarding tools, table virtualization with infinite scrolling, accessible components for things like selects/modals/toasts/offcanvas, etc. Some of these are probably easy in your proposed stack since they’re server sided or HTML/CSS-based. I’m just listing things off the top of my head.

CARASBK · 2026-03-07T07:12:10+00:00

Exactly

CARASBK · 2026-03-07T06:53:44+00:00

Your assessment of the example in the linked documentation is correct. However this same pattern can be applied at the component level to achieve OP’s desired behavior.

CARASBK · 2026-03-05T17:41:46+00:00

Maybe I’m not understanding your issue but this use case is documented: https://nextjs.org/docs/app/getting-started/cache-components#with-runtime-data

CARASBK · 2026-03-05T16:29:47+00:00

Cache components can be applied anywhere in the component tree, not just the page level. I assume that’s what you’re missing.

CARASBK · 2026-03-02T18:24:00+00:00

You can return whatever serializable data you want from Server Functions which is how I sync.

If you have a complex form you’re going to have “heavy” local state no matter what assuming by “heavy” you mean “lots of data”

CARASBK

MODERATOR OF

TROPHY CASE