Redux Alternative(taverne.surge.sh)
taverne.surge.sh
Redux Alternative
https://taverne.surge.sh/
15 comments
Nice! Seems more "raw context" than most of the simple state management libraries I've seen so far!
I also created a library for state management including Context, the main goal as well was not to rerender everything when a fragment of a Context changes (which is IMHO the main limitation of using Context):
https://statux.dev/
I also created a library for state management including Context, the main goal as well was not to rerender everything when a fragment of a Context changes (which is IMHO the main limitation of using Context):
https://statux.dev/
const Counter = () => {
const [counter, setCounter] = useStore('counter');
const => setCounter(counter + 1);
return <button
}
// ...
const App = () => (
<Store counter={0}>
// ... App
</Store>
);
So, I didn’t get a chance to post this last night due to being rate limited, but I’ll post it today due to my conviction that Dan Abaramov is dangerous to the JavaScript community:
I appreciate the effort and technical prowess involved, but quite frankly Redux is bad design to begin with. Dan Abramov is a smart guy but does not think clearly enough to be allowed to design APIs.
Not saying MobX or the like are any better, but we need clearer heads approaching this problem with solutions that border on one-liners. We are storing some stuff in a global for Christ sakes, can’t we simplify all of this out of the reducer/observer pattern?
I’m depressed the marketplace of ideas has not jettisoned Dan Abramov’s ideas (the reducer pattern ended up in core React).
We are all better than this.
I appreciate the effort and technical prowess involved, but quite frankly Redux is bad design to begin with. Dan Abramov is a smart guy but does not think clearly enough to be allowed to design APIs.
Not saying MobX or the like are any better, but we need clearer heads approaching this problem with solutions that border on one-liners. We are storing some stuff in a global for Christ sakes, can’t we simplify all of this out of the reducer/observer pattern?
I’m depressed the marketplace of ideas has not jettisoned Dan Abramov’s ideas (the reducer pattern ended up in core React).
We are all better than this.
To me, actions is the insight in the reducer approach popular in React community. Actions and reducers force you to clearly define the logic of what can happen in a way that keeps it decoupled from the UI or some global state. When used properly, this actually helps arrive at a better and more sustainable design overall.
I’m working on a somewhat complex app and for a long time was sticking to plain useState and contexts, and lately I’m finding that moving it to a reducer (plain React, no Redux) has positive effects on architecture.
That said, the devil’s in the details—I personally think the approach is sometimes misused, including sadly certain tutorial materials. I’m reasonably new to reducers though.
I’m working on a somewhat complex app and for a long time was sticking to plain useState and contexts, and lately I’m finding that moving it to a reducer (plain React, no Redux) has positive effects on architecture.
That said, the devil’s in the details—I personally think the approach is sometimes misused, including sadly certain tutorial materials. I’m reasonably new to reducers though.
My rant is here:
https://news.ycombinator.com/item?id=26536276
https://news.ycombinator.com/item?id=26536276
Not sure that this has it quite right, but something along these lines (redux-like, but integrated with immer seems like a good idea). Perhaps it could also could also use TypeScript to cut down on "action creator" boilerplate?
Redux Toolkit is the suggested way to use redux these days and has immer built-in.
Redux Toolkit is the official Redux solution now and is what you're looking for.
I've been using pullstate as a Redux alternative, found it to be way more ergonomic. Uses immer for updates, and the move away from action-creators, actions, reducers, etc. cuts down on a huge amount of boilerplate, as well as making it more type-safe when using Typescript.
Given how often I see a "better redux" being written and stuff like redux toolkit, maybe its time to admit that the redux design is just bad?
A provider-less context-less alternative: https://github.com/pmndrs/zustand
without a provider you cannot run many instances of the same store in the same App. (that's how I can run 3 times the same App in my demo https://taverne.uralys.com/demo)
zustand inspired me a lot to create the custom hooks for La Taverne, and you can also create your {store, dispatch} to use anywhere without React (and providers)
zustand inspired me a lot to create the custom hooks for La Taverne, and you can also create your {store, dispatch} to use anywhere without React (and providers)
La Taverne is an elementary Flux implementation to manage your state.
The goal is to keep Redux original power and simplicity, removing the headaches of addons like Redux-thunks or Reselect.
The goal is to keep Redux original power and simplicity, removing the headaches of addons like Redux-thunks or Reselect.
How does La Taverne compare to Redux Toolkit which already removes a lot o boilerplate and includes redux thunk
The reducing is done with Immer so you have exactly the same mechanism than https://redux-toolkit.js.org/usage/immer-reducers
But Redux Toolkit is precisely among the reasons that led me to this new lib `La Taverne`:
Redux core has this awesome Flux basics, but it's deliberately unopinionated: you need addons and toolsets to complete your needs (Toolkit, Thunks, Reselect, Saga etc)
All of them add more setup, specific API, weight to your project...
I wanted a lighter solution to handle my Flux architecture.
La Taverne means to be standalone, providing essential Flux tools: async actions, immutable reducing, isolated external state.
But Redux Toolkit is precisely among the reasons that led me to this new lib `La Taverne`:
Redux core has this awesome Flux basics, but it's deliberately unopinionated: you need addons and toolsets to complete your needs (Toolkit, Thunks, Reselect, Saga etc)
All of them add more setup, specific API, weight to your project...
I wanted a lighter solution to handle my Flux architecture.
La Taverne means to be standalone, providing essential Flux tools: async actions, immutable reducing, isolated external state.
You can play around with a demo here https://codesandbox.io/s/galactic-context-demo-eqkrp