@@joschkazimdarsGiven that "z" is usually pronounced like in "buzzing" and "shtand" looks like "stand", i'd write the pronounciation as "tsoo-shtund".
@@terra_creeper actually, trying to describe a pronounciation with english letters seems impossible. They have different sounds for the same letters all the time.
@@joschkazimdars I don't think it's impossible, just very hard. Single letters don't have a consistent pronounciation, but most letter combinations do. You just have to add letters until there is no ambiguity anymore.
Because it's just so simple to setup and use. However its simplicity comes with a cost, it's unopinionated therefore can lead to inconsistencies. The key thing to remember when using zustand is to never NOT use a selector, otherwise you'll subscribe to your whole store and trigger absurd amount of rerenders where you call it without one. (const foo = useStore((state) => state.foo)) Also, not using the slice pattern can lead to headaches when one store needs something from another.
Agree, people don't understand how powerul Redux Toolkit + RTK Query is and how nice it is to use it due to its opinionated nature. Theo just has a way of picking the worst technologies and pretend they make sense. I'm at a point where I just know that if Theo talks about something I gotta avoid it.
And the „a“ in English is often times pronounced like an „ä“ in German or an „æ“ in danish. The correct „a“ for „Zustand“ would be the first a in „arbitrary“ :)
A lot of people saying that Zustand is like Redux Toolkit but less extra. But sometimes even Zustand isn't needed. Jotai is unbelievable when you just want to have little bits of state that you can grab from anywhere. They're different tools.
Exactly. It all depends on the case scenario. For micro-states, Jotai is an excellent tool. If on the other hand you have cases where you need big complex states due to the application's needs then Zustand is an excellent choice - and, surprisingly, it works really well with NextJS (unlike Redux Toolkit - at least in the current incarnation).
@@LC12345 German pronunciation might not be intuitive, but at least it's consistent, which is way, way, _way_ more than we can say about English. I don't speak German at all, I barely know a few words and sentences, but I immediately knew how to pronounce it just by looking at the word.
@@cobrasys You’re lying at one end here. Either you know German or you don’t know that a beginning Z is pronounced “ts” and that this word’s “st” is pronounced “scht” because it’s the beginning of a combined word. Stop playing.
@LC12345 what a weird false dichotomy. You're suggesting that it's impossible to know a few words or sounds in a language without being able to communicate in it. Most people know and can correctly say the name 'Einstein' which requires correctly handling the 'ei' German dipthong
At this I kind of don't care what state management library is used in a project, just understand the observer pattern (or redux in UI) once and every other library is just a syntax sugar.
You should not judge tools based on extremely basic examples, but more if they can support also support complex fully modular apps. I would rather use a little too heavy tool for small apps and know I have no trouble when it grows and needs to be modulaized, then a lightweight tool where I know I might get in trouble at some point and have to refactor the whole app. Most engineers and companies don't do that research, which costs them sooo much money. Research also needs experience of course, you cannot do research when you never built large scale application, because you so not know what to research and what is actually important.
Why is everyone falling in the same trap. According to the functional programming we don't have to mix data and functions. Use pure atoms from Jotai and pass it to the custom hooks/context. State managers should only store the state and should not modify by itself. This will complicate the React app more than you think. Please experiment with these guys. Peace out.❤
“It’s interesting how getting used to the React way lead you to overlook simpler solutions in plain JS to the same problem.” I couldn’t say it better myself regarding all of these redux-like solutions. 99.9% of you don’t need it.
i have been around since pre mustache theo, but post-needs a haircut- theo, joined as someone brand new to web dev, have enjoyed my time with my website since! and the discord has grown to be so large and is still such a great place to have discussions and help. time flies
The ability to access the store from outside of react is super handy when you want your fetch-like functions (i.e. the functions you end out passing down to react-query) to have access to things like auth or token data, and you want to avoid huge amounts of prop-drilling.
@@ShafickCure the boilerplate only on the setup And toolkit gives you hooks for your api's automatically (unlike react query where you need to write them yourself). Also it handels caching and invalidation automatically I tried both redux toolkit and react query and I think toolkit has less boilerplate than react query 🙃 Although toolkit has some missing features like infinite scroll (I've never used zustand though, so I can't compare it)
Is this why countries and many cities have English names in addition to how they are pronounced in their native language, because English speakers simply don't bother?
Native english speakers are some of the most inept at learning a second language and wrapping their heads around different pronunciations, because they don't have that much need to learn a 2nd language.
A lot of English people can't even speak English correctly. I have a lot of respect for all the people in countries like Poland that have a very complex pronunciation system of their own and can still speak English better than many native Engliah speakers
One day the world will discover react-tracked and truly appreciate it. For now it's just a library that came before its time, and zustand gets all the love.
Actually there is only little difference of the code in the components with Zustand vs RTK. Yes you write more code with RTK outside of the components, but you also get working devtools. With Zustand the redux devtools time machine for example does not work and it does not seem that this will be fixed anytime soon since Zustand has no control over that repo.
@@zayne-sarutobi Time machine works for you? I tested it a few weeks ago and it did not work. Issue is also still open in GitHub. Redux-devtools 1369. You can go forward and backwards in redux devtools with Zustand with the forward and backward buttons? Unlikely
State management is EASY if you get/set in an imperative way and use reactivity when needed only to read and show in the ui. As a FE developer that had the opportunity to work with all major frameworks (AngularJS, Angular 2+, Vue, React and Svelte) i can tell that React and Angular communities really do state management in the most over engineered way. stop putting "middlewares"/"asyncThunks" in the damn global store. Just write a bunch a functions that you call from the components and those functions will just get/state from the stores. It works great in case of SPA, since you can put stuff in modules. In case you need SSR just use whatever solution the framework provide to have per session context or the context api directly and pass this context to the same functions, the context is what will keep the reference to the global stores.
We have one opinionated way to enforce consistency. Every action like actionSetFoo is prefixed with the word action. This way everyone isn’t coming up with their own naming.
What I've Learned in 7 Years as a Developer (JavaScript/React/Python) Use as few packages as possible. Keep things simple. Need shared state? Forget Redux or Zustand-learn React’s Context API. Is your app complex? Don’t overcomplicate it. My frontend team spent two weeks refining our internal guidelines, and now our structure is straightforward and easy to maintain-without touching any state management libraries. Start thinking for yourself. Need a package to check if an array is empty? Write your own code and tests. Sure, a package installs in 10 seconds, but maintaining it (and the others) is a time sink. When one package works with Node 20 and another doesn’t, guess what-you’re stuck maintaining even more. Oh and you also have to do that in your 20 micro applications. Stop making things harder for yourself. The JavaScript ecosystem already has enough mess.
You can potentially optimise the useContext hook which will only trigger re-renders for values that are changed. I think Jack Harrington has already made a video on this, something like "Moving fast with react context"
I don't want all my business logic in functional components so I like the saga middleware option to interact with redux. Is there something similar in Zustand?
bro, react never says that use Context for state management. It is usually for props drilling to children. It hasnt been like a performent state manager at all. But, in most cases, React can handle such rerenders with efficient way. But the library still need some performant way inside. Maybe next versions have optimized Contexts usages with selectors
Cool vid! Using children reference in the useMemo dependency arr is going to re-create the memoized instance due to JSX always returning a new object for children props in React. Also, driving re-renders off of the result of a selector function is not unique to Zustand - Redux does the same thing.
Redux is the most ridiculous thing I’ve ever seen. It complicates things to unnecessary degree. I remember spending hours trying to understand WHY they do things the way they do it, but their documentation is one of the worst out there. It did slightly get better when Toolkit came out, but seriously too much stress and abstraction hidden in complicated documentation. Zustand saved my life.
Theo pls if you like zustand you need to try Effector, we use at the moment effector and migrate from redux. I'm not joking but it's better than zustand and TS working more correct
That part about children prop needing to use memoizisation - Was the issue that when the context updated state it would re-render the children? Children was an element not a component so it wouldn't re-render it anyway which we did see wasn't the issue. Just wanted to confirm I'm not missing something in my understanding of re-renders. React only re-renders all non memoized children components when state changes not elements.
Hey guys, can anybody explain me why does RecoilJS RIP? It was very excellent in case of async data and complex reacting on atom changing via selectors? Thanks. I found it more usable than Jotai (which is often called simplified version of RecoilJS). The separation in naming of 'Family' and 'select' was cool to build a kinda pre-architecture in 'state' terms. It was clear what is source of truth (atoms) and what are reflectors and reactive states. As well as where it was something like solid state - origin atoms and selectors, and where there are sets of many - families.
Why use zustand for fetched data instead of tanstack query? 5:55 And why would you fetch from Tanstack Query then put into provider instead of just using cache as global state? 6:55
Ist es Deutsch? Edit: me thinking about the German pronounciation... *first 2 minutes using Google translate to pronounce it* me - I need to tell my coworker, the only other person I've met in 6 years whose learned German! This is too funny 😂
Last time I tried a new state management library (recoil) I ended up tearing it out and replacing it with redux toolkit since recoil had a memory leak that crashed our app. So I’m weary of new libraries in which swapping it out is very laborious.
That's the same reason I'm sticking with RTK (for now at least) ... The design, planning, qa, and code quality of the Simpsons guy is far superior IMO. Jotai and Zustand just doesn't give me that professional feeling, if you know what i mean.
Maybe it just means that react is thinking you render same component? You can add wrapper component and render the full component with key based on url parameters.
10 years ago when i started learning javascript, it was either react or vue for me. i hated redux so much i wen't vue way. zustand might be the only reason i would convert
My mental Zustand worsened with every time you said the word
Das sind ja Zustände hier
that's how language works unfortunately, assuming you respect/like the speaker.
Shoosh-tand!
i love it because it's not redux
Real 😂😂😂
I hate redux😅😅😅
This guy gets it
Nailed it!
Why hate it so much?😊
Zustand also means "state", which fits better IMHO.
Zustimmung!
Daumen hoch!
ah, there it is, the German muss jetzt kommentieren-drang ^^
Haha it should be cuz another state library from the same author is named Jotai, which means state in Japanese.
You know what's cool, redux devtools
0:45 American moment
Very american, yes. We also could start calling Theo "See Oh" and just "dont care" :D
@@SubwayToSally90 SEO
ZOOSHTANT
more like typical behaviour of any native English speaker who's never had to learn another language
I think it means state in English not condition :) source living in Germany
It's pronounced zustand not zustand
Bro you have it backwards
smartest comment ever
It's actually pronounced Zustand
@@CoDEmanX47 nope it's zustand
Lol tap the translate button in RUclips 😆
I like that the poll doesn't even have the right way to pronounce it 😂
If it's written in Murican I'm pronuncing it in Murican
zuh-shtand would be correct
@@joschkazimdarsGiven that "z" is usually pronounced like in "buzzing" and "shtand" looks like "stand", i'd write the pronounciation as "tsoo-shtund".
@@terra_creeper actually, trying to describe a pronounciation with english letters seems impossible. They have different sounds for the same letters all the time.
@@joschkazimdars I don't think it's impossible, just very hard. Single letters don't have a consistent pronounciation, but most letter combinations do. You just have to add letters until there is no ambiguity anymore.
Because it's just so simple to setup and use. However its simplicity comes with a cost, it's unopinionated therefore can lead to inconsistencies.
The key thing to remember when using zustand is to never NOT use a selector, otherwise you'll subscribe to your whole store and trigger absurd amount of rerenders where you call it without one. (const foo = useStore((state) => state.foo))
Also, not using the slice pattern can lead to headaches when one store needs something from another.
lol honestly, using a 'getter' is such a basic code pattern i'm not sure that fits as being 'opinionated' or coming with a 'cost'
@@PraiseYeezus
He meant having the ability tp cause problems when having conplex use cases
Wrong, Zustand does have the slices pattern as well, read the docs next time: zustand.docs.pmnd.rs/guides/slices-pattern
@@PraiseYeezus Well, what can happen is one guy can write 10 stores and another will write 10 slices which is inconsistant, just one example
Agree, people don't understand how powerul Redux Toolkit + RTK Query is and how nice it is to use it due to its opinionated nature. Theo just has a way of picking the worst technologies and pretend they make sense. I'm at a point where I just know that if Theo talks about something I gotta avoid it.
In Italian and German you pronounce the "z" (zed) like "tz"--just like the "z"s in pizza--it's not that difficult. Hence: "Tzoo-shtand"
Yeah and I don't think Google AI voice is better as it feels like she said Zoo-stand.
And the „a“ in English is often times pronounced like an „ä“ in German or an „æ“ in danish. The correct „a“ for „Zustand“ would be the first a in „arbitrary“ :)
I think “Tzoo-shtunt” would be the closest…
Bro, how do expect him to say that when he can't even say mirror? Murrrruuur
Not relevant for speaking English
A lot of people saying that Zustand is like Redux Toolkit but less extra. But sometimes even Zustand isn't needed. Jotai is unbelievable when you just want to have little bits of state that you can grab from anywhere. They're different tools.
Exactly. It all depends on the case scenario. For micro-states, Jotai is an excellent tool. If on the other hand you have cases where you need big complex states due to the application's needs then Zustand is an excellent choice - and, surprisingly, it works really well with NextJS (unlike Redux Toolkit - at least in the current incarnation).
Ok, let's call him Otto for the rest of our lifes.
"Meine Fresse was für ein 'zustand' hier auf diesem Kanal" 😂
Nicht mal richtig ausprechen kann er es haha
@@MichaelReichNo offense but German pronunciation isn’t intuitive at all. And I speak enough German to make myself understandable.
@@LC12345 German pronunciation might not be intuitive, but at least it's consistent, which is way, way, _way_ more than we can say about English. I don't speak German at all, I barely know a few words and sentences, but I immediately knew how to pronounce it just by looking at the word.
@@cobrasys You’re lying at one end here. Either you know German or you don’t know that a beginning Z is pronounced “ts” and that this word’s “st” is pronounced “scht” because it’s the beginning of a combined word. Stop playing.
@LC12345 what a weird false dichotomy. You're suggesting that it's impossible to know a few words or sounds in a language without being able to communicate in it. Most people know and can correctly say the name 'Einstein' which requires correctly handling the 'ei' German dipthong
At this I kind of don't care what state management library is used in a project, just understand the observer pattern (or redux in UI) once and every other library is just a syntax sugar.
Because its the closest thing to Pinia for React
Yeah that's I was thinking 😅 It's the closest thing I've find so far.
and thats why, even though I'm German, i give my projects english names. 😂
You should not judge tools based on extremely basic examples, but more if they can support also support complex fully modular apps. I would rather use a little too heavy tool for small apps and know I have no trouble when it grows and needs to be modulaized, then a lightweight tool where I know I might get in trouble at some point and have to refactor the whole app. Most engineers and companies don't do that research, which costs them sooo much money. Research also needs experience of course, you cannot do research when you never built large scale application, because you so not know what to research and what is actually important.
Why is everyone falling in the same trap. According to the functional programming we don't have to mix data and functions. Use pure atoms from Jotai and pass it to the custom hooks/context. State managers should only store the state and should not modify by itself. This will complicate the React app more than you think. Please experiment with these guys. Peace out.❤
“It’s interesting how getting used to the React way lead you to overlook simpler solutions in plain JS to the same problem.” I couldn’t say it better myself regarding all of these redux-like solutions. 99.9% of you don’t need it.
i have been around since pre mustache theo, but post-needs a haircut- theo, joined as someone brand new to web dev, have enjoyed my time with my website since! and the discord has grown to be so large and is still such a great place to have discussions and help. time flies
I would love to see your thoughts on Jotai and why you might use one vs the other
btw zustand is german and is pronounced tsooshtund
tsoo-shtund
I like the tip on using a context for a zustand store and not treating it like a global store. I think I'm going to try that out.
But still 99% of companies still ask Redux experience in resume...😢
The managers don't need to work on this shit. They just want someone to maintain all this shit that he/she wrote. 😅
Tsoo-shtunned. German for state.
I think use-context-selector solves the problem of useContext causing unnecessary rerender
I like Valtio the most because of it's simplicity. Also has selective rendering and ends up with less code than Zustand.
Zustand stand, zu Stand stand, und als es zu Stand zu stand, stand es zu.
The ability to access the store from outside of react is super handy when you want your fetch-like functions (i.e. the functions you end out passing down to react-query) to have access to things like auth or token data, and you want to avoid huge amounts of prop-drilling.
Redux toolkit + rtk query are so underrated 😢
Nope, redux is a pain even with them
It's ok. The boilerplate is ridiculous.
@@ShafickCure the boilerplate only on the setup
And toolkit gives you hooks for your api's automatically (unlike react query where you need to write them yourself).
Also it handels caching and invalidation automatically
I tried both redux toolkit and react query and I think toolkit has less boilerplate than react query 🙃
Although toolkit has some missing features like infinite scroll
(I've never used zustand though, so I can't compare it)
@@mohammadyahyaq React Query isnt a global store like Redux, its an async state manager.
@@ShafickCure the biggest weakness in toolkit in my opinion is the documentation
Probably that's why people don't use it 😅
I might just rewite my entire project from redux to zustand just because of the hoops I had to jump / hacks I had to implement Agora. Great solution!
Is this why countries and many cities have English names in addition to how they are pronounced in their native language, because English speakers simply don't bother?
Native english speakers are some of the most inept at learning a second language and wrapping their heads around different pronunciations, because they don't have that much need to learn a 2nd language.
A lot of English people can't even speak English correctly. I have a lot of respect for all the people in countries like Poland that have a very complex pronunciation system of their own and can still speak English better than many native Engliah speakers
That one’s colonialism
I’m a German and I love how you pronounce “Zustand” - I’ll start a petition to change the official German pronounciation into “sust and”
You use the "s" to spell the /z/ sound. Identity checks out lol.
I'd say tsoo-shtunned.
One day the world will discover react-tracked and truly appreciate it. For now it's just a library that came before its time, and zustand gets all the love.
Love your content Theo. But i‘m German and 1:52 wasn‘t that far away 😂 but it is always funny to see amaricans try to pronounce german words ❤
I pretty much wrote an implementation like zustand when react contexts came out because we werent allowed to use mobx and i hated redux that much.
Its like you read my mind w these videos
I added this in my orgs main FE product and this going fun. Its so easy and fun to use.
XState is much easier to pronounce
i heard zustand is pronounced 'not-redux'
Good to know Theo came down to use object oriented programming
I like nanostore more, it simpler and framework agnostic.
Actually there is only little difference of the code in the components with Zustand vs RTK. Yes you write more code with RTK outside of the components, but you also get working devtools. With Zustand the redux devtools time machine for example does not work and it does not seem that this will be fixed anytime soon since Zustand has no control over that repo.
It's works for me tho? Why is that?👀
@@zayne-sarutobi Time machine works for you? I tested it a few weeks ago and it did not work. Issue is also still open in GitHub. Redux-devtools 1369. You can go forward and backwards in redux devtools with Zustand with the forward and backward buttons? Unlikely
@@zayne-sarutobi sorry it is the Trace that is not working. Also confirmed it with the maintainer in Discord. They cannot do much there.
Lmao google translate scene killed me
Didn't knew it could do granular updates/rerenders... makes me wanna try it out even more.
State management is EASY if you get/set in an imperative way and use reactivity when needed only to read and show in the ui.
As a FE developer that had the opportunity to work with all major frameworks (AngularJS, Angular 2+, Vue, React and Svelte) i can tell that React and Angular communities really do state management in the most over engineered way. stop putting "middlewares"/"asyncThunks" in the damn global store.
Just write a bunch a functions that you call from the components and those functions will just get/state from the stores. It works great in case of SPA, since you can put stuff in modules.
In case you need SSR just use whatever solution the framework provide to have per session context or the context api directly and pass this context to the same functions, the context is what will keep the reference to the global stores.
We have one opinionated way to enforce consistency. Every action like actionSetFoo is prefixed with the word action. This way everyone isn’t coming up with their own naming.
It's a fantastic library. It's incredible.
I started watching you during the 'needs a haircut' phase..the porno mustache took me a while to get used to
What I've Learned in 7 Years as a Developer (JavaScript/React/Python) Use as few packages as possible. Keep things simple. Need shared state? Forget Redux or Zustand-learn React’s Context API. Is your app complex? Don’t overcomplicate it. My frontend team spent two weeks refining our internal guidelines, and now our structure is straightforward and easy to maintain-without touching any state management libraries. Start thinking for yourself. Need a package to check if an array is empty? Write your own code and tests. Sure, a package installs in 10 seconds, but maintaining it (and the others) is a time sink. When one package works with Node 20 and another doesn’t, guess what-you’re stuck maintaining even more. Oh and you also have to do that in your 20 micro applications. Stop making things harder for yourself. The JavaScript ecosystem already has enough mess.
Context API would've been great imho, expect it isn't performant when used as anything beyond a simple transport mechanism
Fact. Many developer use too many library just to overcomplicate their code
You can potentially optimise the useContext hook which will only trigger re-renders for values that are changed. I think Jack Harrington has already made a video on this, something like "Moving fast with react context"
Moral of the story. When working with React use the *Fewest* amount of React features possible 🤕
I love it. and I use it always on my projects. Thanks Zustand to save me from Redux hell 😅
I don't want all my business logic in functional components so I like the saga middleware option to interact with redux. Is there something similar in Zustand?
bro, react never says that use Context for state management. It is usually for props drilling to children. It hasnt been like a performent state manager at all. But, in most cases, React can handle such rerenders with efficient way. But the library still need some performant way inside. Maybe next versions have optimized Contexts usages with selectors
What about Jotai?
Jotai ftw
I use jotai, it just simple to setup, using in production website, it works.
The video creater may not use Jotai. I use Jotai for state management and custom hooks to update it. Everything works great. ❤
Great to have an American say German words.as always Trying is good enough. Batteriezustand
Zustand dee Korvette
wow learned alot in this one
Was using it for my first react project, clean and simpler than redux
did i just learned, React best practices in a ZUSTAND video
Cool vid! Using children reference in the useMemo dependency arr is going to re-create the memoized instance due to JSX always returning a new object for children props in React. Also, driving re-renders off of the result of a selector function is not unique to Zustand - Redux does the same thing.
Redux is the most ridiculous thing I’ve ever seen. It complicates things to unnecessary degree. I remember spending hours trying to understand WHY they do things the way they do it, but their documentation is one of the worst out there. It did slightly get better when Toolkit came out, but seriously too much stress and abstraction hidden in complicated documentation.
Zustand saved my life.
30 min confirmation that React is a footgun.
Am using ably for my chat.. what do you recommend?
Recoil is great too ...
Theo pls if you like zustand you need to try Effector, we use at the moment effector and migrate from redux. I'm not joking but it's better than zustand and TS working more correct
Susana Walks
Missing zustand in angular
Why should you never look up the source code (10:07) ? I heard it's actually very much the opposite for understanding how things works.
I found Jotai first so I never zustand a try. I might tho, it seems promising
Preact signals is a good alternative to all this.
I migrated from Ably to Soketi in a large app, definitely worthy, Ably is terrible
I hated React until I started using Zustand. It’s perfect.
Zustand is my babe, so much love
That part about children prop needing to use memoizisation - Was the issue that when the context updated state it would re-render the children? Children was an element not a component so it wouldn't re-render it anyway which we did see wasn't the issue. Just wanted to confirm I'm not missing something in my understanding of re-renders.
React only re-renders all non memoized children components when state changes not elements.
I like zustand, what i don't like are some of the "best practices" of it.
oh man that blush
Hey guys, can anybody explain me why does RecoilJS RIP? It was very excellent in case of async data and complex reacting on atom changing via selectors? Thanks. I found it more usable than Jotai (which is often called simplified version of RecoilJS). The separation in naming of 'Family' and 'select' was cool to build a kinda pre-architecture in 'state' terms. It was clear what is source of truth (atoms) and what are reflectors and reactive states. As well as where it was something like solid state - origin atoms and selectors, and where there are sets of many - families.
Zustand + Context API is great / makes the context API actually useable
I do the following setup
Client state - zustand
Server state - React Query aka Tanstack query
is there any scenarios where i should use context API?
I use zustand only
@@statuschannel8572there is no
You don't need Context if you have Zustand, since the latter already tracks state
I don't understand why you would need context api if you have zustand? Can you please give a use case?
Das sind ja Zustände hier
all Germans crying
hi Theo, what's your opinion about MobX? would like to hear it
What would you recommend for realtime/websockets communication? Roll your own, or another service?
Why use zustand for fetched data instead of tanstack query? 5:55
And why would you fetch from Tanstack Query then put into provider instead of just using cache as global state? 6:55
"I'm never saying it that way. I don't care." LOLOL
Primagen going Sayan
ngl I prefer nanostores, works with other things such as Astro well as well - and it's easy AF to use
Ist es Deutsch? Edit: me thinking about the German pronounciation... *first 2 minutes using Google translate to pronounce it* me - I need to tell my coworker, the only other person I've met in 6 years whose learned German! This is too funny 😂
Nanostores ftw
Oh, poor Tio.
Last time I tried a new state management library (recoil) I ended up tearing it out and replacing it with redux toolkit since recoil had a memory leak that crashed our app. So I’m weary of new libraries in which swapping it out is very laborious.
That's the same reason I'm sticking with RTK (for now at least) ...
The design, planning, qa, and code quality of the Simpsons guy is far superior IMO.
Jotai and Zustand just doesn't give me that professional feeling, if you know what i mean.
I use Valtio, I love it even more. It's even from the same dev(s?).
say it right, then I'll watch the video
wow I was just discussing about this yesterday redux or zustand
zustand has some issues too. It doesn't reset state automatically when you move between pages. This can be inconvenient in certain use cases.
Maybe it just means that react is thinking you render same component? You can add wrapper component and render the full component with key based on url parameters.
if your store gets initialised together with a component you'll not have this problem
Create a scoped store solves this
It's just the best out there.
10 years ago when i started learning javascript, it was either react or vue for me. i hated redux so much i wen't vue way. zustand might be the only reason i would convert
Tsuschtand
use logic outside of react is a good approach, but mobx better allows to do that much simple and convenient way
As a german this is outrageous :D
meh Zustand has also too much boilerplate, been using effectorjs in many projects and nothing comes even close to it.
Still waiting for Zen Review!