State Managers Are Making Your Code Worse In React

One of the first things most people do when creating a new React application is install a state management library. This is something that used to be necessary to create a React application, but with the improvements to React and the tooling around React state managers are really not needed for most applications.
📚 Materials/References:
Next.js Ecommerce Project Video: Coming Soon
🌎 Find Me Here:
My Blog: blog.webdevsimplified.com
My Courses: courses.webdevsimplified.com
Patreon: / webdevsimplified
Twitter: / devsimplified
Discord: / discord
GitHub: github.com/WebDevSimplified
CodePen: codepen.io/WebDevSimplified
⏱️ Timestamps:
00:00 - Introduction
00:58 - Prop Drilling
02:42 - Global State
04:28 - Context
06:38 - Reducers
07:37 - State Reconciliation
08:25 - Meta Frameworks
10:02 - URL State Management
10:57 - When To Use State Management Libraries
12:36 - Example App
#ReactJS #WDS #StateManagement

[@kmellia]

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.

[@miervaldis42]

Yes, that would be cool Also configuring a simple CI pipeline, Docker, automatic versioning, monorepo, etc...

[@spongebob93lover]

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

[@ElatedBlue]

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'

[@adtc]

Thank you for not saying there is "state" in server components. It tripped up a lot of people.

[@bama2619]

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.

[@ParaZumir]

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

[@TienNguyen-og5eo]

Yeah, I finally understand on big scale the props drilling issue.

[@Yoband706]

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!

[@deshi-sukuna]

server state with react query is my go to and always will be 🐐

[@Yoband706]

@@deshi-sukuna indeed. The server is (almost always) the real state. We are here to make buttons ands

[@vickylance]

​@@deshi-sukunawhen you say server you mean like next js server or like actual server API?

[@deshi-sukuna]

@@vickylance i mean actual server api 😃

[@vickylance]

@@deshi-sukuna ok cool

[@mountakhabi]

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

[@JesseSlomowitz]

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

[@dereksniper]

This is what i want to try on my next project

[@BboyKeny]

Knockout had it right

[@adriankateliev731]

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.

[@tom.watkins]

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

[@Stevexupen]

you'll find that if you avoid state management libraries, you'll start creating better reusable components.

[@StefanoV827]

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]

Got a code example?

[@StefanoV827]

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

[@buzz1ebee]

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.

[@Osirisdigitalagency]

What about the client side State management like e-commerce carts and themes

[@StefanoV827]

@@Osirisdigitalagency yeah you can do it with reducers as usual with RTK

[@osaka-ben9291]

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

[@Shyam_Mahanta]

These ideas are for small web apps. For a scalable management app or a eCommerce app you do need state manager and all that

[@hollycow8171]

​@@Shyam_Mahanta you can still use json or cookie.

[@cauliflow3r1337]

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

[@faroukbello164]

Thank you for the insight, it's was really helpful.

[@thedelanyo]

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

[@anushasurakala5975]

Thank you kyle....eagerly waiting for the project

[@SilonSilon]

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

[@Shyam_Mahanta]

Re rendering how would you avoid it?

[@chinmayghule8272]

Got any code examples?

[@chawkichalladia1812]

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.

[@aliasalias510]

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)

[@chawkichalladia1812]

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

[@aliasalias510]

@@chawkichalladia1812 well thats exactly what i meant with "if its not to deep...". So i understand. Same here. Nothing to argue about

[@chawkichalladia1812]

@@aliasalias510 not arguing just discussing

[@kirillvoloshin2065]

mobx does the job for our project ideally

[@alejandroangongandara678]

"Thanks for watching" No man, Thank you for sharing. ❤

[@YakovL]

Great videos, very concise and to-the-point, thanks!

[@paccioti]

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

[@snake1625b]

React routers url params too

[@TienNguyen-og5eo]

You mean React Query ?

[@paccioti]

yup that's the one @@TienNguyen-og5eo

[@paccioti]

@@snake1625b for routers that basically goes by default if your not using next

[@stevinjack5062]

@@TienNguyen-og5eo Yeah TanStack Query is called React Query back then. They just changed the name. They two are the same.

[@maryamahmedseager142]

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

[@marcteufel8348]

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

[@jordanfarr3157]

Yes!!! This!

[@serg472]

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.

[@Fanaro]

Really looking forward to that tutorial!

[@harshrathod50]

This video is summary of actually my 1 year of experience and in that I learnt all this while working on company projects.

[@talleyrand9530]

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

[@Franck_Polla]

Thank you bro you are a savior 😊

[@snake1625b]

In my company's legacy app we would make queries with Apollo and then stick the entire response in zustand. It was only later we realized that Apollo has it's own cache that behaves like the store. In our rewrite it was our policy to not stick everything in the store

[@digitaldevigner4080]

This also helps for deep links and smart links that are url based. If you want to pass a user from a web app to a mobile app you have to do via url.

[@riya6549]

I learn state management this week and then this video pops up 😆

[@adamzalesak]

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.

[@mineturtle1841]

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

[@akashthoriya]

Excited for Next.js Ecommerce Project ❣

[@liban7032]

What website are you using for the diagrams and stuff?

[@Grenade034]

excalidraw I suppose

[@waleedsharif618]

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 ?

[@vigneshwarrv7136]

yeah we cant put sensitive data in URL. It destroys its glorious purpose😅

[@BrianThorne]

Hi love to start problems huh

[@sylum4277]

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.

[@elvisjackson808]

What's that whiteboard you're using?

[@paulmouchel3641]

Excalidraw

[@v.reagan]

@@paulmouchel3641 Thanks a lot!

[@user-hw1bc5nq4m]

Thanks for your share, what’s the app you are drawing?

[@georginreji1945]

Excalidraw

[@oerbyy]

Plus to the question!!!!!!!!!!! Please share!! 🙏

[@RUFeelin]

What app is being used to draw/illustrate?

[@bezimienny5149]

Maybe Excalidraw

[@azulay7]

What tool are you using, to sketch the diagram?

[@egorovsa]

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

[@abderrahmanebenchalel541]

I think it depends on the project requirements, so some times we need client state more, some times we need server state more.

[@tombrauey]

Absolutely - especially if you only can use client libraries, because your code is executed in context of a bigger application. In my instance, I develop line of business apps on top of SharePoint and there is no easy way to include a server part to the application, because everything runs on the client.

[@BGBaDBlo0D]

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.

[@helleye311]

The only things I use state managers for nowadays is auth (if I'm doing it myself, it's much easier to just stick tokens in zustand) and sometimes specific interactions for deeply nested components. Everything else I either do server components for low-interactivity apps, or hook-form + react query + plain old useState for high interactivity. State libraries have their place, but that place is actual global data and not form input or data from an api. I'm very glad we're moving away from redux in the industry.

[@AykutKlc]

Looking forward for the nextjs video.

[@TannerBarcelos]

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.

[@igots]

I'd be curios to see how your demo app at the end of your video does with react dev tools showing rerenders?

[@igots]

If that results in lots of re-renders it could be a great video for you to walk through resolving those.

[@tj-softwaresolution]

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?

[@nemeziz_prime]

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

[@AmirLatypov]

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.

[@dawidm9768]

What is the name of the app you are using for drawing concepts?

[@v.reagan]

Excalidraw

[@tuananhdo1870]

True. Aftet many years of rract I found that props drilling is kind of nice

[@munna5553]

Please make video on redux complete i have lots of confusion

[@halfalligator6518]

I'm still yet to figure out why the native Context can't do most of it. With the benefit of being able to tailor it to the patterns and structure of your app. If i need to automate huge areas of an app or project, i'd build my own schema system to generate objects, so why not have my own custom state manager to go along with it? Context is really not complicated. It's just one single step/layer beyond setting up regular component states. I feel sometimes we're so obsessed with standardizing and making things "efficient", then it bloats, backfires and gets less efficient. Even if it it helps a little bit... I still have to consider that having extra knowledge needed in my brain and extra packages still "costs" in other ways. Depending on the project, there can be a long term efficiency when working with vanilla stacks. I'm not a denialist though as I'm so happy with some basic packages. Have to pick your battles!

[@EricSundquistKC]

8:36 "and the nice thing about that is that now you have two different places you can deal with state" 😆😂

[@VortexMaster98]

what is the drawing program hes using in the beginning?

[@VortexMaster98]

Its called excalidraw for anyone wondering

[@cameronosborne7405]

Jotai is extremely helpful especially when you start making derived states based on other observables.

[@jNayden]

hey man what software are u using for drawing this diagrams ?

[@Grenade034]

excalidraw

[@offlercrocgod]

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.

[@goncaloshred]

How do you move states to the server? I dont understand what you mean by that... Thanks for the video.

[@BrianThorne]

It's the source of state. That means stop mangling stuff in the react code

[@antonvoltchok7794]

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.

[@EvertJunior]

react context is beautiful once you understand it properly and it forces you to improve your composability skills

[@hamedb299]

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 🤔

[@kylerjohnson988]

What tool are you using to draw these diagrams? It looks like something I need in my dev life STAT. 3:03

[@Upsided]

It's called excalidraw!

[@kylerjohnson988]

@@Upsided thanks!

[@fooked1]

I wonder how this advice impacts performance. With client state, I can make a single DB call and maintain that state across routes and other transitions. If instead I use the stateless web paradigm, I would need to make a DB call each time a route changes, even if the state doesn't need to change. And some state is too big to live in the URL. Likewise, cluttering the URL might impact some tracking services like Google Tag Manger, Optimizely, etc (don't quote me on that one though).

[@claystation6360]

All we need for our enterprise app is jotai. Screw redux type libraries. Screw nesting context providers. Derivative atoms are so clutch

[@igors.2943]

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.

[@user-hk8xm6jy5t]

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.

[@markeem321]

So, it depends also on ur backend technology, correct?

[@StevenDavisPhoto]

i use react sweet state for a few global state things i need. it's way smaller and super simple to use. easier than context.

[@nottoonior]

does anyone know which app he used for the drawings..thanks

[@edrbt]

excalidraw

[@abots]

Please do a video on tanstack router

[@darrenhwang900]

Odd, but it would seem that for anyone to realize that URL can help with state management should be much earlier, and should have happen right after "Global state"(or Lifting State). You don't need your thinking/evolution to go through context stage, reducer stage, reconcilliation stage, meta framework etc. In other words, you don't need next.js to take advantage of URL query parameter.

[@VidoviDroga]

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

[@Su-xs1yr]

that's why i hate react vue has a better development experience than react😂

[@nemeziz_prime]

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

[@aryomuhammad8254]

I like this new style, using drawings on the screen really helped me to understand. Thank you Kyle!

[@Tommy-jn9ps]

1:00 whats the app called? The blackboard

[@gmlongo1]

Looks like excalidraw

[@Prof.Respect]

excalidraw

[@adamkniec9333]

excalidraw

[@srijonp4]

Excalidraw

[@prasanthpedaprolu2261]

excellidraw. just google it.

[@grimmdanny]

"use-between" makes it so you don't need a state manager for global states. It allows you to use custom hooks with useState globally, and you're done.

[@zb2747]

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

[@Su-xs1yr]

yeah! Agree with you🎉 When encounter complex business logic, you will be happier developing with Vue.

[@dolapoajayi2156]

Good insight

[@samislam2746]

We thought they're necessary because we were mixing async fetch operations with local state management solutions

[@TheFocusedCoder]

Managing state client side is usually a bad idea. Great video I like this approach

[@investkalimot7499]

react query with context api is enough to build a huge application.

[@Dhdnrjrbrjrnrkfjwk]

In such simple examples you can avoid using even react, not only state managers. The question is how much time will it take to debug and test everything. To avoid boilerplate there are different solutions e.g. redux tool kit (RTK). I doubt if it is easy to debug complex state changes using useReducer/state + context API when with redux devtool + redux extension in browser I can see every step of updating my state

[@Mari_Selalu_Berbuat_Kebaikan]

Let's always do alot of good 🔥

[@jacobphillips9235]

Thanks!

[@WebDevSimplified]

Thank you for the support!

[@othersidesss1]

Waiting for Ecommerce Project Video

[@awaisraza2285]

True. People use unnecessary tooling while the same functionality you achieve without using 3rd party libraries.

[@jigmelodey4632]

To be honest I feel like we are moving back to PHP world 😢

[@fabiovictorino350]

I like the ideia of using more Hoock

[@ernestwarhead4144]

Next tutorial should be about the brand of shampoo that you use lol

[@codewithved]

Amazing video

[@DannyGlobal]

That's why I use Svelte/Kit.

[@fischi9129]

Idk, on one side, URL state is extremely underused and should be used more, on the other side I really don't like the react Context api, I think zustand is easier, faster to implement and generally just more comfortable to use, so when I would actually need context, I just use zustand. Takes me less time to implement, and it's not really complex

[@jenstornell]

In Vue we have Pinia. That is all that we need, if any.

[@amkamn1886]

Pinia better than vuex ?

[@canardeur8390]

​@@amkamn1886 Pinia is the new Vue officially supported store library. Vuex is now deprecated.

[@jenstornell]

@@amkamn1886 Yes, much better. VueX was good but grew into a bloated monster. They started over and made Pinia. It's tiny but still better and more simple. VueX is for Vue2 mainly. Pinia is for Vue3. Pinia is also recommended as the new default go to state manager.

[@thesynalice]

​@@amkamn1886, yes. Pinia is preferred for new projects.

[@andrewwall2730]

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.

[@Cognitoman]

I like redux still

[@netssrmrz]

If the problem is prop drilling then we'd have to blame Reacts, very limiting, hierarchical architecture. Real DOM components are not restricted to only interacting with parent or sibling components. Additionally, I don't feel incurring the additional SSR cost of splitting UI onto another server is acceptable. Even my "simple" sites consist of a client site, a back-office site, and scheduled tasks all of which use a common HTTP API. Do I want to incur the extra effort and dollars of more servers, and UI code tied to a specific framework AND project? No chance!

[@vigneshwarrv7136]

You have my respect brother. I am confused why people are not even talking about the reasons that made us to shift from server side to client side in the first place.

[@netssrmrz]

@@vigneshwarrv7136 Yes that's a really good point. I've often thought this would be a great topic for a video... "Why is this round of SSR better than the last?"

[@StephanHoyer]

I just read "Stop using react", unfortunately I missread. 🤷‍♀

[@hineko_]

I think that literally anything is better for state management than the built in react tools

[@dereksniper]

What about using signals?