useEffect infinite loop: It happened to me twice in 3years+ working with useEffect and somewhat was pretty sure what's the issue. I don't see the point people are even mentioning it.
This was also my favorite part of the con. When I shared the concept with my team, a sr dev just dumped all over me, as another coworker put it “it got really cringe”. I love the idea of a fully contained component that handles its own business so it can be dropped in anywhere.
The issue is that it's not gonna be constant. The requirements will change and you'll end up looking for a solution to manage versions of components rather than APIs. So the same problems that we have with APIs will just be in react land.
I look at it more in the light of a specific type of component for App Router apps that speeds integration for that environment. It wouldn’t be the only way to integrate, it would be one of many options.
`select * from blogs` in the Lego block is SQL. The database has a shape. The server component at least depends on the database shape. The database shape is not communicated or shipped. If you shipped it, it would likely have data dependencies. Trying to delegate schema migrations as Lego is non-trivial. I'm sure you could do it but you'd have to have a stable interface, a better boundary would be the network which they should know by now because they have already done it.
The pain point is to configure the UI library like Shadcn to works fine in Monorepo or ? Need to share some config file, and path aliases on root project.
I think it is cool that we can delegate all requests to the server and just focus on what is really supposed to be client-side, perfectly balance app should hide all the backend logic from the client component as much as possible I thing
Wouldn't it be better to use revalidateTag instead of revalidatePath? That way the component would be able to revalidate its own fetches upon mutation, without users of the component (the page) having to do anything at all.
somehow makes me feel nostalgic thinking back on my ember.js days... iirc an ember plugin could even add routes (we can argue how useful that is, but there might be use cases). loved its convention over configuration approach, probably that's why I'm so interested in next.js now :)))
@Jack how I can migrate outlets from react-router-dom to app router in nextjs14? How is possible to execute rootLayout, one nested layout and then one more level deep render the page and the url from './' to shown /path1/path2? next.config.js redirects not helping at all... i'm getting 404 not found...
That's a little too complicated for a UA-cam comment. You should join the Blue Collar Coder Discord server and ask you question there in the #react channel. But please, read and follow the #rules first, you are going to have to give a lot more information if you are going to get a reasonable answer.
Since all of the list functionality is hidden within a library, how would you do something like updating a blog post count from a component not nested without the list loader?
Nice aspect of RSC for sure. Not super fan of using client side state to update rows. I haven't tried but couldn't revalidateTag be an interesting alternative?
is updating on the client via data sent from a server action a recommended pattern? i wrap these things in a suspense and just revalidate my path. with new hooks like useOptimistic in the pipeline I'm not so sure about the pattern you showed. also in this case why is input state stored in hook and not part of the formData api?
Love actions and genuinely like the direction we are heading and these new Lego blocks, but I ran into some snags recently that I'm hoping get ironed out. 1. Client fired actions are queued so there is no way to run actions in parallel. 2. Next is discarding promises in flight when a user navigates to a new page without resolving or rejecting the promise. This is a major flaw when wrapping actions in external async management tools like react query. React Query ends up in an endless fetching state when the action is discarded because it's looking for it to either resolve or be rejected. I was trying to move everything away from API routes and handlers but ran into these issues which made me pause and rethink my strategy a little. Maybe the next team isn't considering actions for data fetches as a use case, but I'd love to be able to skip an API layer when the only client is my frontend. 😅 Have you tried fetching data with an action instead of just RSCs?
Yea it definitely works but I ran into issues with parallel fetches and promises being diecarded. Example: I was showing the most recent action on a bunch of user cards fetched with an action. All the last actions data for each card were supposed to fetch in parallel with useQueries. Unfortunately they are queued so they still execute one at a time. If a user was impatient because user 3 had resolved but user 12s last action was still in flight or was in the queue when they clicked to navigate to the user prolife page the action got discarded. So when you navigate back to all users that query is in an endless fetching state unless I manually cancel the query. Found the issue in Nexts repo though and am writing up a quick PR that would ensure that actions are at least rejected on navigation and not just discarded.
@@jherr If i had to guess probably to maintain consistent application state and discarding to improve performance. Since they are feeding the state of the promise back to the client with startTransition it probably introduces some complexity and performance concerns for tracking the state of parallel promises. Seems like they can either create a saved state on navigation with all the pending actions in the queue and restore and try again after the navigation event or just reject the promises that are pending. I'd be fine with a rejected promise so at least external state management tools could pick it up and refetch when needed if there are performance concerns with the first option.
Changing the action queue or removing it to process actions in parallel would be a fundamental shift in how actions are processed in Next. Probably won't get those for a little while but I am keeping my fingers crossed.
This is going to backfire for sure in less than a year. Now everyone will quickly realize that this leads to waterfalls unless you follow some steps, so we need a compiler like Relay to aggregate and fire requests together to prevent waterfalls. This is spectacular for MVPs and throwaway apps. But for anything even mildly important this is not going to scale.
Did Turso create the 'packages' folder? Could someone explain why the component was dropped inside that 'ui' folder for him to use? Is this almost a microfrontend approach?
It was Turborepo that made the packages directory. Turso is _just_ the database. And yep, it's a build-time micro-fe since it is a self contained piece of UI that communicates with it's own service layer (in this case the DB).
@@jherr, Thats really interesting. May I ask why you used Turborepo for this? I was under the impression it was a nextjs project or does this approach allow for this architecture whereas Next is the monorepo style?
@@robjjohnsen The app is a NextJS project within a Turborepo. I chose Turborepo because it makes it really easy to do TypeScript type sharing between projects so it made for an easy demo. You don't need to do it monorepo style, you could do it with multiple repos and a public or private package repository. The value in putting it in a library (monorepo or not) is that it can be reused between applications.
@@jherr Ok, I really like this approach. Turborepo would be the package repository in this instance? I need to do more reading on this (or if you have a video from your library that you could point me to) . Thanks Jack
@@robjjohnsen npmjs.com, where you download the modules from when you do npm install [a module name], is a package repository. You can also self-host your own package repository for private packages. Package repositories contain built and versioned packages. Repos and mono-repos contain the source code for apps or packages. Those apps can be deployed once built, and those packages can be uploaded to a package repository once built.
Great video and love your content. I'm a little unsure why you would want to ship your components tho. I like the whole idea of self-contained components, I definitely dig that, but I feel like most companies will probably not want to ship their components anywhere anyways, which kinda invalidates the whole brick (Lego) argumentation. You could probably argue that you'll still get the brick benefits without having to ship them, but really, practically, when you app is running, how often do you need to move things around, and what benefit do you really get? I'm unsure, maybe I'm just not the right receiver of this message :)
Are there any other ways to do this (import server and client code in one component / in one input) in react or in another framework. For instance can you do this with TRPC somehow? Also Is there a way to do this in vue for example?
Hey Jack and the rest of the community !! I watched your video on UA-cam about the Lego Blocks Architecture of Next.js with Turbo I've been trying to conceptualize the same Blogs application with Turborepo where the package can have other routes nested within it Like for example, I would want to keep the form for creating the Blogs in a new route `/blogs/create`, the display all Blogs in the `/blogs` route and view a single blog in the `/blogs/[slug]` route. I haven't been very successful with it. How can we implement such a Lego Brick Architecture for Blogs ?
I learned react last year. I liked it a lot. Now I don't like the direction of react plus these wild nextjs features. Maybe for small hobbyist projects where you are responsible for the frontend, backend and the database it's fine but for massive projects where lots of people are involved it doesn't sound good.
This is WAY cleaner than the NextJs 14 presentation. Single responsibility is better rather than mixing wrong things in the right scope. I can celebrate the SSR thing but make it in a way that is not a rape on the eyes of everyone.
Storybook does not support RSCs yet, but they are working on it. Im currently having to do some silly work arounds right now, can’t wait for them to release an update to support them.
I recently looked into a frontend application written entirely in vanilla JS and XHR calls. I could not believe how much simpler and easier to understand that code is than 90% of the overly abstracted shit being produced today in react / angular / svelt / etc... We've really gone too far into "making things easier".
Imagine, you don't even need components. Just html elements themselves magically call your DB server, or any server, just give them all of your credentials. Wow! You don't need to worry about anything! I mean, why the egg-headed people invented layers of abstraction and separation of concerns, if it just complicates things, and we just put our sql right in the attributes of the html div? We don't even need typescript or anyscript anymore. Awesome!
Embedding action in a form breaks progressive enhancement, to make it work you need to store action in a separate file and this breaks the concept of self containing components.
It's interesting to see the industry move towards FE driven design. It makes a lot of sense as manipulating these points of action is far easier on the FE than it is to create a new endpoint with a new set of queries and parameters. By having the component encapsulate both the FE and BE logic for each feature you bridge that gap all in one easy to see location. I'm really liking where NextJS is going with this.
A whole bunch of react nextjs programming hides and obfuscates any Lego aspect. So, I looked at some Lego's in front of me and it is whole lot simpler, 1 brick plus another brick connected done. The bricks are opaque, this session was anything but opaque. I had to know a whole bunch of things and perform a whole bunch of things. Same amount of effort, but in a different way. I'm not feeling it as the best part.
I have yet to see anyone convince me switching from Pages to the App router is a good idea. Jack tried to make some good points, but nothing he mentioned is simpler or more powerful than doing it the original NextJS way. Vercel really screwed the pooch going all in on RSC, and I feel like this is going to hurt them in the long run.
I think we are going back to the stone age when it comes to web. For all their faults, when SPAs were king we had some cool looking websites with slick animations and interactivity and they felt like an application. They were maybe a little slower, but it didn't feel like it for the most part. Now, with this huge SSR push and focus on server component that can't even have interactivity, it feels like we're back to the stone age browsing actual documents on the web. 😴😴😴
I agree, that's why I use Solid instead. Interactivity, better dx, Typescript by default, and super fast and lightweight, much more than React. Plus it's super easy to use compared to React
react is really just lego.
you can build the web apps of your dreams
or scream in pain when you step on the useEffect infinite loop
Text content does not match server-rendered HTML
useEffect infinite loop: It happened to me twice in 3years+ working with useEffect and somewhat was pretty sure what's the issue. I don't see the point people are even mentioning it.
U move your useEffects calls into routes as actions
This was also my favorite part of the con. When I shared the concept with my team, a sr dev just dumped all over me, as another coworker put it “it got really cringe”.
I love the idea of a fully contained component that handles its own business so it can be dropped in anywhere.
The issue is that it's not gonna be constant. The requirements will change and you'll end up looking for a solution to manage versions of components rather than APIs. So the same problems that we have with APIs will just be in react land.
I look at it more in the light of a specific type of component for App Router apps that speeds integration for that environment. It wouldn’t be the only way to integrate, it would be one of many options.
@@StingSting844then don't use SQL in your component, just call an API.
`select * from blogs` in the Lego block is SQL. The database has a shape. The server component at least depends on the database shape. The database shape is not communicated or shipped. If you shipped it, it would likely have data dependencies. Trying to delegate schema migrations as Lego is non-trivial. I'm sure you could do it but you'd have to have a stable interface, a better boundary would be the network which they should know by now because they have already done it.
Great video , that is a power of composition :)
The pain point is to configure the UI library like Shadcn to works fine in Monorepo or ? Need to share some config file, and path aliases on root project.
It is always fun to do integration and unit test's for components that's have hidden any networking inside them.... NOT
I think it is cool that we can delegate all requests to the server and just focus on what is really supposed to be client-side, perfectly balance app should hide all the backend logic from the client component as much as possible I thing
Thank you for this excellent breakdown!
"We can't update the component library for this button until we run these database migrations. "
Wouldn't it be better to use revalidateTag instead of revalidatePath? That way the component would be able to revalidate its own fetches upon mutation, without users of the component (the page) having to do anything at all.
My thought exactly. You can wrap any data in the next cache API and use it to set a tag that you can later revalidate.
Feel likely goings back to old days with php, which is actually quite nice
somehow makes me feel nostalgic thinking back on my ember.js days... iirc an ember plugin could even add routes (we can argue how useful that is, but there might be use cases). loved its convention over configuration approach, probably that's why I'm so interested in next.js now :)))
So , isn't this some what similar micro-frontend, although we can now have data and component both abstracted?
@Jack how I can migrate outlets from react-router-dom to app router in nextjs14? How is possible to execute rootLayout, one nested layout and then one more level deep render the page and the url from './' to shown /path1/path2? next.config.js redirects not helping at all... i'm getting 404 not found...
That's a little too complicated for a UA-cam comment. You should join the Blue Collar Coder Discord server and ask you question there in the #react channel. But please, read and follow the #rules first, you are going to have to give a lot more information if you are going to get a reasonable answer.
Since all of the list functionality is hidden within a library, how would you do something like updating a blog post count from a component not nested without the list loader?
You have to have an RSC to handle the server action. Either that or expose an API endpoint, which you can’t do directly from a component.
Why can’t we use react query and next js API routes?
Feels easy to me
Idk
these lego blocks only work if you rewrite your app using legos
I just had a flashback to the first time I watched a Ryan Bates Railscasts
Nice aspect of RSC for sure.
Not super fan of using client side state to update rows. I haven't tried but couldn't revalidateTag be an interesting alternative?
Hi Jack,
Can you please put up a video discussing about app router and next 14 support with module federation?
There is no official support that I know of.
whats the difference between RTK Query and createAsyncThunk i,am highly confused
is updating on the client via data sent from a server action a recommended pattern? i wrap these things in a suspense and just revalidate my path. with new hooks like useOptimistic in the pipeline I'm not so sure about the pattern you showed. also in this case why is input state stored in hook and not part of the formData api?
Love actions and genuinely like the direction we are heading and these new Lego blocks, but I ran into some snags recently that I'm hoping get ironed out. 1. Client fired actions are queued so there is no way to run actions in parallel. 2. Next is discarding promises in flight when a user navigates to a new page without resolving or rejecting the promise. This is a major flaw when wrapping actions in external async management tools like react query. React Query ends up in an endless fetching state when the action is discarded because it's looking for it to either resolve or be rejected.
I was trying to move everything away from API routes and handlers but ran into these issues which made me pause and rethink my strategy a little.
Maybe the next team isn't considering actions for data fetches as a use case, but I'd love to be able to skip an API layer when the only client is my frontend. 😅
Have you tried fetching data with an action instead of just RSCs?
I built a search page using server actions and it worked just fine. So you can definitely just make data requests.
Yea it definitely works but I ran into issues with parallel fetches and promises being diecarded. Example: I was showing the most recent action on a bunch of user cards fetched with an action. All the last actions data for each card were supposed to fetch in parallel with useQueries. Unfortunately they are queued so they still execute one at a time. If a user was impatient because user 3 had resolved but user 12s last action was still in flight or was in the queue when they clicked to navigate to the user prolife page the action got discarded. So when you navigate back to all users that query is in an endless fetching state unless I manually cancel the query. Found the issue in Nexts repo though and am writing up a quick PR that would ensure that actions are at least rejected on navigation and not just discarded.
@@pdesmay Good on you for doing the PR! Well done!
Any thoughts on my SAa are queued?
@@jherr If i had to guess probably to maintain consistent application state and discarding to improve performance.
Since they are feeding the state of the promise back to the client with startTransition it probably introduces some complexity and performance concerns for tracking the state of parallel promises.
Seems like they can either create a saved state on navigation with all the pending actions in the queue and restore and try again after the navigation event or just reject the promises that are pending.
I'd be fine with a rejected promise so at least external state management tools could pick it up and refetch when needed if there are performance concerns with the first option.
Changing the action queue or removing it to process actions in parallel would be a fundamental shift in how actions are processed in Next. Probably won't get those for a little while but I am keeping my fingers crossed.
This is going to backfire for sure in less than a year. Now everyone will quickly realize that this leads to waterfalls unless you follow some steps, so we need a compiler like Relay to aggregate and fire requests together to prevent waterfalls.
This is spectacular for MVPs and throwaway apps. But for anything even mildly important this is not going to scale.
great jack!
Did Turso create the 'packages' folder? Could someone explain why the component was dropped inside that 'ui' folder for him to use? Is this almost a microfrontend approach?
It was Turborepo that made the packages directory. Turso is _just_ the database. And yep, it's a build-time micro-fe since it is a self contained piece of UI that communicates with it's own service layer (in this case the DB).
@@jherr, Thats really interesting. May I ask why you used Turborepo for this? I was under the impression it was a nextjs project or does this approach allow for this architecture whereas Next is the monorepo style?
@@robjjohnsen The app is a NextJS project within a Turborepo. I chose Turborepo because it makes it really easy to do TypeScript type sharing between projects so it made for an easy demo. You don't need to do it monorepo style, you could do it with multiple repos and a public or private package repository. The value in putting it in a library (monorepo or not) is that it can be reused between applications.
@@jherr Ok, I really like this approach. Turborepo would be the package repository in this instance? I need to do more reading on this (or if you have a video from your library that you could point me to) . Thanks Jack
@@robjjohnsen npmjs.com, where you download the modules from when you do npm install [a module name], is a package repository. You can also self-host your own package repository for private packages. Package repositories contain built and versioned packages. Repos and mono-repos contain the source code for apps or packages. Those apps can be deployed once built, and those packages can be uploaded to a package repository once built.
Great video and love your content.
I'm a little unsure why you would want to ship your components tho. I like the whole idea of self-contained components, I definitely dig that, but I feel like most companies will probably not want to ship their components anywhere anyways, which kinda invalidates the whole brick (Lego) argumentation.
You could probably argue that you'll still get the brick benefits without having to ship them, but really, practically, when you app is running, how often do you need to move things around, and what benefit do you really get? I'm unsure, maybe I'm just not the right receiver of this message :)
Are there any other ways to do this (import server and client code in one component / in one input) in react or in another framework. For instance can you do this with TRPC somehow? Also Is there a way to do this in vue for example?
Possibly Qwik. Nothing else that I’m aware of.
Now do this with Qwik using Loader, Action, and Server$ :)
Hey Jack and the rest of the community !!
I watched your video on UA-cam about the Lego Blocks Architecture of Next.js with Turbo
I've been trying to conceptualize the same Blogs application with Turborepo where the package can have other routes nested within it
Like for example, I would want to keep the form for creating the Blogs in a new route `/blogs/create`, the display all Blogs in the `/blogs` route and view a single blog in the `/blogs/[slug]` route. I haven't been very successful with it.
How can we implement such a Lego Brick Architecture for Blogs ?
Hello sir.Will you make Nextjs14 series for us pls?
hope your arm is fine now!
wow great I have always hated separation of concerns /s
Love your content Jack, can you make a video on error handling - forms, backend errors etc
I learned react last year. I liked it a lot. Now I don't like the direction of react plus these wild nextjs features. Maybe for small hobbyist projects where you are responsible for the frontend, backend and the database it's fine but for massive projects where lots of people are involved it doesn't sound good.
Isn't this PHP all over again
Can we use that feature with module federation ?
NextJS has always had issues with Module Federation, so my guess is no.
Great video! I would be careful with the term Lego though. The "friendly" danish company is very stringent with its trademark 😅
Vercel is a bigger target than me
Robert');DROP TABLE *;-- has entered the chat
Wow, Thank you Jack.
very good explained.
and .......Yeaaaaaah Lets GO, lets put SQL in the component. 😂
This is WAY cleaner than the NextJs 14 presentation. Single responsibility is better rather than mixing wrong things in the right scope. I can celebrate the SSR thing but make it in a way that is not a rape on the eyes of everyone.
Sorry, Lego was fun at the time but it's hard to go back after fischertechnik.
Looks super neat, is there any tooling that exists for RSC's yet like storybook?
Storybook does not support RSCs yet, but they are working on it. Im currently having to do some silly work arounds right now, can’t wait for them to release an update to support them.
I recently looked into a frontend application written entirely in vanilla JS and XHR calls. I could not believe how much simpler and easier to understand that code is than 90% of the overly abstracted shit being produced today in react / angular / svelt / etc... We've really gone too far into "making things easier".
You should check out HTMX.
Time to fire our backend developers.🤣
Imagine, you don't even need components. Just html elements themselves magically call your DB server, or any server, just give them all of your credentials. Wow! You don't need to worry about anything! I mean, why the egg-headed people invented layers of abstraction and separation of concerns, if it just complicates things, and we just put our sql right in the attributes of the html div? We don't even need typescript or anyscript anymore. Awesome!
Embedding action in a form breaks progressive enhancement, to make it work you need to store action in a separate file and this breaks the concept of self containing components.
I guess I'm done with react and other stuff ❤
It's interesting to see the industry move towards FE driven design. It makes a lot of sense as manipulating these points of action is far easier on the FE than it is to create a new endpoint with a new set of queries and parameters.
By having the component encapsulate both the FE and BE logic for each feature you bridge that gap all in one easy to see location.
I'm really liking where NextJS is going with this.
for the rest of us, what is FE again?
@@feldinhoFront End? Or do you mean the line between FE and BE is blurring?
@SomeDude-gs7om Nope. I just didn't know what they meant for "FE driven design", and googling it verbatim didn't help.
A whole bunch of react nextjs programming hides and obfuscates any Lego aspect. So, I looked at some Lego's in front of me and it is whole lot simpler, 1 brick plus another brick connected done. The bricks are opaque, this session was anything but opaque. I had to know a whole bunch of things and perform a whole bunch of things. Same amount of effort, but in a different way. I'm not feeling it as the best part.
You won't ever use this stupid form twice, what's the point of creating this package
“use php”
That is an actual thing
Again top notch Video. But too fast and too less explanation, eg what does revalidatepath do. No word about it
Endless React >>> Endless Next , i am tired.
wow
i have a sense like next 12 was the best so far
I have yet to see anyone convince me switching from Pages to the App router is a good idea. Jack tried to make some good points, but nothing he mentioned is simpler or more powerful than doing it the original NextJS way. Vercel really screwed the pooch going all in on RSC, and I feel like this is going to hurt them in the long run.
@@coherentpanda7115 totally agree
I think we are going back to the stone age when it comes to web. For all their faults, when SPAs were king we had some cool looking websites with slick animations and interactivity and they felt like an application. They were maybe a little slower, but it didn't feel like it for the most part. Now, with this huge SSR push and focus on server component that can't even have interactivity, it feels like we're back to the stone age browsing actual documents on the web. 😴😴😴
You can still have interactivity. Server components let you opt in to client components when you need them
Client components are client components, server components are server components. You are confused about terminology.
I agree, that's why I use Solid instead. Interactivity, better dx, Typescript by default, and super fast and lightweight, much more than React. Plus it's super easy to use compared to React
Client components aren't even fully client. Try using local storage without use effect or some other browser api
We still have interactivity through client components.
I hate react so much its unreal
I hate Nextjs since 13. I'm sorry.
whats the difference between RTK Query and createAsyncThunk i,am highly confused
whats the difference between RTK Query and createAsyncThunk i,am highly confused
whats the difference between RTK Query and createAsyncThunk i,am highly confused
whats the difference between RTK Query and createAsyncThunk i,am highly confused