In my POV, React state management libraries can be divided into three groups:
Reducer-based: requires dispatching actions to update a big centra...
For further actions, you may consider blocking this person and/or reporting abuse
The only good thing Redux still has going for it is its Devtools, and that will never be a good enough reason for me to use it. It's the most used tool because it's the earliest robust tool and goes back to the days of class components.
Redux, and central state management in general, make needless globalization the go-to approach to share state, which can quickly turn into a nightmare.
I am convinced that the notion that "central stores are suitable for large projects" is the biggest sham in history. I know from experience that the opposite is more likely to be true.
Central stores are only good for bigger apps only when most state is global by definition. That's it. And I don't know many such use-cases.
It looks like you and I had the same DX with Redux 😆
+1
If react offers a context and providers and a way to consume the context values using hooks, you must have really specific needs to go and search for libraries. I believe 90% of projects don't.
So, use your common senses, as first step, then plan further.
The need is most often the re-rendering the whole app problem. It is better to re-render a few components than the whole tree, that's also the reason why you should work with multiple contexts and not just with one which however becomes hard to manage.
Yes, but you can have as many context providers as you need, as atomic as you need them to be. Provide them as hooks and use them. You'll avoid the dependency to any 3rd party libs and go with pure react. You'll have full control over what you provide and the scope you consume your context in.
Never understood overcomplicating our own work with additional libs if we can achieve our goals with the tools at hand.
There should be real need to solve a problem when you make a decision and first thing is to try to write some code instead jumping on libs wagon ... Libs are good think but they are created to solve problems where they exist.
but the moment your app needs a global context provider (let's say for global notifications), then the app is screwed with multiple rerenders with Context
It is getting interesting .. and why you think so?
It is up to you when you re-render and what, no? And why any change in whatever of your context hooks will cause re-render of anything you do not change?
It is not as easy as you might think, there is a reason why the number one rule to learn is that Context alone is not a state management solution.
Well, I think there is a misunderstanding of what is a re-render and what is a re-computation.
A re-computation is when the current component is called again (as a function) and all logic inside is being triggered.
Example:
You will see that the LogginComponent is re-computed and the console log will show that the externalCounter is increasing every time you click the "Force recompute" button. Something similar happens with the useReducer
Hmm, shall you give a thought about what it will be for moderately sized and complex application to get dependent on some libraries that are perfect, but not actually needed?
In summary, React's Context API, when used judiciously with React Hooks, provides a more efficient way to manage state and control rendering behavior in a React application. It offers a simpler and often sufficient alternative to more complex state management libraries for many use cases, especially in moderately sized applications, as I mentioned above.
So, instead of 'first rules' we better use our common senses' as rules often are subjective to the use case or the user.
Do whatever you believe just keep in mind that context is not a state manager.
I would say that a "moderately sized" app is one which does not have:
When you start to have complications like:
I know how context works, and I also wrote context like you do since 2019, you are misunderstanding a few thing and you think you simplifying while in reality you write more code. I bet if you show me a project where you do this I will find tons of unessecary re-renders.
Atom-based Libraries
Atom-based Libraries / Weaknesses
Jotai
Generel
20Kb difference is huge, who says it is not?
Only one who can that are people using Nextjs that ships 200kb of JS even in a simple hello world example -> RIP all old/cheap smartphone mobile users (and all users of your app/website in third world countries).
I have written an article, where I touched on state management in react
dev.to/adaptive-shield-matrix/reac...
TLDR: no one should use react build-in state managers. Pick one library - Jotai (recommended) or Zustand and use it exclusively.
Here is some prior art comparing react state managers, about a year ago
frontendmastery.com/posts/the-new-...
I'm not even sure why recoil still exists tbh... They were really good at SEO for a long time, thats for sure, but that discouraged a lot of people from using atoms, because they would stumble upon recoil first, before jotai, when they searched for atom state management. Luckily that's no longer the case, but we can see that a lot of people still asociate atoms with recoil :(
My personal solution of state management is useReducer which is a ligthweight replacer of redux. A small 100LOC code npm module written in typescript.
(react-state-factory)npmjs.com/package/react-state-factory[dev.to/pengeszikra/simplify-your-r...]
I give a typescript helper for state handling user can define own - even complex state type - and pass to useReducer.
This type of state is not mandatory use at global statate level, and boiler plate near easy as useState.
The only problem with this approach (if any) is that the state is updated in every single action, triggering a re-computation of the component, which might lead to re-assignments of any other logic inside the component, and could potentially lead to re-renders if the devs are not using
useCallbackoruseMemoor evenmemodepending on the case.So, for this to properly work, you need the devs in your team to be aware of the pitfalls to be avoided.
Example of bad implementation:
As you can see, in this example,
OtherComponentwould be re-rendered even if valuesaorcwere not modified.Great article @nguyenhongphat0 . I recently found Jotai, and I am blown away by it's simplicity and DX. But, I am still not sure what will be the best practices for using Jotai in a big project where there is big state object to manage. I haven't got any example of such. If you have any idea on this, please write another article on this, will be of great help 🙌. Thanks!
Thank you for your compliment, I really appreciate it! I would love to share my specific experience with Jotai and tips that I found useful in another blog. Stay tuned 🤗
Sure @nguyenhongphat0 . I have been using Jotai for a while now, but only for small projects as of now. Haven't been able to decode the best practice to use it in large projects. Will be waiting for your article.
Good. Always used proxy-based MobX singletons with Typescript. Best combo
MobX is awesome, I recently use legend state as an alternative. It has everything mobx provide but has less boilerplate
Signals.
Although React is so 2018 that you might want to consider something else. Like, something that actually has been designed to work great with signals.
Learned something new, thanks for sharing!
zustand
I don't feel if you need a library in 2024. React manages state fine if you know how to use all of its hooks. Also it is well complemented with SWR or ReactQuery
try helux github.com/heluxjs/helux
About
A state engine integrates atom, signal, derive, watch and dep tracking, supports fine-grained responsive updates, it is compatible with all react like libs (including React 18)
I’m so glad to see Jotai as your top choice. I find it so simple and elegant.
I wanted to give recoil a try for a new small project, but I saw it’s still experimental and hasn’t been updated for a year. So I grabbed Jotai again. I wanted to check whether there is some newer better approach and found your article :) My soul restd assured :)
How do you solve a use case when you need to do a derived atom but need a dynamic variable (e.g. categoryId)? Creating the atom dynamically inside the component, memoizing it and using it right away seems a bit clunky. I wonder if there’s a better approach…
Typescript is an anti pattern. It is something that sounds good, but is bad. So having that in the list actually make this article lose credibility.
Redux is a good start for most people because it enforce you as developer too think more about how you structure your app and its state than the rest. It is basically event sourcing which is an extreme powerful design pattern.
I believe that everyone has a unique point of view and developer experience. You might prefer JavaScript over TypeScript, but I would pick TypeScript most of the time. Typing things initially took more time in my projects, but having IDE autocomplete saved me much time later (and that was just one of many TypeScript's awesomeness) 😎
TypeScript does not have types, it has annotations. And yes, it is huge difference. Types you can trust, always, annotations never. If you want types, use webassembly.
And no, TS do not save time. Type or dont type research paper some year ago showed clearly TS cause more bugs and cause longer development times.
My experience is TS really can hurt initial development time but saves a lot of it when you start adding/removing features and refactoring (usually that's at least 75% of time for a mature product). Annotations can be trusted majority of the time with a sensible config (although I do miss proper types Dart has) and the only alternative I see is JSDoc which is more verbose and has all the same drawbacks.
That is the issue. People, like yourself think annotations can be trusted. As the application and the code grows, bugs tends be introduced because the developer believe he/she can trust the all the annotations. That is what the research paper I mention for you earlier proofs. The more you trust TS, the more problems will come.
Overtime will you learn you code against an interface all the time. Some programmers learn this experience after a couple of years, some it takes 10 years - others understand it first after 20 years. But the faster you learn it, does suddenly the "typing" not make so much sense anymore. The only reason why it was invented in the first place was because of memory alignment together with CPU instructions. Not to help developers to create robust and large applications.
hmm, the only paper with a name similar to the one you mentioned is this one — and it's definitely pro-Typescript. Could you please share a link to whatever you're using as a basis for your statements, please?
arxiv.org/abs/2203.11115
Analyze the numbers a little bit and you see the problem.
First of all, thank you for the link! But I'm not sure the paper supports what you're saying, tbh:
They actually mention that one of the explanations might be Typescript being chosen for more complex projects. There's also a long section on threats to validity in the paper with some valid concerns. By the way, I'm not 100% convinced if the metrics used make a lot of sense for anything outside open source development with its very specific set of problems and behaviors (but that last one is only my personal opinion, ofc).
On "All other studies are bought by Microsoft" theory (which seems helpful to cement your "I have research behind my back - you don't" argument), paper itself mentions that it contradicts some pre-existing finding. Putting that aside, companies (like Google or Meta, for example) are using Flow / Closure compiler (that have ~ the same perks and drawbacks TS does in regards to type system) without too actively pushing them to anyone — and most of their decisions tend to be data-driven.
All in all, I honestly think it's sensible to question Typescript's usefulness (especially in the light of type anotations proposal) but it would require some better arguments.
It 100% supports what I am saying, you just lack the knowledge to understand it.
It is what developers reports and the author just forward. In other words, it is what developers generally feel, not fact. If it really were true, it should've support in lower bugs and faster development speed heavily for TS vs JS, but that is not the case. That is why you must analyze the numbers.
Having around ~10% larger codebase, several more commits in average and multiple more days to fix a bug is a lot compared to the alternative to not use it at all. So yes, understand the numbers before you speak and compare every single thing vs JS. The learning curve, the complexity, time on bugs vs features, the extra complexity, the unsafe future (it will very low chance it will be added to the ECMAScript, read the latest meetings notes in the type annotations proposal). TS is just extra risk everywhere.
Sure, or it could be reverse. But the truth is probably either. The realistic possibility is that people who love TS, use TS and people who prefer JS, use JS. And with same skill, JS wins.
PS. Do you know that large companies such as Meta and Google have enough money so they can hire really good developers? Do I need to tell you less experienced and average developers are more productive in JavaScript? Have your ever coach a bunch of junior developers? I doubt you will have the same opinion after 1 year if you did.
Heyo! Community Manager speaking — please remember to keep it friendly here!
There's no need for terse accusations like "you just lack the knowledge to understand it" or "understand the numbers before you speak" — if this is your feeling that's fine, but your tone here feels very gatekeeperly and there must be friendlier ways to word this. Disagreements are bound to arise, but remember to follow our Code of Conduct and treat folks with respect.
Let me make these 3 points and I promise this is my last message in this thread 😅:
1) if the question was whether junior developers should use Typescript for small projects, I'd 100% agree that they probably shouldn't 🙂 That's not how you framed it, though.
2) As an ex-Meta Sr Frontend dev I can vouch for people there not being smarter-than-everyone demigods (well, I sure am not 😅); to make things worse more than a few devs contributing to frontend code have very little experience with JS, TS or React (writing PHP-like Hack or Python code day to day) 🙂
3) I have several years of experience teaching HTML, CSS and JavaScript to complete beginners; I would never suggest they learn TS instead of JS, ofc. But I also taught a course on Typescript to middle/senor developers and most of them found it useful 🤷♂️
All in all, as always, "use the right tool for the right job". Small projects (especially by inexperienced teams) likely don't need TS but larger ones might.
There was nothing disrespectful in that answer. It is however disrespectful to me as person you just assume I mean any disrespect/harm by telling the truth. Would write it again if needed. And no, you have no authority to decide if something is disrepectful or not. The only thing you can do is to ban my account, but i don't give a fuck if you are so fucking disrespectful. I don't want to be part of this woke-toxic communitiy anyway.
I doubt you've ever tried TypeScript for more than a week. The reason you like Redux is also the same reason some people like TypeScript. And no, it's the opposite of what you say: Everyone I knew when TypeScript got big thought TypeScript sounded terrible. Then after using it fell in love with it. I will personally never go back. I couldn't.
The reason why TS is an anti pattern come from a management perspective. It cause more bugs and slower development speed. No benefit at all from a business point of view. All objective research papers show it, such as type or dont type paper. Only paid research from Microsoft say it is good.
You can still love it though, but just know the marketing for TS is a lie.
It prevents bugs and increases development speed. There's no need to specify "from business point of view" because that's the default point of view.
Answer honestly: Have you ever used TypeScript for more than a week on a typical application?
False. Every research that is objective (large and not paid by Microsoft) show TS is counter-productive if you aim for high producivity. All the marketing is a complete lie. TS is worst, it has no types, cause more bugs, longer learning curve, has lower development speed.
TS sucks in every way except it cause some developers find the code more readable than regular JS, but that does not mean anything if the end product is more bugs and lower producivity.
Sure, you don't agree with me, but I have research behind my back- you don't.
My personal research show TS is really helpful even at start phase of hobby project. But also help a lot, when I start transform my real world complex JS react application to TS based one, and even at phase of small amount ts code parts give a great guidance which is improve our development speed a lot.
I know until we don't familiar the use of generic in TS it is harder, but after the whole development process will be much cleaner.
Until I try TS personaly I hated, because with JS I can write code much flexibile, but at that moment I did not work with generals.
TS drawback is the use of generator functions, but correctly declared generator function type, whic can be any amount of yield pont is really crazy things, my advice when we would like to use generator function then best way to forget the TS. But who is using generator function?
How would you categorize StateAdapt?
state-adapt.github.io/react
This is the first time I heard about this library! But it looks promising with that RxJS support. Although it doesn't perfectly fit into the Reducer-based group, the way actions show up in Redux DevTools when you use StateAdapt's API hints that it uses a reducer-based approach under the hood.
Yep, it was originally implemented as a reducer within a Redux-like library.
I use Mobx when I'm working alone on a project. ❤
Hello @nguyenhongphat0 , want to discuss something about Jotai and it's using strategy. Possible to connect?