Or is it sufficient to us the build in reactivity system of Vue or the other frontend frameworks like in SolidJS.
I think it is the same question like using Axios or fetch?
You don't have to axios any more in times of the fetch API and it makes your source easier to understand.
The JavaScript World gets overwhelmed with frameworks and libraries, that soon gets replaced by the next one.
The argument to use them get killed with the next one coming up from nowhere. So why using them at all and how often do you really need them to share a state between to components.
Less is more.
What do you think?
Latest comments (6)
Like always it depends on the project needs.
For example if you've a React app which is plenty of Forms, you don't even need to manage the forms with React.
HTML forms have state by default so you can just rely on web standards to handle that and you'll avoid re-renderings and so on which at the end is better most of the time.
Use React by what it's meant to do (build the UI) and handle the rest on the most convenient way, be React or any other thing.
Wow I don't think that's how that works at all. The next one isn't there to necessarily replace the last one--it's usually there to serve a slightly different need or use case. Like if I were trying to write JS, I would probably gravitate toward Redux because Redux is based off of the Elm language's state management and I'm an Elm dev, but there are lots of other good reasons to use other tools I wouldn't use.
So why use them at all? Because state management is really difficult in a large codebase.
It's not at all uncommon to share state between components. Take any page that might look different depending on whether the user is authenticated or not. The whole page might look completely different, and every part of the system has to know who is logged in and what to display and request on their behalf. That's a very common use case.
It's all good to say "less is more" but if you're doing nontrivial work on the DOM I really think you need good state management design patterns at least, and at that point you're looking at writing your own libs, so you may as well not reinvent the wheel.
I do not want to write my one, but simply use that what is already given in the frontend framework instead of adding another player to the game.
In SolidJS you have Stores in VueJS you have reacitve (V3) or observable (V2) so why using another thing, that makes it more difficult to understand.
The authors auf Pinia, the new kid on the block for VUE, notices themselfes that you already have a statemanagement in VueJS.
Another thing is I often see code that simply uses state management for every little thing, but there is only one position in the code where the state is used. So no need to have statemanagement. It is simply not shared.
It seems to me that many developers do things simply because the have seen somebody else done it in a sample or tutorial. Its this the next step from copying code from stackoverflow to do the work that has to be done?
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.