First time that i knew this library was in your serie of state management, and since then i use zustand in all my projects that i need some sort of state management. thank you, and keep creating good content.
I've used Zustand in a demo project of mine and really loved using it. It's a really cool library and super concise and combined with another library - Immer it's even better.
@@JBuchmann Ya, I've used that as well. When I posted my comment I wasn't aware of Redux Toolkit but after trying it I enjoyed using it quite a bit. I have used it only in a small demo project but from what I could tell, it did seem to have a pretty good implementation unlike the regular Redux lib which is a bit of a pain to use imo.
Oh, the ad hoc transition from useState to useAnyStore with Zustand is so much more convenient than it is/was with Redux. Btw, you don't have to spread the exciting state in the set function, Zustand does that implicitly for you.
Good point, I didn't even know that. I think the problem with spreading in Zustand happens because the syntax that you use in "set" looks like a standard one that requires spreading. I use immer to go around that, but it is a good tip. Thanks! :)
I've been pondering if it would be useful to in some way combine Zustand and useSWR for keeping a global store and API in sync, or if the problems they are trying to solve overlap too much.
Zustand shines for client state, anything that comes from the server delegate to react-query and your life will be a lot easier. Highly recommend Tanner Linsley’s “client vs server state” video on YT and the React-query blog from TKDodo
I have not watched the complete series, but first of all, thanks for this great series, very nice and practical introduction to TS! I just have a remark and that is that the add method is not very robust, if you delete and add an element, they will receive the same ID. Not sure if you fixed this later in the series, but you can correct this by using something like id = todos.length > 0 ? todos[todos.length-1].id + 1 : 0
Another great video into React TypeScript. Is the Zustand dev tools any good? since I find the Redux dev tools to come in clutch whenever I fear I've mismanaged my state
Hi Jack, I'm really like this playlist, it's something I've been looking for a long time. I have one question: Is it ok to replace Redux with Zustand, because I liked it (Zustand)? Nice job
If it's for a large client/company app, I'd personally stick with Redux/Redux Toolkit since it has the largest community/user-base behind it. If the company needs to add people to the team most likely they will already know Redux. But if it's for your own personal thing then use which ever you like the best that gets the job done.
Great video as always Jack - thank you! Question: is this state truly immutable? Had issues with a recent project where I was (accidentally) mutating the state directly (without using the setter), probably because the state was an array of objects - each obj containing an array of its own, so I'm assuming the direct mutating was due to the values being references. If I have such a value as the zustand state - will it still be immutable? From some testing I did it seems so, but I'm a (very) junior dev and wanted to be sure. (I'm aware zustand is a state manager, I don't intend on using it "just" for immutability, just wondering)
I haven't checked, but my hunch is that Zustand for performance reasons is not going to make immutable deep clones. It's going to store objects and array by reference, which does mean they could be altered directly without forcing an update.
Thanks for yet another great video. Guess it's up to personal preference whether one decides to go with Context, Redux, CreateGlobalState or Zustand? This one definitely seems like the simpliest solution
You should also factor in the cost of maintenance. Also with Context you need to realize that by using `useContext` you are subscribing to the entire context and if anything in the context changes ten you re-render. The state managers you listed allow you to use a selector on your store data to get just the data your component needs. And when you write those selectors well you will only get re-rendered when your portion of the store changes.
Thanks for the great video. Wow, Zustand really looks cool, nice and clean. Just a quick question - can the state update functions (that call "set") be async?
Have you tried nx workspaces? I absolutely love them. I like the separation of apps and libs. Also the monorepo setup. Although admittedly I've never used it in production.
@@jherr I feel the same. Storybook, Jest, Cypress for Angular or React if you choose, TypeScript ready to go. It's a joy to work with. I'm a consultant, so often you are called in to work on legacy code. Like for utilities, they move very slow. They haven't even contemplated Type script yet. But yeah for my own projects, I love it. I would like to see the ability to swap out Webpack for Vite. It's incredibly fast to me
very interested to see Zustand demonstrated. For usecases that are simple why not consider a simpler state manager ? Some go as far as migrating to other frameworks such as Svelt and Sveltkit for it's simplicity. It is good to see a cleaner, simpler implementation of something we all want - state but in React
@@jherr my bad wording - I meant to say youre suggestion to use Zustand is a very good one and I agree that this is much simpler to use. Sorry for that. I find your content highly informative and usefull as it is React based and I'm choosing to use React even when things like Svelte are around as I want to be able to hand over work or get others to work with me an React is more widely used. Oh, and your series 'no bs' on Typescript and React is tops also - its got me off the ground now with TS and the subtleties of React.
good series but the episodes should be progressive to the previous one, because I have no way of knowing that for the 20th episode I will need the skeleton from the 10th. There is confusion in my opinion. Tutorials like this or each subsequent one should build on the previous one or be each for itself with a skeleton for example 23th episode > before/after / 24th episode> before/after.greetings!
First time that i knew this library was in your serie of state management, and since then i use zustand in all my projects that i need some sort of state management.
thank you, and keep creating good content.
I've used Zustand in a demo project of mine and really loved using it. It's a really cool library and super concise and combined with another library - Immer it's even better.
Note, it wasn't mentioned in the previous Redux Toolkit video, but Redux Toolkit comes with Immer out of the box. :)
@@JBuchmann Ya, I've used that as well. When I posted my comment I wasn't aware of Redux Toolkit but after trying it I enjoyed using it quite a bit. I have used it only in a small demo project but from what I could tell, it did seem to have a pretty good implementation unlike the regular Redux lib which is a bit of a pain to use imo.
I've watched every video in this series so far... great work!
Okay, thats horrificly amazing how small that pack is and how cool it is to work with.
I'm ready to check Zustand out. Thanks for posting!
Thank you, Jack! 🙏 This series really made me a better developer. 😁 Loving Zustand already!!!
Zustand has such a natural API and just how I want to use state
Oh, the ad hoc transition from useState to useAnyStore with Zustand is so much more convenient than it is/was with Redux.
Btw, you don't have to spread the exciting state in the set function, Zustand does that implicitly for you.
I keep on forgetting that, whoops.
Good point, I didn't even know that.
I think the problem with spreading in Zustand happens because the syntax that you use in "set" looks like a standard one that requires spreading. I use immer to go around that, but it is a good tip. Thanks! :)
such an awesome teacher, i am getting so much confidence by watching your content....Thanks!!!!!!!!!!!!!!!!!!
great series so far!
Have a great weekend. Love the German pronunciation. 🙏😀
I hadn't heard of this library really thank you for this video
Beautiful content
Great video! Love zustand :)
Have to try out this state library, looks super fun :D
loved this series
It's still going. New episode next Monday!
Thanks for the great video
Thank you, Jack
I've been pondering if it would be useful to in some way combine Zustand and useSWR for keeping a global store and API in sync, or if the problems they are trying to solve overlap too much.
Zustand shines for client state, anything that comes from the server delegate to react-query and your life will be a lot easier. Highly recommend Tanner Linsley’s “client vs server state” video on YT and the React-query blog from TKDodo
I have not watched the complete series, but first of all, thanks for this great series, very nice and practical introduction to TS!
I just have a remark and that is that the add method is not very robust, if you delete and add an element, they will receive the same ID. Not sure if you fixed this later in the series, but you can correct this by using something like id = todos.length > 0 ? todos[todos.length-1].id + 1 : 0
Fair enough. ;)
Another great video into React TypeScript. Is the Zustand dev tools any good? since I find the Redux dev tools to come in clutch whenever I fear I've mismanaged my state
github.com/beerose/simple-zustand-devtools ?
Hi Jack, I'm really like this playlist, it's something I've been looking for a long time.
I have one question: Is it ok to replace Redux with Zustand, because I liked it (Zustand)?
Nice job
I think it's fine. You should check out my 20 state managers video th-cam.com/video/P95DuIBwnqw/w-d-xo.html
If it's for a large client/company app, I'd personally stick with Redux/Redux Toolkit since it has the largest community/user-base behind it. If the company needs to add people to the team most likely they will already know Redux. But if it's for your own personal thing then use which ever you like the best that gets the job done.
interesting content
nice video
Great video as always Jack - thank you! Question: is this state truly immutable? Had issues with a recent project where I was (accidentally) mutating the state directly (without using the setter), probably because the state was an array of objects - each obj containing an array of its own, so I'm assuming the direct mutating was due to the values being references. If I have such a value as the zustand state - will it still be immutable? From some testing I did it seems so, but I'm a (very) junior dev and wanted to be sure. (I'm aware zustand is a state manager, I don't intend on using it "just" for immutability, just wondering)
I haven't checked, but my hunch is that Zustand for performance reasons is not going to make immutable deep clones. It's going to store objects and array by reference, which does mean they could be altered directly without forcing an update.
Nice
Thanks for yet another great video. Guess it's up to personal preference whether one decides to go with Context, Redux, CreateGlobalState or Zustand? This one definitely seems like the simpliest solution
You should also factor in the cost of maintenance.
Also with Context you need to realize that by using `useContext` you are subscribing to the entire context and if anything in the context changes ten you re-render. The state managers you listed allow you to use a selector on your store data to get just the data your component needs. And when you write those selectors well you will only get re-rendered when your portion of the store changes.
Thanks for the great video.
Wow, Zustand really looks cool, nice and clean. Just a quick question - can the state update functions (that call "set") be async?
yes, just call set when you're ready, zustand doesn't care if your actions are async or not.
@@ray-lee how "dare" you copy-paste directly from the docs :D
@@NorweskiDrwal that's the best answer lol
@@ray-lee I know :D
Have you tried nx workspaces? I absolutely love them. I like the separation of apps and libs. Also the monorepo setup. Although admittedly I've never used it in production.
Ahhh... You're spoiling episode 32!
@@jherr oops. Sorry bout that
@@kettenbach I am really blown away by it. I hand-rolled our TS monorepo at my job and NX is sooooo much easier. Holy schnikeys.
@@jherr I feel the same. Storybook, Jest, Cypress for Angular or React if you choose, TypeScript ready to go. It's a joy to work with. I'm a consultant, so often you are called in to work on legacy code. Like for utilities, they move very slow. They haven't even contemplated Type script yet. But yeah for my own projects, I love it. I would like to see the ability to swap out Webpack for Vite. It's incredibly fast to me
@@kettenbach Definitely gotta do more on/with vite. :)
very interested to see Zustand demonstrated. For usecases that are simple why not consider a simpler state manager ? Some go as far as migrating to other frameworks such as Svelt and Sveltkit for it's simplicity. It is good to see a cleaner, simpler implementation of something we all want - state but in React
A simpler state manager than Zustand? What would you recommend? (Beside porting to svelte (which I totally agree is awesome)).
@@jherr my bad wording - I meant to say youre suggestion to use Zustand is a very good one and I agree that this is much simpler to use. Sorry for that. I find your content highly informative and usefull as it is React based and I'm choosing to use React even when things like Svelte are around as I want to be able to hand over work or get others to work with me an React is more widely used. Oh, and your series 'no bs' on Typescript and React is tops also - its got me off the ground now with TS and the subtleties of React.
very nice videoo :)
good series but the episodes should be progressive to the previous one, because I have no way of knowing that for the 20th episode I will need the skeleton from the 10th. There is confusion in my opinion. Tutorials like this or each subsequent one should build on the previous one or be each for itself with a skeleton for example 23th episode > before/after / 24th episode> before/after.greetings!
At the start of the series they do. But later on as I get into more esoteric or advanced topics they are mainly standalone.
i guess valtio will be the next one? :D
Only one more, XState! And then into project design and interop with Javascript, testing with Jest, and Monorepos with NX.
@@jherr oh yes, state machines please! :)
how to use persist in zustand with typescript