1. It was inadvertently removed from the documentation, but these are equivalent:
const count = counter.use()
const count = useEntity(counter)
2. As for the [state, setState] convention, think of useEntity more like useContext than useState. Then it gets simpler.
3. I would also argue that since this is "shared" state, the developer might (again, the library is not opinionated on this) choose to separate the logic of updating shared state. For this reason, I didn't see any reason to provide a setter through the hook, when you can access the setter from anywhere via something like counter.set(). Conforming to useState convention was not justified in this case, especially since useContext convention equally makes sense for shared state.
4. To suit whatever convention, you can always do something like this alongside the definition of the entity:
export const useCounter = counter.use
Thanks for your feedback.
These intro how-to comparisons don’t do redux justice because being simple to use is not the stated goal of redux. Large scale, maintainable, and traceable code is the primary goal of redux. When you allow anything to update your state with zero form of traceability, you’ll start to see the cracks in these simple designs.
Are these new state management libraries easy to use? Sure, but what happens when you have tens of thousands (even hundreds of thousands) of lines of code to deal with and then add major refactoring objectives in the pipeline?
Like others have mentioned, if you are using redux for a simple to-do app, then its design principles are probably not as valuable.
It’s like thinking about time complexity for algorithms, at a small enough N, even slow algorithms can compete, but as you increase N, some algorithms become untenable.
It’s crazy how the Redux people either always appeal to authority (‘my app is bigger than yours’) or can’t say anything more than ‘I just like it’.
And to play the rhetorical game, what happens when you have hundreds of thousands of lines of insane Redux code where you have lost all sense of the state tree and need to mentally cordon off one single piece of it to not go insane? Kind of like how libraries like this are already doing it.
So here is my challenge to you. Spec out an app that you believe can only be solved with Redux at scale (or rather, highlight the areas of the app that absolutely benefit from Redux, but please provide as detailed a spec as you can if you have the time, or care for that matter). I’d love to hear about this incredible web app.
Redux is not complex, contrary to popular belief. The core code can be written in 100 LoC.
The real downside to redux is not the boilerplate that is required to set it up or the number of concepts to learn, instead it’s how easy it is to do it incorrectly. The redux maintainers have spent the last few years not making changes to the core library, but figuring out conventions and helper libraries to make it more clear what you should (eg normalize state) and should not (put every piece of state) in your redux store.
No offense but the spec exercise seems like a waste of both of our time. No amount of talking about an app can illustrate the code organization at scale.
Which is totally fine, but not your everyday problem for the rest of us! I'm very happy to see all of these versions pop up as well.
What about this would get worse with more engineers or higher caliber engineers that Redux clearly avoids?
Basically the Flux architecture. See from 10:20:
I’m just not seeing the argument here, and I’ve been on multiple redux applications on teams of various sizes. We always seem to create layers of indirection to do the simplest possible state update.
We adopted Dan Abramov’s mental model, and my god, it was a labyrinth.
- https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...
- https://blog.isquaredsoftware.com/2017/05/idiomatic-redux-ta...
- https://medium.com/@dan_abramov/you-might-not-need-redux-be4...
Ultimately, it's about putting a deliberate separation between "what happened" in the UI and "how the state is updated", writing as much of your state update logic as pure functions, and being able to use that indirection to enable tracing state updates over time via the DevTools.
Also note that our official Redux Toolkit package is now the standard recommended way to write Redux logic, and it simplifies most of the Redux code you'll write:
https://redux.js.org/tutorials/fundamentals/part-8-modern-re...
The truth of the story was that community was desperately looking for a solution to global state to avoid prop drilling. No amount of technical virtuosity, or cop outs to a half assed flux architecture that fundamentally mimics model-view-controller or a pub/sub pattern will be satisfiable to anyone with critical thinking ability.
The kids had one job, get some global state available to the app, and they managed in their bravado to pack in ‘addons’, or in sales terms, they ‘up-sold’, that $40 hdmi cable along with your new $1600 television.
Dan packaged his extra bullshit (the reducer pattern) over to a desperate group that had nowhere else to turn for a global state solution. Celebrity and hero worship was one of the premier sins in all of this. The guy didn’t know what the fuck he was doing and no one called him out on it.
Certainly we are not going to marvel at the fact that he is a React core developer. Bad ideas are bad ideas, regardless of the current class that ordains it.
For this, I am depressed, and will continuously antagonize the Redux team for the damage they caused the entire community.
The Redux team owes a debt. Rewrite your library so that the api is 5 lines at max. Replace your conceptions, seek forgiveness for the sin, and let it rest. Until then, don’t peddle your Frankestein ever again anywhere, you all had plenty of time in the limelight and quite frankly - you weren’t good enough.
Like what is the redux-toolkit? Do you guys lack the conviction to decide what the api is or isn’t?
With all that said, if you don’t understand what I’m saying, then mapDispatchToProps or mapsTateToFuckYou, connect everything to nonsense, and I suppose in your new bullshit, createSlice to shut up already. You guys can’t write an api if your life depends on it. And I swear to god, if I hear about the stupid Ducks pattern ... I just can’t anymore.
Anyways, I’d prefer never to punch down if I can avoid it. The redux/abramov/constituents of the react community became the Zeitgeist of the Javacript community. Paragons. And no one stood up to them and behind the bullshit is a clusterfuck of shitty apps. You guys ain’t a small agenda, and I expect the fight to continue.
In the meantime, we're going to keep working to support our users. Who, based on the vast amount of feedback we've gotten over the last couple years, _are_ happy with the directions we're going.
But there is always an alternative, IMHO. If the project has a good code structure and follow equally good coding standards and review process, using simple un-opinionated/flexible libraries would not be a liability with "scale" (in terms of team/project size).
And there's one advantage of simpler approaches for growing teams: faster/easier onboarding. Let's face it, even good React/Redux developers can understand simpler code faster.
Just an alternative thought. But I completely get your point.
For example, in React the common way of using hooks is `useMyhook()` where "Myhook" is whatever you name it, like "useState", "useEffect", etc.
So I'd argue that an API that follows the conventions in a platform is simpler than one that rewrites them. In this specific situation in the first demo, I would expect to have a hook called `useCounter()` instead of `counter.use()`.
Furthermore, since we are manipulating state again the convention in React for state manipulation is to return the value and then the setter, like:
Now I understand since it's a global state we cannot give it a local initial value to avoid race conditions, so that's IMHO about as simple as you can get.I didn't do that, but I believe I got pretty close with my own React state management library https://statux.dev/: