@@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).
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.
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.
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.
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
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.
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?
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 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
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 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.
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"
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
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
@@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)
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.
I am using Zustand to store userdata once I login in localstorage. And calling api again if i update user profile. This way I dont have to call api again and again if page refresh😅
@@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
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.
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.
This is somewhat hilarious. Never had such a problem with vuex using vue. Can someone explain me why you love to create more complex codebase and complex styles and then need a new library to fix it? Is react so much faster compared to vue? I can't relate, but I love the simplicity of vue in combination vuex-pathify which makes it even simpler to use. Keep it simple.
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.
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
i think at first thoughts, zustand is sustained, its states like situation that you could preserve its value... and yeah, after use zustand then learn using redux make me think, redux is true problem on the earth....
@@zayne-sarutobi and why? It’s just easier to use in 99% of cases. Valtio always allowed me to develop apps much much faster and I love that idea from Vue and even using it in non react apps as well (I used both of zustand and Valtio for a long time)
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.
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 😂
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.
You really can’t declare something is liked or loved because a fraction of developers know it and use it. Remember that react implementation is still so small in comparison to the rest of other web app tech stack. How about just not make ridiculous claims to get clicks and be honest by just saying you use this said thing in your projects .. the pros the cons.. and leave it at that.
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.
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?😊
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 😆
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
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.
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.
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.
I would love to see your thoughts on Jotai and why you might use one vs the other
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.
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. ❤
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.
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.
btw zustand is german and is pronounced tsooshtund
tsoo-shtund
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 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?
As a German, I read the title and I was like "Did he activate auto translate for the title?", but then I was "Oh, he means the Zustand library" lmao
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 think use-context-selector solves the problem of useContext causing unnecessary rerender
The German Zu is like T-zoo , a short T sound before zoo
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 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.
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
Am using ably for my chat.. what do you recommend?
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.
and thats why, even though I'm German, i give my projects english names. 😂
I like Valtio the most because of it's simplicity. Also has selective rendering and ends up with less code than Zustand.
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’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.
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. 😅
hi Theo, what's your opinion about MobX? would like to hear it
i heard zustand is pronounced 'not-redux'
What would you recommend for realtime/websockets communication? Roll your own, or another service?
For many days I have had a question: which browser are you using?
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
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
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.
Didn't knew it could do granular updates/rerenders... makes me wanna try it out even more.
Tsoo-shtunned. German for state.
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 😅
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
Zustand stand, zu Stand stand, und als es zu Stand zu stand, stand es zu.
i used jotai to create a markdown and node js version manager GUI using Tauri
meh Zustand has also too much boilerplate, been using effectorjs in many projects and nothing comes even close to it.
Missing zustand in angular
I am using Zustand to store userdata once I login in localstorage. And calling api again if i update user profile. This way I dont have to call api again and again if page refresh😅
"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
A minute 4 comment that I'll probably delete, but why would you use Zustand or any other store if you already have the data in the React Query cache?
Zustand is great for when you don’t have the data in React Query. I use it for things like A/V device selection, game states, theme picking etc
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!
I found Jotai first so I never zustand a try. I might tho, it seems promising
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.
So basically Pinia but for react?
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.
This is somewhat hilarious. Never had such a problem with vuex using vue. Can someone explain me why you love to create more complex codebase and complex styles and then need a new library to fix it? Is react so much faster compared to vue? I can't relate, but I love the simplicity of vue in combination vuex-pathify which makes it even simpler to use. Keep it simple.
use logic outside of react is a good approach, but mobx better allows to do that much simple and convenient way
I like nanostore more, it simpler and framework agnostic.
wow learned alot in this one
Good to know Theo came down to use object oriented programming
Hate to break it to you, but the second time correctly pronounced was actually not correct :)
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.
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.
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
Still waiting for Zen Review!
Preact signals is a good alternative to all this.
Recoil is great too ...
I added this in my orgs main FE product and this going fun. Its so easy and fun to use.
What about Jotai? It’s simple, it works.
It's a fantastic library. It's incredible.
I use Valtio, I love it even more. It's even from the same dev(s?).
i think at first thoughts, zustand is sustained, its states like situation that you could preserve its value...
and yeah, after use zustand then learn using redux make me think, redux is true problem on the earth....
XState is much easier to pronounce
ngl I prefer nanostores, works with other things such as Astro well as well - and it's easy AF to use
Its like you read my mind w these videos
Hey and why not Valtio? It’s insanely good and even Zustand is not even close!
Proxies are not necessarily the best things to work with in react
@@zayne-sarutobi and why? It’s just easier to use in 99% of cases. Valtio always allowed me to develop apps much much faster and I love that idea from Vue and even using it in non react apps as well (I used both of zustand and Valtio for a long time)
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.
did i just learned, React best practices in a ZUSTAND video
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 😂
Was using it for my first react project, clean and simpler than redux
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 ❤
Moral of the story. When working with React use the *Fewest* amount of React features possible 🤕
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.
what is he yapping about at 14:00 i am fucking lost
I like zustand, what i don't like are some of the "best practices" of it.
Lmao google translate scene killed me
30 min confirmation that React is a footgun.
can't understand why you suggest to use a deprecated functionality like create context. Any pratical reason?
he's nuts
@@najlepszyinformatyk1661 is nuts to use deprecated functions? what a wounderful way to write code...
zus tand === sister tooth in Dutch and is pronounced as recorded
You really can’t declare something is liked or loved because a fraction of developers know it and use it. Remember that react implementation is still so small in comparison to the rest of other web app tech stack. How about just not make ridiculous claims to get clicks and be honest by just saying you use this said thing in your projects .. the pros the cons.. and leave it at that.
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.
I started watching you during the 'needs a haircut' phase..the porno mustache took me a while to get used to
The pronunciation was in german
am I the only one who is listening theo twice(like useEffect in dev🤣🤣), there is some echo.
Your product loader looks like obs studio
oh man that blush