3 ms·

I think this is an unfair characterization. Once you understand hooks in general, any specific hook should be quite straightforward so they can collapse into o

I think this is an unfair characterization. Once you understand hooks in general, any specific hook should be quite straightforward so they can collapse into one. Hooks are quite novel, but I don't find them to be overly complicated unless you're dealing with an already complex situation. Dispatch, actions and reducers can be collapsed into one since they rely on each other. I think this paradigm is not too dissimilar to message passing with something like RabbitMQ. Reducers are a common concept. Ducks and Actions, Epics and Sagas are just a convention. It's not required to use React or Redux. If you try to learn everything at once, of course you're going to get overwhelmed. But the same is true for almost any area of Software Engineering.

nwienert 6y ago
I think it’s totally fair. I discourage redux and all related patterns for this very reason. Well that, and I think local state is actually a good thing (and moving state out into separate files a bad thing). To me the proxy object (or proxy class) is really the best abstraction - much like valtio. Or a compiler like svelte. There’s no reason for ducks, epics, sagas, etc etc. We have a programming language already, we should use it.
- ZephyrBlu 6y ago
  It sounds like you're agreeing with me. You don't need everything up front, so listing everything is a bit disingenuous. It's the same explaining a fully kitted out backend (Routing, caching, authentication, etc) and then going "see, it's so complicated!". Well duh, it's a big and complex system. I think the issue with valtio is that there's no central store. As far as I can see, you'll end up having these proxies scattered around your codebase or you'll end up re-creating Redux and centralizing them. Also, I have ironically never heard of valtio.
  - nwienert 6y ago
    Agreeing how? By using valtio you avoid needing to know most of that list, by using redux you.. don't. Also, you can easily wrap valtio with: const createStore = (name, store) => { if (window.stores[name]) throw 'store already exists' window.stores = { ...window.stores [name]: valtio(store) } } And boom, you can see every store just like redux.

nwienert 6y ago

I think it’s totally fair. I discourage redux and all related patterns for this very reason. Well that, and I think local state is actually a good thing (and moving state out into separate files a bad thing). To me the proxy object (or proxy class) is really the best abstraction - much like valtio. Or a compiler like svelte. There’s no reason for ducks, epics, sagas, etc etc. We have a programming language already, we should use it.

ZephyrBlu 6y ago
It sounds like you're agreeing with me. You don't need everything up front, so listing everything is a bit disingenuous. It's the same explaining a fully kitted out backend (Routing, caching, authentication, etc) and then going "see, it's so complicated!". Well duh, it's a big and complex system. I think the issue with valtio is that there's no central store. As far as I can see, you'll end up having these proxies scattered around your codebase or you'll end up re-creating Redux and centralizing them. Also, I have ironically never heard of valtio.
- nwienert 6y ago
  Agreeing how? By using valtio you avoid needing to know most of that list, by using redux you.. don't. Also, you can easily wrap valtio with: const createStore = (name, store) => { if (window.stores[name]) throw 'store already exists' window.stores = { ...window.stores [name]: valtio(store) } } And boom, you can see every store just like redux.