I'm a junior developer and have been following your channel for a while now because your courses are so easy to understand. However, I was wondering if you could make videos about how to maintain and update a project when there are new packages and/or frameworks versions, and how to configure things like imports, Prettier, etc. We always see videos about coding, but I think configuration, infrastructure, and maintaining projects are also very important.
You’ll never get him to do this because frankly it’s a very difficult topic that is quite deep. And he goes very surface level on most topics on TH-cam. For example, something like Zustand is great. So this video is kind of moot
This was an amazing video! Specifically, I liked you going through a short summary of the history where you explained problem -> solution, problem -> solution. I think it is infinitely more useful to understand why things are used/developed as opposed to the common 'this is industry standard, use this for x'
I have literally spent the last month removing impossibly intertwined and implicit state and putting it in the URL. This has allowed for deeplinks, bookmarking and easier to read code, test and re-use code. I am of the opinion you most likely don't need state management in almost all work you do. Thanks for the vid!
Zustand is so good that you should not bother with reducer and context hooks other than to feel how painful it is to use them, so that you would be able to appreciate zustand even more.
For super complex web Apps I have been leaning for Redux for global state and localized hooks for fetching and very localized contexts for purely sharing props to avoid excessive prop drilling. This way you can avoid context hell and make it a rule to not make contexts dependent on each-other.
I avoid using state management libraries until I have an exact use case for one in the project. It's surprising how far you can get without having any need for one
I basically use only RTK for the login reducer with persist to keep the user logged, and RTK query (so same package) for api fetch because it manages the cache and allows me to avoid too many requests to the backend. That's it.
@@marvinkr you can get all the examples on RTK query docs. Also RTKQ allows you to avoid using useEffect, cause it reloads automatically the widget on data change. Also you can launch multiple fetchs sequentially using "skip" option, so convenient!
The code gen for rtk query is really nice too. If you have accurate openapi specs for your back end (either because you define the openapi spec and also generate the backend, or you generate the openapi from your backend) then you can just run a command to have all of your data fetching and mutations created for you automatically.
Finally someoone who understands what I have always said. Nice video and great explanation. 90% of the time you do not need state management! keep your code clean and if you don't need some fancy library then don't use it. You are only "prop drilling'" if your only going way too deep into your components. Love you Web Dev. GREAT VIDEO!
Well the biggest reason to use state management libraries is one - they store the states separately from the app wrapper, so components are rerendered only when THEIR state changes. Problem with useContext etc is that it is a wrapper around and if one single state changes, everything related to that wrapper will rerender too. Which is a huge deal when ie. you have some table with plenty of inner components and data. That means every single cell of that table, every single component (ie button in a row) will rerender just ie. because one state of one button in that table has changed…
No, please don't use Context with Reducer for state management. It is not optimal (re-rendering due to the lack of selectors), much boilerplait needed especially in TS. Jotai is much better option if you need to manage global client state.
This. I ran into a problem because of this like 2 years ago and it was painful to debig and fix. Context is good but shouldnt manage a global state, it is not the purpose of it
Kyle, thank you for the right info. I love your explanations. I just about to brush up state management in React. You gave the view of all the state panorama. I have still many things to learn. Really waiting for your next video with the project you mentioned.
I've been a huge fan of what Preact Signals has done for React. I've been using that for state management on the client side. (And it's also really smooth for passing state around in Svelte).
React Context is a robust and easy-to-use solution for state management. In my experience, it has proven to be highly effective and free of issues. There is considerable debate regarding the use of URLs to store state. It's important to note that search parameters should be used specifically for conducting searches, not for general state storage. While storing state in a database might make sense in some scenarios, it can be impractical for managing UI-related, client-side state. Frequent re-fetching of data from the server can introduce unnecessary complexity and friction. Instead, maintaining state on the client side often leads to a more seamless and efficient user experience.
Great video. I tried to apply the new knowledge to my project but failed. **Project structure:** ``` dashboard dashboard\p1 dashboard\p2 dashboard\p3 ``` All four pages work with the same data (a single supabase query) within authorized zone, but in a different way. Currently, to navigate through these four pages, I make 4 identical database queries on every page and receive the same response 4 times because the query is executed at the SSR page level. How can I do this properly?
Only read the title, not yet seen the video itself, but thought : "Thats why we're mainly using selfcoded stores written in plain Java/TypeScript living in the module scope of the application, keep it simple, keep it small".
I haven't even watched your video yet and I 100% agree, react standard library for state is brilliant, I'll watch the rest of the video to be even more convinced tomorrow.
I think passing state down the tree is not the main problem a state management library solves. The really nasty side of react is dealing with a state that's an object, containing arrays of objects, etc. It becomes very difficult to correctly merge updates to this state to avoid unnecessary re-rendering, or to force re-rendering when needed. This is the most nasty and difficult part or react, which they didn't really solve to this day, and that's why all those libraries were invented and continue being invented - to deal with state updates. State passing can be solved with the context, but state merging is still a big pain and Achilles' heel of the whole react universe. I was spending endless hours trying to figure out unexpected rendering issues every time (which you don't have direct control over as it's all react magic which is the worst part) until tried MobX and it finally all started working together just like I always expected without any weird unexpected side effects.
This is the things I've still strugle with.., sometimes 😄.. I want to use just an old vanilla javascript or jquery that what I had known for almost 20yrs alongs with php. Main purpose I learn react is it can be used for mobile app. ah.. maybe it just because my brain isn't fresh anymore 🤣🤣
True. This video did not mention the rerendering issue in Context API, which is a really big deal when working with a big app and every bit of performance is important.
Thank you! This is true. I started with React and chose not to add Redux until I was familair with what React offered first. That way If I decided to upgrade to Redux later I would know why and have a clear understanding of the differences. 3 years later and I have not had a clear case to add Redux yet. I have a middle tier Web API, and a back-end, so the frront-end is not handling everything. Thank you for the explanation.
here's my opinion on state management. you need 3 types of states. global client state, server state or async state, and scoped state (client state under a single branch of the app tree, basically only considered global for the children of the component where they are defined). I prefer Zustand, reaact query and context for them in order.
Agree but for the third I would add the following: As long as the tree hierarchy in that "ui-branch" is not too deep and complex (and not expected to), try to use as much local state and other techniques like prop drilling as possible and only use context if necessary. This will "force" the devs early on to really think about seperation of concerns and clean architecture instead of putting everything in a semi-global state (making it better for testing and maintainability)
@@aliasalias510 it doesn't scale well. If it's 2 or 3 components deep it's fine but if you drill deeper it becomes a nightmare. I inherited a big project that has that issue. It forced me to think about context for components instead of for the app.
I used only contexts/reducers in my last few projects and it was a best decision I made. For more complex state I use two combined contexts - one for state, one for actions and it works perfect
I somewhat disagree. Though your project may begin as a simple app not needing global state management, it may grow in complexity and features pretty quickly, and useContext, useReducer will not scale. Why not start with a global state manager, though there may be a bit more setup and boilerplate code, it will scale and is pretty simple to implement.. Don't really understand the dis on redux. That lib with redux-saga allows to build large projects that once setup will just work. Lower maintenance, ease of testing need to be considered.
I think Redux has a bad rap due to the initial boilerplate it required. Modern Redux doesn't have that. Even the reducers you write are much simpler than the old days due to its use of the Immer lib. It's akin to saying React sucks because of the way it implements mixins (i.e. ancient history). When I started using RTK I was hesitant but it's been a great DX. I'm not sure I agree about redux-saga though (just use RTK Query)...
I agree that you shouldn't use a state manager until you need it, (same with every library, pattern, and so on). But they are still needed in the real world, code youtubers always make these absolute statements and all they do is very contrived examples.
So if a webapp has not to many states we can use nextjs but if it has to deal with to many states and state changing (interactions) we should use react?
Seems you think NextJS is a state manager. No! In React or any framework, if your state is not too complex, you can use useState to manage state. If you want, you could also use URL based state management. If a considerable amount of state is shared (global), then you should use a State Management library like Zustand or Jotai or Redux
10:57 If the things qualified as a webpage, not as a webapp, you dont need even react or nextjs, that's it. But I agree that a lot of usecases implemented as a specialized hooks/libs, you don't need to implement it from scratch on your favorite state manager.
I'm using Nextjs and i already figure it out that state was no longer needed in my application because i prefer using SSR and page be generated server side to gain performance which is a great thing but when you have client interaction to filters blog for example , i thought there were no other way to deal with states so thank you so much for the URL parameters tips , didn't think about that and i'm gonna apply this idea right away :)
Many websites need maintainers. As a good developer, it's important to understand state management. If you're a beginner, I highly recommend learning state management before you get lost in complex projects.
This follows what I believe as well, though I happen to be in that 1% that’s working on a complex state heavy web application. I will say tools like Tanstack query and redux toolkit (in particular rtkquery) go a long way in reducing the need to worry about state (these libraries let you treat data from endpoints as external state so to speak). Not usually used with nextjs but we aren’t using next
Prop drilling is one problem. The other one is they should rename the "react developer" job position to a more appropriate one - "machine for spread operators". xD And since some state management libraries allow me to actually think of the solution and work properly with the data instead of using spread syntax all over the place I am very happy with them. Redux is not the chosen one ofc.
It will break the pattern of one way data flow and immutability of React. Therefore, putting state on global variables will make it hard to debug and causes unexpected behavior.
THIS is the video I've been looking for! Thank you so much for sharing the latest features in React that remove the need for state management libraries. I'm building a social media website (similar to twitter), based on your video this would be a good use case for state management libraries like Redux? Appreciate any feedback (btw just subscribed)🙏
To sum up the comments: - Unexperienced devs: Yaaay it is so simple, thank you! - Experienced devs: Yeah no, state managers very much do have their right to exist and totally make sense at a larger scale.
Running in production on NextJS app router since February and now the only thing I use global state management for anymore is turning modals that are shared across components (a navbar and the page) on and off.
Remember, State management is an art. You'll learn by making mistakes! State updates cause re-renders, and therefore poor state management leads to several unnecessary re-renders which causes performance overheads. Zustand, Jotai, etc make state management and state updates much smarter - they only update those components which use the state that has changed. State management doesn't always mean bringing out the big guns in the form of Zustand, etc. Sometimes, a local state variable or a ref variable should be enough. It all boils down to YOUR understanding of the type of state management solution that is required for a given problem...
but what about rerenders... i am having this problem when i update state in any way, everything rerenders and probably in the end will slowdown my app. i have no idea how to do this and where to look for it
Almost two year ago we completely left out from all state managers like redux mobx so on and now just react context and react-query, it's enough to build any apps you would needed
As soon as I have a form I usually want mobx state management that 1. binds form elements to properties of objects and 2.updates the UI when the properties change from a load operation (for example). I wouldn't know how to do this differently without increasing the boilerplate.
It depends on how complex your business logic and application is. I wouldn't dream of not having a store for what I work on. Legend-state is my recommendation as signals make computed/derived data trivial.
Hot take... Avoiding prop drilling comes down to component composition.... That's literally it. If you need to pass state down two components, just lift the part of your component that needs the state to the parent and there is no longer a problem. Then render the children using {children} in your child component. (or by passing multiple props) You just have to think a bit about your data flow and refactor on the fly if you need more deeply nested components. I've been using react for a long time and I've never had an issue with prop drilling even with very complex state.
Also, signals are a complete stuff up in my opinion. You have no idea where data is going anymore and everything is flying all over the place... Experienced this first hand while working on a collaborative project. There's no encapsualtion and hierarchy anymore, and debugging becomes a total nightmare. Feel free to disagree with me... That's just my experience.
I don't like using more external libraries than I have to, because it's just a matter of time before a dependency becomes deprecated and you have to migrate and break your code. Consider the long term effects of using state management libraries, especially if they aren't well-established.
In fact it’s the opposite. It is easer to start without a state manager, with just react context. But it easier to work with a state manager (I use redux toolkit) later. So much easier, that I’m thinking of replacing existing parts of my app with react context to unify with other parts, and use only redux now.
I've had to do that (migrate to Redux) several times with complex apps that contain thousands of components. I think it's really foolish to think that RTK, Zustand etc. serve no purpose. It may be true for toy apps presented on youtube but if/when your app becomes increasingly dense performance can become a real problem (especially on mobile devices, customers with crappy PCs). Tools like Redux let you tackle these problems and provide features like undo/redo etc. It's unfortunate that Redux still gets a bad rap due "but boilerplate!" but it's actually quite elegant these days.
Some state management libraries are harder to implement then the project itself. If you have ever tried the earlier versions of redux , it was harder to learn then React itself. But I still find it suitable to do state management with much better tools like Recoil.
Tanstack Query and Zustand are all anyone needs if building a SPA. But always, the project requirements will dictate your decision on tools / technologies you need.
Yo said that you used url for that project at the end of the video so does it mean you also put Card Number input value to url ? Isnt it bad thing to do ?
I mean I don’t need redux for a small app, but at work we have a gigantic 50+ module app that would be absolute hell to work on without redux or something for state management.
I'm a junior developer and have been following your channel for a while now because your courses are so easy to understand. However, I was wondering if you could make videos about how to maintain and update a project when there are new packages and/or frameworks versions, and how to configure things like imports, Prettier, etc. We always see videos about coding, but I think configuration, infrastructure, and maintaining projects are also very important.
Yes, that would be cool
Also configuring a simple CI pipeline, Docker, automatic versioning, monorepo, etc...
Agree! Being a web developer now is not only about coding but also all those things you mentioned and I find it difficult to proceed as a junior
You’ll never get him to do this because frankly it’s a very difficult topic that is quite deep. And he goes very surface level on most topics on TH-cam. For example, something like Zustand is great. So this video is kind of moot
in a real job, you wont be updating to new framework versions unless mandatory by your company, most times you staying on a LTS for a minute
@@TheStickofWar i only use zustand it's easy it's very great and very easy to implement
This was an amazing video! Specifically, I liked you going through a short summary of the history where you explained problem -> solution, problem -> solution. I think it is infinitely more useful to understand why things are used/developed as opposed to the common 'this is industry standard, use this for x'
Thank you for not saying there is "state" in server components. It tripped up a lot of people.
PLS use more drawings like in this video. It makes it much easier to understand. Awesome channel
Yeah, I finally understand on big scale the props drilling issue.
Yes! And what tool are you using to make those drawings?
Excalidraw @@Leightym
@@Leightym That's Excalidraw
I have literally spent the last month removing impossibly intertwined and implicit state and putting it in the URL. This has allowed for deeplinks, bookmarking and easier to read code, test and re-use code.
I am of the opinion you most likely don't need state management in almost all work you do. Thanks for the vid!
server state with react query is my go to and always will be 🐐
@@deshi-sukuna indeed. The server is (almost always) the real state. We are here to make buttons ands
@@deshi-sukunawhen you say server you mean like next js server or like actual server API?
@@vickylance i mean actual server api 😃
@@deshi-sukuna ok cool
React Query (Tanstack Query) is also a good way to store requested data with the build in cache
Call it cache or whatever, it is still some "in-memory state".
Zustand is so good that you should not bother with reducer and context hooks other than to feel how painful it is to use them, so that you would be able to appreciate zustand even more.
Agreed just use it on Next Js. It makes everything easier.
For super complex web Apps I have been leaning for Redux for global state and localized hooks for fetching and very localized contexts for purely sharing props to avoid excessive prop drilling. This way you can avoid context hell and make it a rule to not make contexts dependent on each-other.
I learn state management this week and then this video pops up 😆
I avoid using state management libraries until I have an exact use case for one in the project. It's surprising how far you can get without having any need for one
you'll find that if you avoid state management libraries, you'll start creating better reusable components.
I basically use only RTK for the login reducer with persist to keep the user logged, and RTK query (so same package) for api fetch because it manages the cache and allows me to avoid too many requests to the backend. That's it.
Got a code example?
@@marvinkr you can get all the examples on RTK query docs.
Also RTKQ allows you to avoid using useEffect, cause it reloads automatically the widget on data change. Also you can launch multiple fetchs sequentially using "skip" option, so convenient!
The code gen for rtk query is really nice too. If you have accurate openapi specs for your back end (either because you define the openapi spec and also generate the backend, or you generate the openapi from your backend) then you can just run a command to have all of your data fetching and mutations created for you automatically.
What about the client side State management like e-commerce carts and themes
@@Osirisdigitalagency yeah you can do it with reducers as usual with RTK
Finally someoone who understands what I have always said. Nice video and great explanation. 90% of the time you do not need state management! keep your code clean and if you don't need some fancy library then don't use it. You are only "prop drilling'" if your only going way too deep into your components. Love you Web Dev. GREAT VIDEO!
Well the biggest reason to use state management libraries is one - they store the states separately from the app wrapper, so components are rerendered only when THEIR state changes.
Problem with useContext etc is that it is a wrapper around and if one single state changes, everything related to that wrapper will rerender too.
Which is a huge deal when ie. you have some table with plenty of inner components and data.
That means every single cell of that table, every single component (ie button in a row) will rerender just ie. because one state of one button in that table has changed…
No, please don't use Context with Reducer for state management. It is not optimal (re-rendering due to the lack of selectors), much boilerplait needed especially in TS. Jotai is much better option if you need to manage global client state.
This. I ran into a problem because of this like 2 years ago and it was painful to debig and fix. Context is good but shouldnt manage a global state, it is not the purpose of it
exactly what I experienced with useContext, every change in the context could make all the components inside being rerendered, horrible performance.
"Thanks for watching" No man, Thank you for sharing. ❤
Reasons why I like Vue
Vuex/Pina: One state management library that gets the job done
Less time worrying about state management and more time building
yeah! Agree with you🎉
When encounter complex business logic, you will be happier developing with Vue.
Kyle, thank you for the right info. I love your explanations. I just about to brush up state management in React. You gave the view of all the state panorama. I have still many things to learn. Really waiting for your next video with the project you mentioned.
I love how Svelte solves - very simple and intuitive and it's baked in the language.
What app is being used to draw/illustrate?
Maybe Excalidraw
For enterprise software, where complex state is a necessity, state managers are a blessing. I'm happy with RTK/RTK Query.
I've been a huge fan of what Preact Signals has done for React. I've been using that for state management on the client side. (And it's also really smooth for passing state around in Svelte).
This is what i want to try on my next project
Knockout had it right
not true. state managers are life savers. zustand made our project possible
I use it too, and would not live without it. :-)
For me is React Query
Wait till another state management tool comes out in 2 years and you're told to migrate to it.
fact, this video is just clickbait. He is just talking about simple project doesn't need zustand but the title is just so bad
As always the correct answer is "it depends"
React Context is a robust and easy-to-use solution for state management. In my experience, it has proven to be highly effective and free of issues. There is considerable debate regarding the use of URLs to store state. It's important to note that search parameters should be used specifically for conducting searches, not for general state storage.
While storing state in a database might make sense in some scenarios, it can be impractical for managing UI-related, client-side state. Frequent re-fetching of data from the server can introduce unnecessary complexity and friction. Instead, maintaining state on the client side often leads to a more seamless and efficient user experience.
react hook form, context and TanStack Query is all you need for your app
React routers url params too
You mean React Query ?
yup that's the one @@TienNguyen-og5eo
@@snake1625b for routers that basically goes by default if your not using next
@@TienNguyen-og5eo Yeah TanStack Query is called React Query back then. They just changed the name. They two are the same.
Great video. I tried to apply the new knowledge to my project but failed.
**Project structure:**
```
dashboard
dashboard\p1
dashboard\p2
dashboard\p3
```
All four pages work with the same data (a single supabase query) within authorized zone, but in a different way.
Currently, to navigate through these four pages, I make 4 identical database queries on every page and receive the same response 4 times because the query is executed at the SSR page level.
How can I do this properly?
Only read the title, not yet seen the video itself, but thought : "Thats why we're mainly using selfcoded stores written in plain Java/TypeScript living in the module scope of the application, keep it simple, keep it small".
Yes!!! This!
Excited for Next.js Ecommerce Project ❣
I haven't even watched your video yet and I 100% agree,
react standard library for state is brilliant,
I'll watch the rest of the video to be even more convinced tomorrow.
I think passing state down the tree is not the main problem a state management library solves. The really nasty side of react is dealing with a state that's an object, containing arrays of objects, etc. It becomes very difficult to correctly merge updates to this state to avoid unnecessary re-rendering, or to force re-rendering when needed. This is the most nasty and difficult part or react, which they didn't really solve to this day, and that's why all those libraries were invented and continue being invented - to deal with state updates.
State passing can be solved with the context, but state merging is still a big pain and Achilles' heel of the whole react universe. I was spending endless hours trying to figure out unexpected rendering issues every time (which you don't have direct control over as it's all react magic which is the worst part) until tried MobX and it finally all started working together just like I always expected without any weird unexpected side effects.
This is the things I've still strugle with.., sometimes 😄.. I want to use just an old vanilla javascript or jquery that what I had known for almost 20yrs alongs with php. Main purpose I learn react is it can be used for mobile app. ah.. maybe it just because my brain isn't fresh anymore 🤣🤣
True. This video did not mention the rerendering issue in Context API, which is a really big deal when working with a big app and every bit of performance is important.
The rendering issues mentioned above, will they be solved in React 19 with the help of the React 19 compiler?
Thanks!
You are very welcome!
What website are you using for the diagrams and stuff?
excalidraw I suppose
I have a question. Doesn't using url parameters as states reduces security
what is the drawing program hes using in the beginning?
Its called excalidraw for anyone wondering
i really cant wait to watch your upcoming video on this topic )) cuz its the exact thing that Im struggling with while working on my project
hello, won t that be a security bridge to have your states in your url regarding injections ?
React is designed to be flexible, and encourages the use of third-party libraries. So, why discourage us from using a packages like Zustand?
you didn't watch the video did you
@@Zukias We aren't unemployed like you
@@saarza9991 wtf are you talking about and why are you pretending to (incorrectly) know my employment status?
@@saarza9991I would love to work with someone like you who makes judgment before hearing the entire thing.
I was thinking the same and it's good that somebody with your experience say that.
Thank you! This is true. I started with React and chose not to add Redux until I was familair with what React offered first. That way If I decided to upgrade to Redux later I would know why and have a clear understanding of the differences. 3 years later and I have not had a clear case to add Redux yet. I have a middle tier Web API, and a back-end, so the frront-end is not handling everything. Thank you for the explanation.
Thanks for your share, what’s the app you are drawing?
Excalidraw
Plus to the question!!!!!!!!!!! Please share!! 🙏
here's my opinion on state management. you need 3 types of states. global client state, server state or async state, and scoped state (client state under a single branch of the app tree, basically only considered global for the children of the component where they are defined). I prefer Zustand, reaact query and context for them in order.
Agree but for the third I would add the following:
As long as the tree hierarchy in that "ui-branch" is not too deep and complex (and not expected to), try to use as much local state and other techniques like prop drilling as possible and only use context if necessary. This will "force" the devs early on to really think about seperation of concerns and clean architecture instead of putting everything in a semi-global state (making it better for testing and maintainability)
@@aliasalias510 it doesn't scale well. If it's 2 or 3 components deep it's fine but if you drill deeper it becomes a nightmare. I inherited a big project that has that issue. It forced me to think about context for components instead of for the app.
@@chawkichalladia1812 well thats exactly what i meant with "if its not to deep...". So i understand. Same here. Nothing to argue about
@@aliasalias510 not arguing just discussing
Thank you so much bro❤ Your guidence is helping me loot ❤
What is the name of the app you are using for drawing concepts?
Excalidraw
I used only contexts/reducers in my last few projects and it was a best decision I made. For more complex state I use two combined contexts - one for state, one for actions and it works perfect
Re rendering how would you avoid it?
Got any code examples?
Managing state client side is usually a bad idea. Great video I like this approach
I somewhat disagree. Though your project may begin as a simple app not needing global state management, it may grow in complexity and features pretty quickly, and useContext, useReducer will not scale. Why not start with a global state manager, though there may be a bit more setup and boilerplate code, it will scale and is pretty simple to implement.. Don't really understand the dis on redux. That lib with redux-saga allows to build large projects that once setup will just work. Lower maintenance, ease of testing need to be considered.
I like redux still
I think Redux has a bad rap due to the initial boilerplate it required. Modern Redux doesn't have that. Even the reducers you write are much simpler than the old days due to its use of the Immer lib. It's akin to saying React sucks because of the way it implements mixins (i.e. ancient history). When I started using RTK I was hesitant but it's been a great DX. I'm not sure I agree about redux-saga though (just use RTK Query)...
Great videos, very concise and to-the-point, thanks!
I agree that you shouldn't use a state manager until you need it, (same with every library, pattern, and so on). But they are still needed in the real world, code youtubers always make these absolute statements and all they do is very contrived examples.
This video is summary of actually my 1 year of experience and in that I learnt all this while working on company projects.
Hey Kyle, what tool are you using to draw all those diagrams you're using to explain?
So if a webapp has not to many states we can use nextjs but if it has to deal with to many states and state changing (interactions) we should use react?
Seems you think NextJS is a state manager. No! In React or any framework, if your state is not too complex, you can use useState to manage state. If you want, you could also use URL based state management. If a considerable amount of state is shared (global), then you should use a State Management library like Zustand or Jotai or Redux
10:57 If the things qualified as a webpage, not as a webapp, you dont need even react or nextjs, that's it. But I agree that a lot of usecases implemented as a specialized hooks/libs, you don't need to implement it from scratch on your favorite state manager.
I'm using Nextjs and i already figure it out that state was no longer needed in my application because i prefer using SSR and page be generated server side to gain performance which is a great thing but when you have client interaction to filters blog for example , i thought there were no other way to deal with states so thank you so much for the URL parameters tips , didn't think about that and i'm gonna apply this idea right away :)
These ideas are for small web apps. For a scalable management app or a eCommerce app you do need state manager and all that
@@Shyam_Mahanta you can still use json or cookie.
What kind of software does he use to visualize the state management
What's that whiteboard you're using?
Excalidraw
@@paulmouchel3641 Thanks a lot!
Thank you kyle....eagerly waiting for the project
Many websites need maintainers. As a good developer, it's important to understand state management. If you're a beginner, I highly recommend learning state management before you get lost in complex projects.
This follows what I believe as well, though I happen to be in that 1% that’s working on a complex state heavy web application.
I will say tools like Tanstack query and redux toolkit (in particular rtkquery) go a long way in reducing the need to worry about state (these libraries let you treat data from endpoints as external state so to speak).
Not usually used with nextjs but we aren’t using next
i have watched this video 3 times now. you're a good d00d k!!! thank you!
Provider consumers in react has been such a breath of fresh air from a life time of redux as my go to
hey man what software are u using for drawing this diagrams ?
excalidraw
I'd be curios to see how your demo app at the end of your video does with react dev tools showing rerenders?
If that results in lots of re-renders it could be a great video for you to walk through resolving those.
What tool are you using to draw these diagrams? It looks like something I need in my dev life STAT. 3:03
It's called excalidraw!
@@Upsided thanks!
Prop drilling is one problem. The other one is they should rename the "react developer" job position to a more appropriate one - "machine for spread operators". xD And since some state management libraries allow me to actually think of the solution and work properly with the data instead of using spread syntax all over the place I am very happy with them. Redux is not the chosen one ofc.
Id love to see you teach that url trick for state!
What tool are you using, to sketch the diagram?
Eraser
What is the name of this flow draw app ?? Name ??
Any reason we can’t just keep global state on the window object?
It will break the pattern of one way data flow and immutability of React. Therefore, putting state on global variables will make it hard to debug and causes unexpected behavior.
@@ngochunglongnguyen2526 thanks!
Looking forward for the nextjs video.
Redux + saga is still for me the best combination. You've got clear components without any async requests. You send only events, so much clear.
im a senior dev and i find redux-toolkit such as easy state management to use!
1:00 whats the app called? The blackboard
Looks like excalidraw
excalidraw
excalidraw
Excalidraw
excellidraw. just google it.
THIS is the video I've been looking for! Thank you so much for sharing the latest features in React that remove the need for state management libraries. I'm building a social media website (similar to twitter), based on your video this would be a good use case for state management libraries like Redux? Appreciate any feedback (btw just subscribed)🙏
Context causes rerenders of all wrapped children. It's recommended to use it only for things like user or theme that don't change frequently.
0:55 what is the name of the editor in which you draw your presentation?
It's Excalidraw.
@@damianszymczuk7796 thx
8:36 "and the nice thing about that is that now you have two different places you can deal with state" 😆😂
does anyone know which app he used for the drawings..thanks
excalidraw
excalidraw
What whiteboard tool are you using?
To sum up the comments:
- Unexperienced devs: Yaaay it is so simple, thank you!
- Experienced devs: Yeah no, state managers very much do have their right to exist and totally make sense at a larger scale.
Running in production on NextJS app router since February and now the only thing I use global state management for anymore is turning modals that are shared across components (a navbar and the page) on and off.
How do you move states to the server? I dont understand what you mean by that... Thanks for the video.
It's the source of state. That means stop mangling stuff in the react code
Remember, State management is an art. You'll learn by making mistakes! State updates cause re-renders, and therefore poor state management leads to several unnecessary re-renders which causes performance overheads. Zustand, Jotai, etc make state management and state updates much smarter - they only update those components which use the state that has changed. State management doesn't always mean bringing out the big guns in the form of Zustand, etc. Sometimes, a local state variable or a ref variable should be enough. It all boils down to YOUR understanding of the type of state management solution that is required for a given problem...
but what about rerenders... i am having this problem when i update state in any way, everything rerenders and probably in the end will slowdown my app. i have no idea how to do this and where to look for it
that's why i hate react
vue has a better development experience than react😂
So, it depends also on ur backend technology, correct?
mobx does the job for our project ideally
Every state management works
Almost two year ago we completely left out from all state managers like redux mobx so on and now just react context and react-query, it's enough to build any apps you would needed
As soon as I have a form I usually want mobx state management that 1. binds form elements to properties of objects and 2.updates the UI when the properties change from a load operation (for example). I wouldn't know how to do this differently without increasing the boilerplate.
Thank you!!! This helps a lot!
It depends on how complex your business logic and application is. I wouldn't dream of not having a store for what I work on. Legend-state is my recommendation as signals make computed/derived data trivial.
What tool are you using to make those drawings?
🤔🤔🤔
Cool! So React has finally figured out what PHP has been doing since the '90s. Great!
Guys, how to push some state to URL in next JS 14, because useRouter from next/router is deprecated, and the new useRouter does not have query 🤔
Bro, app router using next/navigation and pages router using next/router
Hot take...
Avoiding prop drilling comes down to component composition.... That's literally it.
If you need to pass state down two components, just lift the part of your component that needs the state to the parent and there is no longer a problem. Then render the children using {children} in your child component. (or by passing multiple props)
You just have to think a bit about your data flow and refactor on the fly if you need more deeply nested components.
I've been using react for a long time and I've never had an issue with prop drilling even with very complex state.
Also, signals are a complete stuff up in my opinion. You have no idea where data is going anymore and everything is flying all over the place... Experienced this first hand while working on a collaborative project. There's no encapsualtion and hierarchy anymore, and debugging becomes a total nightmare.
Feel free to disagree with me... That's just my experience.
I don't like using more external libraries than I have to, because it's just a matter of time before a dependency becomes deprecated and you have to migrate and break your code.
Consider the long term effects of using state management libraries, especially if they aren't well-established.
In fact it’s the opposite. It is easer to start without a state manager, with just react context. But it easier to work with a state manager (I use redux toolkit) later. So much easier, that I’m thinking of replacing existing parts of my app with react context to unify with other parts, and use only redux now.
I've had to do that (migrate to Redux) several times with complex apps that contain thousands of components. I think it's really foolish to think that RTK, Zustand etc. serve no purpose. It may be true for toy apps presented on youtube but if/when your app becomes increasingly dense performance can become a real problem (especially on mobile devices, customers with crappy PCs). Tools like Redux let you tackle these problems and provide features like undo/redo etc. It's unfortunate that Redux still gets a bad rap due "but boilerplate!" but it's actually quite elegant these days.
Really looking forward to that tutorial!
Some state management libraries are harder to implement then the project itself. If you have ever tried the earlier versions of redux , it was harder to learn then React itself. But I still find it suitable to do state management with much better tools like Recoil.
Guys, what is this whiteboard tool that he used to draw diagrams?
excalidraw
thanks@@_KITISH
To be honest I feel like we are moving back to PHP world 😢
Tanstack Query and Zustand are all anyone needs if building a SPA. But always, the project requirements will dictate your decision on tools / technologies you need.
Yo said that you used url for that project at the end of the video so does it mean you also put Card Number input value to url ? Isnt it bad thing to do ?
yeah we cant put sensitive data in URL. It destroys its glorious purpose😅
Hi love to start problems huh
Thank you for the insight, it's was really helpful.
I mean I don’t need redux for a small app, but at work we have a gigantic 50+ module app that would be absolute hell to work on without redux or something for state management.