State Managers Are Making Your Code Worse In React

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.

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.

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.

React Query (Tanstack Query) is also a good way to store requested data with the build in cache

PLS use more drawings like in this video. It makes it much easier to understand. Awesome channel

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.

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 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!

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).

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.

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 :)

react hook form, context and TanStack Query is all you need for your app

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

What do you think of cookies to manage states in server components?

I love how Svelte solves - very simple and intuitive and it's baked in the language.

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.

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

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?

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.