So far I really like next.js app router and RSC
ฝัง
- เผยแพร่เมื่อ 12 ก.ย. 2024
- 📘 T3 Stack Tutorial: 1017897100294....
🤖 SaaS I'm Building: www.icongenera...
💬 Discord: / discord
🔔 Newsletter: newsletter.web...
📁 GitHub: github.com/web...
📺 Twitch: / webdevcody
🤖 Website: webdevcody.com
🐦 Twitter: / webdevcody
you said that you love jotai and its easy. please make video on jotai vs zustland. which one to pick according to global vs dynamic state changes.
Love the way you explain the whole Next.js 13.4 working structure. kind of loving your videos last couple of month. ♥♥
thanks man, yeah maybe I can do that
@@WebDevCody chill bro
@@gung2267 DONT TELL ME TO CHILL
Yes, I was surprised by what jotai did in this clip
as borat once said, very nice
There a couple of things that bothers me with the new app directory and server components (I don’t assume all of those to be facts, just my personal thoughts while working on refactoring my website).
1. You can use jotai or a provider or any state management library you want in client components but what if you need to access the stored state inside of a server component ? I wonder if using React-Query/SWR as a state manager would solve that problem since it can be used both on client and server.
2. It is cool to be able to load data in server components and pass it down to client components down but you still need react-query/swr if you want to automatically refetch on window focus, after some predefined time,… so that means there’s still a lot of client side fetching
3. Server actions seems to be great for handling forms but how would that work with client side form validation ? You would have to make the form component a client component then if you want to use a server action you still can using the useTransition hook but you lose the « Progressive Enhancement » according to their docs. So if the user disable JavaScript it the form won’t work anymore.
Great video, thanks for the content. I did want to make a small point though. At @17:03 you mentioned that the component was a "server component" because async was in front. That's not quite accurate. RSC are server components by default, not because they have async in front. The async simply allows you to perform awaits on data fetching. I just wanted to ensure that was driven home. (IE: If none of those functions had async in front, they would still be server components.)
Again, great video. Subbed and liked.
Thanks for pointing that out!
What console log extention are you using? The terminal is sometimes so annoying when using server components.
Console ninja
Hey man, here's a couple ways you can do types for the params:
export default function Testing({ someParam } : { someParam: string }) {
}
You can also make an interface for them, to simplify it:
interface ISomeParam {
someParam: string;
}
export default function Testing({ someParam } : ISomeParam) {
}
Can also just create it as a type instead. Please don't create interfaces and then preface them with I.
type TestingParams = {
...
}
export default function Testing({ destructure your params }: TestingParams) { ... }
@@andrewcathcart To those who read this: Please note that prefixing interfaces with I is an opinion, and entirely based on your own personal preference (or team guidelines) for the project. I currently use it because I am also a C# developer and have developed habits from that. There is nothing wrong with using I as a prefix for your interfaces in a TypeScript project.
Please keep in mind there there are subtle differences to using type vs interface in JS. One being type cannot be extended like interfaces can, among some other things. Before using one over the other, ensure you look into the restrictions and see which one is right for you.
@@_Sonato Prefacing I for interfaces is entirely redundant. Same for prefacing types with T. Yes it is an opinion, do what you want at the end of the day, but it makes code harder to refactor later. If I change it from a type to an interface or vice versa I have to change all call-sites. Not ideal.
@@_Sonato Also note that you can absolutely extend types, or you can use an intersection, or you can use Pick or Omit on a type.
My approach:
interface pageProps {
params: {
testingId: string;
or:
testingId: string[ ];
};
searchParams: URLSearchParams;
}
Have you tried turbopack yet? I used it in small app router side project and I really liked the DX and overall performance. Without it next13 feels kinda sluggish. To try it you can just add --turbo flag to run dev command.
Btw, thx for your content.
Yes, very very nice! ❤
😘 like you baby
Have you tried using the app directory with tRPC or GraphQL yet? If not, would love to see a vid on that. I’m struggling to understand how data fetching with React query works in this new design paradigm.
Your initial data fetching should happen in the RSC. You can do fetch() and then use that data in rendering your RSC. You can also still have REST endpoints (possibly through alpha server actions if you want) that can respond to data fetching requests from your client component
So the actions.tsx worked or not?
man for params you can just go
interface Props {
params {
id: string;
}
}
then you can go
const page = ({ params: { id }}: Props) =>
right, but why doesn't next provide a interface or type already for us?
what's that little extension that captures server logs next to console.log?
console ninja
Oohhhh I didn't know about layout... I just kept copy/pasting my application frame into every page.
I am getting 404 page not found error even though i enter the correct url on the web.. 😢 i could not resolve that... I know i made silly mistake but i can not figure it out please help me..
But.... isnt it better to load those 20, put them in a store/provider for later, and then if the main view needs it load from server if necessary when the store doesnt havent it? Why is rendering on server actually better for this stuff? I'm still just missing some of the applications for this...
I guess the SSR side of things allows the response to come back to the user faster than letting the user initialize the UI and then later make a request for the data
What folder file icons are you sing i like the simplicity
Bearded icons
Veeery nice video!! People are using "{/* @ts-expect-error Server Component */}" above RSCs for now
its fixed in TS 5.1
@@Dev-Siri Nice to know!!
Isn’t the HMR really slow for you? Compared to pages I mean?
it does feel a bit slower at times
what is the shortcut to auto import library?
Go to end of word e.g "LibUwantToImport|" the | in the end is your cursor and press ctrl + space
hey, could you do a livestream on continue working on ur course platform?
yeah I probably will this weekend
What is the VSCode theme you're using?
Bearded theme
why you use Typescript without types? that makes no sense
because I like seeing red swiggles
Which vs code theme are you using?
bearded theme
Hi
hi there
Yo Cody unless you already made it, I think a video on how you built your whole ai project from start to finish, with the wireframe, to the specific technologies would be great, and hosting. Something like this th-cam.com/video/4G5t1HwHQD4/w-d-xo.html
I have a course that explains how I build a subset of my ai site
Interface ParamProps {
params: {
id: string
}
searchParams: {}
}
Passed in as ({ params }: ParamProps)
right, but I have to manually declare that. I was wondering if Next provides an existing type so I don't have to declare one myself?
@@WebDevCody I ended up with creating a utility type by myself. But yeah, there are some things that should be added (but first of all, allow prefixes for pages)
Oh yeah na I couldn't find anything built in they have a different way of doing it in the docs but I found this was easier to read