That's great to hear! Prop drilling can definitely be a nightmare lol, it's so easy to lose track of things once your app gets the slightest bit complex
Jotai is same creator/maintainer (dai-shi) as zustand which you mention. He has writeups that help explain which library to use depending on requirements.
Nano store is awesome as well.. it's small reactive and works with react, solid ,native js or any famous framework. Great fit for. Small to medium size projects. If you use nano store with Astrojs the store you can be shared between frameworks.. you can make a change in solid component and react component will re-render if needed
Thanks for enlighting me about this awesome library. It was a great video. I would want more indepth video about jotai with complex state like non-primitives and other feature provided by Jotai with real world example. Also if possible would you please share Jotai optimized version so that there is no un-necessary re-render like Jotai's focusAtom or selectAtom.
great video! I like that you get to the point! I tried to like zustand but it felt weird and cumbersome however jotai seems like a way better fit for me!
This is wicked, somehow very similar to zustand but yet seems even simpler indeed. Would be nice to see how types work on typescript and how more complex state works too, for instance if you have several variables and a few set/get functions like the usual zustand drill.
I would argue that putting state in the url (via search params) is my perferred way. That means you can mount your components everywhere and they will be context aware by default.
That's a great point! I haven't used Zustand a ton yet (still testing it out) but in my opinion Zustand would likely be a better choice if your app is highly complex. Not quite as cut and dry as Jotai, but it has the capability to do more. After all both Jotai and Zustand are made by the same person, for that exact reason
That's a great question. React does technically have support for global state, using contexts. You can wrap your app (or subtree of the app) in a context provider, and then React components within that subtree can access the state. The problem is, if you state gets a bit more complicated or needs to not be so rigid, contexts are not always the best solution. You end up having to wrap your App with multiple, sometimes dozens (yes I've actually seen this) of context providers, and it can get really messy and hard to track. The reason for libraries like Jotai, Zustand, Redux, etc, popping up is to try and offer a better and more flexible way to manage global state. It's a bit unfortunate that so many libraries exist because it complicates things. It's also worth mentioning that React is a library while Svelte is a framework. React is great at doing what React does, but it stays pretty unopinionated about things like global state management and routing, whereas vanilla Svelte is a bit wider than vanilla React. I think both cases are good in their own way, part of what makes React good is that since it stays unopinionated, it meshes well with almost any library and is super flexible!
@@AustinDavisTech "part of what makes React good is that since it stays unopinionated, it meshes well with almost any library" is that really true though? with svelte, I can use vanilla js libraries directly without having to write wrappers. and svelte isn't built on a vdom, so i can access the dom directly
@@anxpara Whether it is true or not, it depends on the person. I personally like having multiple choices on what technology stack I want to use for development. For example in many frameworks everything you need to develop an app is pretty much included. In React you might have to decide between Tanstack Query vs RTK Query vs SWR, for remote state, and what it is good for is that imo it pushes the industry forward with people always trying an improving on certain libraries. Like when context and redux were pretty much the only tools used for state management, pretty much everyone agreed that to manage state in react was a pain in the ass, specially classic redux. Now you have many options to choose from. Its true its hard to keep up with all of them, but I personally just find it better than just using a framework. But I feel like it is personal preference at the end of the day. Many people like full fledged frameworks a lot more. Pros and Cons to both
Big agree! They both provide a ton of value, and you could actually use them together if you wanted to. In Jotai's docs there's a guide on how to hook it up with Zustand
@@viktor_zhurbin but these libraries were created by a single person and he is called Daishi Kato. He even created a third library called Valtio. So Zustand, Jotai and Valtio were all created by the same person. All are state management libraries, but built on different principles.
@@viktor_zhurbin yes its a collection of maintainers but look at the commit history it was still created by dai-shi and is still maintained by him. have you considered that this developer could also be a member of this collective?
Jotai seems really easy to use, with absolutely no boilerplate. But i do not think it will scale well in more complex applications. Zustand will be a better fit in that case. Great video BTW
@@darthvader4899 My previous comment was based solely on what was shown in the video (this was my first time seeing the library). So, thinking of integrating it with some complex apps I've worked with, scalability seemed problematic. But going through its docs, my opinion of Jotai has changed. I believe its atom-based architecture allows for an application to be highly modular, consequently improving its scalability.
I agree, a while back I cross shopped jotai v zustand v redux toolkit and of the 3 zustand seemed to be the most flexible. Zustand can be nearly as atomic as jotai, but then built out to be as complex as redux. Zustand has the concept of a store, which helps organize global state into an obvious spot. I was concerned with jotai not having an organizing principle. For truly app wide global state, we use react context. That handles things such as app theme, app authority etc. Other than that, we don't have a need for truly app wide global state. We use zustand for global module/feature level state. Zustand allows module state to be as simple, or complex as that feature requires.
I get your point, and I think a lot of people would probably agree with you about Zustand. However I do think you may be underestimating Jotai a bit, as I have seen it scale very well so long as it's handled responsibly. Two solutions that are created by the same person and great in their own ways!
@@BoonBoonitube Im not really sure but imho better to use zustand for app wide state because of not requiring context provider, thus it will only trigger re-render on component that use that specific state. afaik the cons of using context is that triggers rerender to the providers children
It's global state by default unless you scope it then it only exists within its own scope (similar to how regular variables are scoped). Vanilla Jotai doesn't have thunk functionality like Redux, but that's also part of the beauty as to how simple it is
React devs have forgotten the best state management library of them all, the U R L. I love this library, however I only use it in cases where I don't want to expose state to the user like setting a navbar's sticky state. Everything else goes into the URL bar in our projects.
I do think storing state in the URL is something people completely forget about and don't utilize as much as they could. However, some might say that even with a routing library, the URL still exists outside of the React ecosystem/lifecycle since it's part of the browser, making it less pure React, as opposed to something like Jotai that is 100% tied to the React DOM. This definitely can have upsides though depending how you look at it. Ultimately I think it is best to choose what works best for you :)
Jotai seems very easy to use, with not much of a setup. But having a bunch of global states worries me for the performance. Personally, I like useImmer and useImmerReducer. I don't mind setting up the reducer function once, and Immer helps with the immutability problem that native reducer had.
This really looks fantastic! But... 1. Maintenance may end up becoming a nightmare in large scale production apps - especially in companies where PR reviews are not done "properly". 😉 2. I am curious what the performance is like in medium and large scale apps. 🤔 Thank you making this video though. Best thing I learnt today!
I've been actually working with jotai for quite sometime now, and yeah number 1 is a really valid point i didn't benchmark it with other state management solutions but it seems like it's working fine
That's a great point! Because it's so simple it certainly could be easy to abuse on apps that are super large or complex. My company uses Jotai however and we've never had an issue with it to my knowledge. But to your point, I think something like Zustand is a valid use case when this concern pops up! In terms of performance I have not officially benchmarked it or seen official benchmarks versus other solutions/libraries, however I can say in my experience with both medium scale apps (my personal projects) and large scale apps (my companies codebase) it's been just as fast as normal React state or contexts!
Ive sucessfuly migrated to jotai, an app which has big amount of data (air traffic over US) which is updated with few seconds interval. With jotai, its generalny easier to avoid rerenders, than eg. using redux. In terms of jotai performance overhead - its marginal, I recommend having a look at their codebase. The not so great part is that you need to get used to different data model, and atoms itself have some uncomfortable (for me) quirks. Theres some complexity while dealing with promises, or synchronizing state from outside source. 😊
@@AustinDavisTech I'll try to find a way to measure the performance of these state management solutions. Not sure how to begin, but I'm sure I'll enjoy the process of learning new things. 🙂
Btw, even though I have been working on React projects for many years now, I feel like I know very little. Videos such as this one will definitely be the push that I need to get good. 😛
It's always been incredibly fast for me! It should be comparable in speed to useState/React contexts so long as you're not initializing atoms INSIDE React components and not causing unnecessary state changes & re-renders
Zustand seems really powerful, and I'll probably be making a video here on it soon once I get more experience with it. But if you want an extremely simple, out-of-the-box solution then Jotai is your guy :)
I don't know the official benchmarks of Jotai, but I will say my company uses it pretty extensively on a large application, and performance has never been an issue. Expect it to run at the same speed as normal React state + contexts
State managers based on atoms are good only on examples or when they are simple. But having many atoms, on medium or large projects, can make the state management code realy messy. Especially when you read code after a few months xD
an problem with Valtio is it's not very suited to store complex objects (e.g a MediaStream) because it uses Proxies, whereas Zustand and Nanostores doesn't have issues with them
Congrats. You now made your app infinitely harder to test and debug. Global State is a problem. In fact, it was such a big problem a whole programming paradigm was created to address it.
I strongly disagree. Jotai is not a replacement for using normal React state. As long as you're not spamming atoms everywhere and you're using global state responsibly, it is 100% a better alternative than dodging global state entirely and prop drilling to infinity and beyond. There's a reason React itself supports global state with contexts and so many global state libraries have popped up. Web dev can get really complex, and without some sort of state management like Jotai, Zustand, or even contexts it becomes an absolute nightmare to navigate
@AustinDavisTech Contexts are semantically identical to Jotai. The fundamental problem here is that it is unregulated and not isolated. If a component changes state somewhere you can't know what it is without traceability like Redux offers with reducers. Moreover, since you have global state you have to recreate the entire DOM to test one compoment. No matter how you spin this, it is unregulated Global state which is an Anti-Pattern. I realize wish Front End influencers would study software Engineering Principles instead of hyping up Anti-Patterns.
Okay now you're just making stuff up 😂. Just because atoms effectively function as a global useState with context does not mean the entire app is a dependency of every single atom and the entire DOM re-renders for every single atom. If you make for instance ten layers of nested components and use an atom for layers 3 and 7, rather than prop drilling, the entire app (layers 0-10) does not all re-render. This claim is objectively false. Components only become dependencies of an atom if they subscribe to it, exactly how contexts work. Please go and test for yourself and you'll see exactly what I mean. I'm not sure where you got this information from? The only correct statement in here is that it is not isolated, which is the whole point. Complete isolation in a React app is not possible if you're building anything harder than a to-do list. Even if you're prop drilling, you're still making components become dependent on one another. Jotai, along with many other state management libraries, simply offers a better way to do it. Again, there's a reason why these libraries exist and React itself has built-in support for state sharing. Frontend developers aren't dumb or bad for doing this, in fact the most functional React apps are almost ALL going to have some sort of state management system in place. Just like literally everything else in programming, global state can be bad if it's abused. Memory management in C can be abused, but it'd be ridiculous for me to claim that nobody should touch memory in C because it's dangerous. I understand where you're coming from but some of your claims are objectively false, and applying a blanket statement like "global = bad" doesn't address the genuine need for state management systems in React apps.
@AustinDavisTech Look the problem is simple. Let me simplify so you can understand. 1. It is unregulated global state 2. It is not isolated So no matter what argument you have, it fails this fundamental test. Why is it unregulated? -> No one knows what updated what Why is unregulation bad? -> Because you cant debug it easily Why is it not isolated? -> Because it introduces non local coupling. Your components are not a function if the props but of some hidden state elsewhere. Why is lack of isolation bad? -> It makes things harder to test and harder to reason about. Instead of being able to think about it in isolation, you have to consider the whole app. How do you do isolation and global state management? -> You explicitly pass your dependencies as props in 1 direction. Never do 2 way prop-drilling. For example, you have your state in your store, you pass the selectors used by the component explicitly down. But we can directly access the store with a hook, it is more complicated to pass down props explicitly. Why do you advocate that? -> Sure, we can shoot ourselves in the foot if we want, but it doesnt mean it is good to do so. The reason we pass the selected state from the store explicitly is so we can achieve isolation and so we become agnostic to the state provider. If we access it directly, we make a coupling to that specific store. In other words we make an implicit dependency and so to test the component we need to now mock the whole redux store instead of just passing in props. It is literally the bananna and jungle problem. ==> Therefore we should avoid unregulated global state like in context api or jotai. It leads to well known anti-patterns and is anti-thetical to good software engineering practices.
Not knocking signals at all but this is a gross oversimplification. Jotai is not bloated in the slightest AND is more "react-y" than signals are. Signals are cool and may have their place, but this kind of comparison doesn't do it justice
![Blox Fruits Dragon Rework Update [Full Stream]](http://i.ytimg.com/vi/EqDAp8udhm0/mqdefault.jpg)
Much better than props drilling, love it. That's what I expected React.Context to actually work like, nice
This is awesome. It makes me want to remove my context providers. Great video, subscribed!
Great video, great library! Thanks for the tip! This makes things really easier
Wow! I’ve always hated handling state in react. I always used prop drilling, but this makes me want to get back into coding again! Great video!!
props is react with hard labour
That's great to hear! Prop drilling can definitely be a nightmare lol, it's so easy to lose track of things once your app gets the slightest bit complex
Jotai is same creator/maintainer (dai-shi) as zustand which you mention. He has writeups that help explain which library to use depending on requirements.
Nano store is awesome as well.. it's small reactive and works with react, solid ,native js or any famous framework.
Great fit for. Small to medium size projects.
If you use nano store with Astrojs the store you can be shared between frameworks.. you can make a change in solid component and react component will re-render if needed
I'll have to check this out!
I can vouch for nano stores, super cool and really small weighing in at 286 bytes 😂
Thanks for enlighting me about this awesome library. It was a great video. I would want more indepth video about jotai with complex state like non-primitives and other feature provided by Jotai with real world example.
Also if possible would you please share Jotai optimized version so that there is no un-necessary re-render like Jotai's focusAtom or selectAtom.
great video! I like that you get to the point! I tried to like zustand but it felt weird and cumbersome however jotai seems like a way better fit for me!
For sure! Unless your project is super complex, I think simpler is generally better :)
Thank you very much..... You explained very well 👍👍
This is wicked, somehow very similar to zustand but yet seems even simpler indeed.
Would be nice to see how types work on typescript and how more complex state works too, for instance if you have several variables and a few set/get functions like the usual zustand drill.
made by the same guys lol
THIS CHANGES EVERYTHING! 🙃
I would argue that putting state in the url (via search params) is my perferred way. That means you can mount your components everywhere and they will be context aware by default.
what about zustand it feels like it works like jotai would but the setter and state is dynamic and we can add extra methods using zustand
That's a great point! I haven't used Zustand a ton yet (still testing it out) but in my opinion Zustand would likely be a better choice if your app is highly complex. Not quite as cut and dry as Jotai, but it has the capability to do more. After all both Jotai and Zustand are made by the same person, for that exact reason
Why does react need n +1 state management libraries when svelte has built-in state management?
That's a great question. React does technically have support for global state, using contexts. You can wrap your app (or subtree of the app) in a context provider, and then React components within that subtree can access the state. The problem is, if you state gets a bit more complicated or needs to not be so rigid, contexts are not always the best solution. You end up having to wrap your App with multiple, sometimes dozens (yes I've actually seen this) of context providers, and it can get really messy and hard to track. The reason for libraries like Jotai, Zustand, Redux, etc, popping up is to try and offer a better and more flexible way to manage global state.
It's a bit unfortunate that so many libraries exist because it complicates things. It's also worth mentioning that React is a library while Svelte is a framework. React is great at doing what React does, but it stays pretty unopinionated about things like global state management and routing, whereas vanilla Svelte is a bit wider than vanilla React. I think both cases are good in their own way, part of what makes React good is that since it stays unopinionated, it meshes well with almost any library and is super flexible!
@@AustinDavisTech "part of what makes React good is that since it stays unopinionated, it meshes well with almost any library"
is that really true though? with svelte, I can use vanilla js libraries directly without having to write wrappers. and svelte isn't built on a vdom, so i can access the dom directly
@@anxpara Whether it is true or not, it depends on the person. I personally like having multiple choices on what technology stack I want to use for development. For example in many frameworks everything you need to develop an app is pretty much included. In React you might have to decide between Tanstack Query vs RTK Query vs SWR, for remote state, and what it is good for is that imo it pushes the industry forward with people always trying an improving on certain libraries. Like when context and redux were pretty much the only tools used for state management, pretty much everyone agreed that to manage state in react was a pain in the ass, specially classic redux. Now you have many options to choose from. Its true its hard to keep up with all of them, but I personally just find it better than just using a framework. But I feel like it is personal preference at the end of the day. Many people like full fledged frameworks a lot more. Pros and Cons to both
zustand and zotai developed by the same person so both have place
Poimandres is a dev collective, not a person
Big agree! They both provide a ton of value, and you could actually use them together if you wanted to. In Jotai's docs there's a guide on how to hook it up with Zustand
@@viktor_zhurbin but these libraries were created by a single person and he is called Daishi Kato. He even created a third library called Valtio. So Zustand, Jotai and Valtio were all created by the same person. All are state management libraries, but built on different principles.
@@viktor_zhurbin Daishi Koto made both...
@@viktor_zhurbin yes its a collection of maintainers but look at the commit history it was still created by dai-shi and is still maintained by him. have you considered that this developer could also be a member of this collective?
So if you want to use the global state you need to always import the original atom() to the component
Can you show us your code? I wanna learn it more detail especially the code inside component
Jotai seems really easy to use, with absolutely no boilerplate. But i do not think it will scale well in more complex applications. Zustand will be a better fit in that case.
Great video BTW
why? why would zustand scale not jotai?
@@darthvader4899 My previous comment was based solely on what was shown in the video (this was my first time seeing the library). So, thinking of integrating it with some complex apps I've worked with, scalability seemed problematic.
But going through its docs, my opinion of Jotai has changed. I believe its atom-based architecture allows for an application to be highly modular, consequently improving its scalability.
I agree, a while back I cross shopped jotai v zustand v redux toolkit and of the 3 zustand seemed to be the most flexible. Zustand can be nearly as atomic as jotai, but then built out to be as complex as redux. Zustand has the concept of a store, which helps organize global state into an obvious spot. I was concerned with jotai not having an organizing principle.
For truly app wide global state, we use react context. That handles things such as app theme, app authority etc. Other than that, we don't have a need for truly app wide global state. We use zustand for global module/feature level state. Zustand allows module state to be as simple, or complex as that feature requires.
I get your point, and I think a lot of people would probably agree with you about Zustand. However I do think you may be underestimating Jotai a bit, as I have seen it scale very well so long as it's handled responsibly. Two solutions that are created by the same person and great in their own ways!
@@BoonBoonitube Im not really sure but imho better to use zustand for app wide state because of not requiring context provider, thus it will only trigger re-render on component that use that specific state.
afaik the cons of using context is that triggers rerender to the providers children
jotai is the best
So it's just global state? Does it have anything similar to Thunk in Redux? Even if it does not, I can see where Jotai will be useful.
It's global state by default unless you scope it then it only exists within its own scope (similar to how regular variables are scoped). Vanilla Jotai doesn't have thunk functionality like Redux, but that's also part of the beauty as to how simple it is
React devs have forgotten the best state management library of them all, the U R L.
I love this library, however I only use it in cases where I don't want to expose state to the user like setting a navbar's sticky state. Everything else goes into the URL bar in our projects.
I do think storing state in the URL is something people completely forget about and don't utilize as much as they could. However, some might say that even with a routing library, the URL still exists outside of the React ecosystem/lifecycle since it's part of the browser, making it less pure React, as opposed to something like Jotai that is 100% tied to the React DOM. This definitely can have upsides though depending how you look at it. Ultimately I think it is best to choose what works best for you :)
It’s simple but it could get difficult to handle if you have many levers
That’s great. Simple explanation. But it doesn’t have any vulnerable issue right that’s my only concern.
Jotai seems very easy to use, with not much of a setup. But having a bunch of global states worries me for the performance. Personally, I like useImmer and useImmerReducer. I don't mind setting up the reducer function once, and Immer helps with the immutability problem that native reducer had.
This really looks fantastic! But...
1. Maintenance may end up becoming a nightmare in large scale production apps - especially in companies where PR reviews are not done "properly". 😉
2. I am curious what the performance is like in medium and large scale apps. 🤔
Thank you making this video though. Best thing I learnt today!
I've been actually working with jotai for quite sometime now, and yeah number 1 is a really valid point
i didn't benchmark it with other state management solutions but it seems like it's working fine
That's a great point! Because it's so simple it certainly could be easy to abuse on apps that are super large or complex. My company uses Jotai however and we've never had an issue with it to my knowledge. But to your point, I think something like Zustand is a valid use case when this concern pops up! In terms of performance I have not officially benchmarked it or seen official benchmarks versus other solutions/libraries, however I can say in my experience with both medium scale apps (my personal projects) and large scale apps (my companies codebase) it's been just as fast as normal React state or contexts!
Ive sucessfuly migrated to jotai, an app which has big amount of data (air traffic over US) which is updated with few seconds interval.
With jotai, its generalny easier to avoid rerenders, than eg. using redux. In terms of jotai performance overhead - its marginal, I recommend having a look at their codebase.
The not so great part is that you need to get used to different data model, and atoms itself have some uncomfortable (for me) quirks.
Theres some complexity while dealing with promises, or synchronizing state from outside source. 😊
@@AustinDavisTech I'll try to find a way to measure the performance of these state management solutions. Not sure how to begin, but I'm sure I'll enjoy the process of learning new things. 🙂
Btw, even though I have been working on React projects for many years now, I feel like I know very little. Videos such as this one will definitely be the push that I need to get good. 😛
Is it like recoil lite?
From my understanding it's pretty similar to recoil, although I'm not extremely familiar with that library so it's hard for me to say for certain
From my understanding Jotai was done looking at Recoil. But Recoil was a little more complex. Still, such a shame Fb stopped Recoil development.
isn’t this just recoiljs? Also Solid has this built in
it's same principal as signals
Nice , very niceee
i used it but it's too slow. it updates atom very slowly, i can't use more than 4 atoms after that it become very slow.
It's always been incredibly fast for me! It should be comparable in speed to useState/React contexts so long as you're not initializing atoms INSIDE React components and not causing unnecessary state changes & re-renders
Zustand is just a this with more bells and whistles.
Zustand seems really powerful, and I'll probably be making a video here on it soon once I get more experience with it. But if you want an extremely simple, out-of-the-box solution then Jotai is your guy :)
I think preact signals makes it much more simpler than this. This is a nice state management library tough...
Nice , but what about performance 😊
I don't know the official benchmarks of Jotai, but I will say my company uses it pretty extensively on a large application, and performance has never been an issue. Expect it to run at the same speed as normal React state + contexts
God this is beautiful.
nice
State managers based on atoms are good only on examples or when they are simple. But having many atoms, on medium or large projects, can make the state management code realy messy. Especially when you read code after a few months xD
Valtio is even crazier. It's also another poinandres react state manager
I'll have to try that out!
an problem with Valtio is it's not very suited to store complex objects (e.g a MediaStream) because it uses Proxies, whereas Zustand and Nanostores doesn't have issues with them
Its something like signal
Wow. Like a zustand
contextApi killer?
This has saved me from so much pain 😹
Great to hear! :)
Recoil actually does exactly this, how is this better than Recoil, Recoil actually has more features like getters, setters, family, effects etc.
Isn't this just signals with extra steps?
not really, Jotai and signals are very similar in a lot of ways, but ultimately behave differently behind the scenes
you 360 no scoped this tut
it is just using createcontext behind the scenes.
It can out be. It doesn't require you to wrap your app within a Provider.
@@tusharsnx Unfortunately, jotai-scope is using a context within the implementation of ScopeProvider.
@@realderek You're correct. To create a scoped atom you need context provider.
This is same as recoil
Jotai is bigger than Zustand
Congrats.
You now made your app infinitely harder to test and debug.
Global State is a problem. In fact, it was such a big problem a whole programming paradigm was created to address it.
Exactly, that's what my biggest concern was
I strongly disagree. Jotai is not a replacement for using normal React state. As long as you're not spamming atoms everywhere and you're using global state responsibly, it is 100% a better alternative than dodging global state entirely and prop drilling to infinity and beyond. There's a reason React itself supports global state with contexts and so many global state libraries have popped up. Web dev can get really complex, and without some sort of state management like Jotai, Zustand, or even contexts it becomes an absolute nightmare to navigate
@AustinDavisTech Contexts are semantically identical to Jotai.
The fundamental problem here is that it is unregulated and not isolated.
If a component changes state somewhere you can't know what it is without traceability like Redux offers with reducers.
Moreover, since you have global state you have to recreate the entire DOM to test one compoment.
No matter how you spin this, it is unregulated Global state which is an Anti-Pattern.
I realize wish Front End influencers would study software Engineering Principles instead of hyping up Anti-Patterns.
Okay now you're just making stuff up 😂. Just because atoms effectively function as a global useState with context does not mean the entire app is a dependency of every single atom and the entire DOM re-renders for every single atom. If you make for instance ten layers of nested components and use an atom for layers 3 and 7, rather than prop drilling, the entire app (layers 0-10) does not all re-render. This claim is objectively false. Components only become dependencies of an atom if they subscribe to it, exactly how contexts work. Please go and test for yourself and you'll see exactly what I mean. I'm not sure where you got this information from?
The only correct statement in here is that it is not isolated, which is the whole point. Complete isolation in a React app is not possible if you're building anything harder than a to-do list. Even if you're prop drilling, you're still making components become dependent on one another. Jotai, along with many other state management libraries, simply offers a better way to do it.
Again, there's a reason why these libraries exist and React itself has built-in support for state sharing. Frontend developers aren't dumb or bad for doing this, in fact the most functional React apps are almost ALL going to have some sort of state management system in place. Just like literally everything else in programming, global state can be bad if it's abused. Memory management in C can be abused, but it'd be ridiculous for me to claim that nobody should touch memory in C because it's dangerous. I understand where you're coming from but some of your claims are objectively false, and applying a blanket statement like "global = bad" doesn't address the genuine need for state management systems in React apps.
@AustinDavisTech Look the problem is simple. Let me simplify so you can understand.
1. It is unregulated global state
2. It is not isolated
So no matter what argument you have, it fails this fundamental test.
Why is it unregulated?
-> No one knows what updated what
Why is unregulation bad?
-> Because you cant debug it easily
Why is it not isolated?
-> Because it introduces non local coupling. Your components are not a function if the props but of some hidden state elsewhere.
Why is lack of isolation bad?
-> It makes things harder to test and harder to reason about. Instead of being able to think about it in isolation, you have to consider the whole app.
How do you do isolation and global state management?
-> You explicitly pass your dependencies as props in 1 direction. Never do 2 way prop-drilling. For example, you have your state in your store, you pass the selectors used by the component explicitly down.
But we can directly access the store with a hook, it is more complicated to pass down props explicitly. Why do you advocate that?
-> Sure, we can shoot ourselves in the foot if we want, but it doesnt mean it is good to do so. The reason we pass the selected state from the store explicitly is so we can achieve isolation and so we become agnostic to the state provider. If we access it directly, we make a coupling to that specific store. In other words we make an implicit dependency and so to test the component we need to now mock the whole redux store instead of just passing in props. It is literally the bananna and jungle problem.
==> Therefore we should avoid unregulated global state like in context api or jotai. It leads to well known anti-patterns and is anti-thetical to good software engineering practices.
Preact signals is much better and less bloated.
Not knocking signals at all but this is a gross oversimplification. Jotai is not bloated in the slightest AND is more "react-y" than signals are. Signals are cool and may have their place, but this kind of comparison doesn't do it justice
Austin Davis deletes comments he doesn't like just so you all know.
nah, valtio is better. no boilerplate like this
Is the boilerplate in the room with us?
@@AustinDavisTech 😹😹
nice