New video about Incremental Static Regeneration a new feature in Next.js 9.5 :)
For further actions, you may consider blocking this person and/or reporting abuse
New video about Incremental Static Regeneration a new feature in Next.js 9.5 :)
For further actions, you may consider blocking this person and/or reporting abuse
Ashfiquzzaman Sajal -
Jakub Andrzejewski -
Ashok Admin -
Mark Smith -
Top comments (4)
Great video Bruno!! Muito bem! :D
The problem of using
blockingas fallback is that the user will wait until your app get done.I'm facing an issue of latency with Next.js through Firebase hosting for my project medinamg.com.br
Obrigado ❤️
Yes if you use blocking and your app takes 5 seconds to render on the server, your user will be 5 seconds with a blank screen 😊
I'm slowly coming to the conclusion that it is impossible to have a page generated with ISR that you also want to display a logged in (or Authenticated) state. That is, say I have a home page for a web site that displays a "login" link when the no auth, and with auth, it shows "logout {username}". I'm thinking that's impossible to do because there is no client side cookie available. True? If so, I'm thinking that I need to create separate routes for authenticated vs not authenticated. That is, something like mysite.com/a and mysite.com showing the same thing but one authenticated, one not. Then, all landing pages need to be mysite.com/speakers and mysite.com/a/speakers. Then if some lands on mysite.com/a and they are not authenticated, I redirect them to mysite.com
I figure every big site that wants ISR and CDN's must have this issue. I think the big issue I'm running into is the authentication header posted with the request is what I use to secure the request, and if the I post this to a CDN for example, there is no code on the CDN to process that.
Am I totally lost?
What about looking for the cookie, and updating the component's state to show that the user is logged in - would this not work on the static (ISR) pages?