I’m a developer at heart, and make mobile and web apps for start-ups and businesses. I'm passionate about tech, problem solving and making things that people love. Check my blog at https://casraf.dev
Less is more, sure. That goes both ways - state management tools let you sometimes write less code just to handle the boilerplate of keeping a state updated.
Take mobx for example, and think of a user store. With a state manager like mobx, you can focus on handling the logic of the class, rather than plugging ways for it to update the proper components in the tree.
You can use React.Context instead in the case of react, but as more gets added to each store, you get way more useless renders. What it comes to solve is 2 things:
Being able to share a state between different component - the user's data and class functions, for example
Preventing unnecessary renders - when the auth token in the user store changes, you don't necessarily need to re-render every component that ever loaded the user.
The thing is, it is already there and do not need another framework and often it is also not needed at all, because there is only on place where the state is used.
React is a special case I think, because it does more updated than it should. SolidJS is like React but does this better.
I’m a developer at heart, and make mobile and web apps for start-ups and businesses. I'm passionate about tech, problem solving and making things that people love. Check my blog at https://casraf.dev
Haven't used Solid so I can't really comment. But for example in Vue you still get to use VueX and run some state management. I think it's not a specific use case to a framework, unless one "solves" it internally to provide better dev experience.
React gives you context, which you can fully create a whole app with.
The question isn't what's possible - you can get away with most ways to organize your data in some way and you should be okay. The difference is what experience the devs are gonna have using it, how easy is it to understand, update and create new data stores, and how accessible the data is from different parts of your application.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Less is more, sure. That goes both ways - state management tools let you sometimes write less code just to handle the boilerplate of keeping a state updated.
Take mobx for example, and think of a user store. With a state manager like mobx, you can focus on handling the logic of the class, rather than plugging ways for it to update the proper components in the tree.
You can use React.Context instead in the case of react, but as more gets added to each store, you get way more useless renders. What it comes to solve is 2 things:
The thing is, it is already there and do not need another framework and often it is also not needed at all, because there is only on place where the state is used.
React is a special case I think, because it does more updated than it should. SolidJS is like React but does this better.
Haven't used Solid so I can't really comment. But for example in Vue you still get to use VueX and run some state management. I think it's not a specific use case to a framework, unless one "solves" it internally to provide better dev experience.
React gives you context, which you can fully create a whole app with.
The question isn't what's possible - you can get away with most ways to organize your data in some way and you should be okay. The difference is what experience the devs are gonna have using it, how easy is it to understand, update and create new data stores, and how accessible the data is from different parts of your application.