Lee IMO the only thing missing from NextJS is a "native" websocket solution that works both with self-hosting and with vercel. I know pusher exists but I'm talking about a more granular hands-on approach without having to spin up a separate server. Thoughts?
literally so many extensions cause them and its happening more after upgrading to 19 + 15.1 … easy fix just disable the extensions in dev but hella annoying
Hey Lee, thank you for this update, is it possible to make a condensed version of this video without the livestream interactions for reference. That would help us who missed the livestream to get up to speed quickly.
How to make the routes feel fast like client side in server components? And how to generate static pages because every page with auth verification in it or await async calls have a lot of try catch blocks and dynamic.
I have an external backend application that when i create an order, this order is updated in the backend and i have to send the new information to my frontend, but if i use next.js caching in this pages i can't revalidateTag or revalidatePage from the external backend, because accordingly with the next.js 14 docs the data will only be revalidate if the next page accessed is the page or one page with the cache revalidated. Anyone has some work arround to this situation?
@@haiffy The problem is one part of the revalidateTag documentation that says: "The invalidation only happens when the path is next visited" How i will visit the page if route handlers are API's and i'm acessing it with another backend?
@@victor63666 the revalidate _does_ purge the cache even if you don't visit the page, the next time user visit/refresh the page they will get new data. What's your use case exactly? If you need realtime data without refreshing the page then perhaps client side polling would be better for you, you can use tools like swr subscriptions
@@victor63666 the revalidate _does_ purge the cache even if you don't visit the page, the next time user visit/refresh the page they will get new data. What's your use case exactly? If you need realtime data without refreshing the page then perhaps client side polling would be better for you, you can use tools like swr subscriptions
I still don't think this pattern for default values on form submission is any sound. There's something inherently wrong in my opinion with replacing the user input with what they had already written in the first place. 1. At face value, it's a useless override. 2. If the user finds out in anyway that you are engaging in tempering with what they wrote, you are at risk of losing their trust, and given how hard and indispensable it is to make people fill out form, and (very important) to make them do so accurately and truthfully, trust is the last thing you want to risk on a form. You can do whatever you want with the form's data once it's valid, but before that happens, the user should rest knowing that the message they're sending will not be misconstrued. 3. For scaling purposes, and the issues you've encountered make this very clear, this least amount of "controlled" values, the better. This complement point 2 in that as soon as you'll make the slightest mistake which inadvertantly will let the user know that you're tempering with their input, they will 100% be less likely to fill the form. Hopefully for all parties involved React should fix this mistake soon enough, among others I've been recently encountering. ...I hope.
Very helpful insights and best practices on how to do things the right way. You are awesome Lee!
Lee IMO the only thing missing from NextJS is a "native" websocket solution that works both with self-hosting and with vercel. I know pusher exists but I'm talking about a more granular hands-on approach without having to spin up a separate server. Thoughts?
Works bad with serverless ¯\_(ツ)_/¯ (not their business model)
I guess it's because they use serverless functions only?
What is IMO meaning ?
@@brohands-je9gg In my opinion
@@brohands-je9gg In my opinion
Thanks for this, I really learnt a lot from this, love what you did with the redirects, I have difficulties implementing it.
Great video rob❤
Thanks Lee!!
very reassuring to see that even you get lost in your own code base. 😅 Greetings from Frankfurt 🎉
All the time haha
It would be nice if react/next integrated some fix for Hydration errors caused by browser extensions like Lastpass and Grammarly
literally so many extensions cause them and its happening more after upgrading to 19 + 15.1 … easy fix just disable the extensions in dev but hella annoying
Hey Lee, thank you for this update, is it possible to make a condensed version of this video without the livestream interactions for reference. That would help us who missed the livestream to get up to speed quickly.
thanks for making this video
🚀Thank you Lee!
Could u also explain how to implement infinite scroll without using react-query?
How to make the routes feel fast like client side in server components? And how to generate static pages because every page with auth verification in it or await async calls have a lot of try catch blocks and dynamic.
What about displaying not-found within route groups?
ThAnks lee
please work on hydration error in next.js
That got me stuck in 14 version till now
Next video:
v0 writes nextjs 17
in shadcn?
why turbopack in canary reload 3 times when the code changes? isn't that normal?
So, is using use use a common use?
Hello Lee I am wondering how would I update a project using 15 to 15.1 which command in cli
npx @next/codemod@canary upgrade latest
I have an external backend application that when i create an order, this order is updated in the backend and i have to send the new information to my frontend, but if i use next.js caching in this pages i can't revalidateTag or revalidatePage from the external backend, because accordingly with the next.js 14 docs the data will only be revalidate if the next page accessed is the page or one page with the cache revalidated.
Anyone has some work arround to this situation?
You can use revalidateTag in route handler, use webhooks to revalidate from your backend
@@haiffy The problem is one part of the revalidateTag documentation that says:
"The invalidation only happens when the path is next visited"
How i will visit the page if route handlers are API's and i'm acessing it with another backend?
@@victor63666 the revalidate _does_ purge the cache even if you don't visit the page, the next time user visit/refresh the page they will get new data. What's your use case exactly? If you need realtime data without refreshing the page then perhaps client side polling would be better for you, you can use tools like swr subscriptions
@@victor63666 the revalidate _does_ purge the cache even if you don't visit the page, the next time user visit/refresh the page they will get new data. What's your use case exactly? If you need realtime data without refreshing the page then perhaps client side polling would be better for you, you can use tools like swr subscriptions
Code editor font?
32:22 🤣
Could we get a link to a github repo?
github.com/leerob/next-saas-starter
show us benchmarks.
Is this Ryan Dahl's better-looking brother?
I still don't think this pattern for default values on form submission is any sound. There's something inherently wrong in my opinion with replacing the user input with what they had already written in the first place.
1. At face value, it's a useless override.
2. If the user finds out in anyway that you are engaging in tempering with what they wrote, you are at risk of losing their trust, and given how hard and indispensable it is to make people fill out form, and (very important) to make them do so accurately and truthfully, trust is the last thing you want to risk on a form. You can do whatever you want with the form's data once it's valid, but before that happens, the user should rest knowing that the message they're sending will not be misconstrued.
3. For scaling purposes, and the issues you've encountered make this very clear, this least amount of "controlled" values, the better. This complement point 2 in that as soon as you'll make the slightest mistake which inadvertantly will let the user know that you're tempering with their input, they will 100% be less likely to fill the form.
Hopefully for all parties involved React should fix this mistake soon enough, among others I've been recently encountering. ...I hope.
neovim