4 ms·

Since HTTP does not allow setting cookies after streaming starts, you can't set cookies from a page or layout directly. Next.js believes response streaming is a

by leerob 2y ago

Since HTTP does not allow setting cookies after streaming starts, you can't set cookies from a page or layout directly. Next.js believes response streaming is a tradeoff worth making, so if you don't want or need streaming, then Next.js might not be the right choice for your app. If you're wondering "why streaming?": https://vercel.com/blog/how-streaming-helps-build-faster-web-applications https://vercel.com/blog/how-streaming-helps-build-faster-web...

rgbrgb 2y ago
thanks for the link! i hear you on not having to build for everyone and it's good to take a stance and not be for everyone / every use case. dhh talked about this at railsworld recently [0]. i think i've got it working ok with the second request to update the session (as suggested here [1]). [0]: https://www.youtube.com/watch?v=zPBbHu-BKpQ https://www.youtube.com/watch?v=zPBbHu-BKpQ [1]: https://github.com/nextauthjs/next-auth/discussions/9715 https://github.com/nextauthjs/next-auth/discussions/9715
- leerob 2y ago
  If you're looking for an auth example: https://github.com/leerob/next-saas-starter https://github.com/leerob/next-saas-starter
  - rgbrgb 2y ago
    this is useful, thanks. looks like I can probably do what I'm trying to do (update cookie, return html in one request) with middleware.
hysan 2y ago
> if you don't want or need streaming, then Next.js might not be the right choice for your app. I'm glad to see this stated so clearly. It's important for frameworks to be upfront about the use cases being served and the trade-offs that are being made. I think a lot of the negativity that I see on the web is because Next.js was the right choice [for them] in the past, but once it moved towards streaming as the primary paradigm, those same people probably are feeling left in the dust. I think it would be good for the Next.js team to reiterate this and/or make it more clear in the docs so that new devs can make informed decisions when evaluating Next.js for their next project.
- rgbrgb 2y ago
  agree, this statement should be in the docs. didn’t realize app router wasn’t intended for my use case

by leerob 2y ago

rgbrgb 2y ago

thanks for the link! i hear you on not having to build for everyone and it's good to take a stance and not be for everyone / every use case. dhh talked about this at railsworld recently [0]. i think i've got it working ok with the second request to update the session (as suggested here [1]). [0]: https://www.youtube.com/watch?v=zPBbHu-BKpQ https://www.youtube.com/watch?v=zPBbHu-BKpQ [1]: https://github.com/nextauthjs/next-auth/discussions/9715 https://github.com/nextauthjs/next-auth/discussions/9715

leerob 2y ago
If you're looking for an auth example: https://github.com/leerob/next-saas-starter https://github.com/leerob/next-saas-starter
- rgbrgb 2y ago
  this is useful, thanks. looks like I can probably do what I'm trying to do (update cookie, return html in one request) with middleware.

hysan 2y ago

> if you don't want or need streaming, then Next.js might not be the right choice for your app. I'm glad to see this stated so clearly. It's important for frameworks to be upfront about the use cases being served and the trade-offs that are being made. I think a lot of the negativity that I see on the web is because Next.js was the right choice [for them] in the past, but once it moved towards streaming as the primary paradigm, those same people probably are feeling left in the dust. I think it would be good for the Next.js team to reiterate this and/or make it more clear in the docs so that new devs can make informed decisions when evaluating Next.js for their next project.

rgbrgb 2y ago
agree, this statement should be in the docs. didn’t realize app router wasn’t intended for my use case