Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Redesigning Redux

medium.com

Post reply on HN
Print view View original

51–60 of 88 posts

Re: Redesigning Redux

#51

Post by adamsea »

danpalmer wrote: post #2

This looks nice, although in Redux's favour is a large ecosystem of libraries that will work with it. This highlights a problem I still have with the JS ecosystem, which is relatively tight coupling between libraries. Of course many of these libraries could be glued together manually without too much work, but with the rapidly changing ecosystem and APIs for interoperability between libraries, and the obscurity of so…

I have to agree. The webpack-blocks project seemed like a step in the right direction, as it lets you 'compose' a webpack config (in theory) without side effects. I recently discovered lerna and am curious about using it to put together "safe" bundles of libraries which are commonly used together. No idea if that's actually a practical approach or not - its all in the dreaming stage.

Re: Redesigning Redux

#52

Post by dvlsg »

methyl wrote: post #37
myguysi wrote: post #35

Isn’t one of the points of redux to decouple actions from reducers? How would you implement multiple reducers responding to a single action if your actions are tied to a reducer with a namespace?

This can be done using Subscriptions [1]. I have another problem with this library, which is relying on singleton pattern for communication. This way, you cannot have more than one rematch instance in one application, which can be limiting. It also makes reasoning more difficult. [1] https://github.com/rematch/rematch/blob/master/plugins/subsc...

Agreed. The singleton pattern for state is a non starter for me. Got super wary as soon as I saw `dispatch` get imported and used directly.

It's easier to get started, but you'll likely have really nasty problems later (testing, server side rendering, etc).

Re: Redesigning Redux

#53

Post by dvlsg »

eropple wrote: post #26
adrice727 wrote: post #14

Earlier quoted context omitted.

Part of the idea behind Redux is to keep components as pure as possible and limit side effects to one place, usually actions. You keep all async actions in components?

I write separate business logic into which are passed their dependencies and/or the data to operate on. If you have a defined API client, you can pass that to your business logic and let it work with the API client, but to do so means that in testing you have to mock your API client. So my business logic objects tend to work on groups of domain objects (in a functional manner, usually using ImmutableJS these days). F…

_Can_ you put actions in a proper redux store? I thought the whole point was to keep them distinctly separate.

Re: Redesigning Redux

#54

Post by adamsea »

eropple wrote: post #30
azundo wrote: post #21

Earlier quoted context omitted.

Redux is for state management - that could be your data store but many people use it manage their app's UI state as well. Dan Abramov himself has said many times that redux isn't strictly necessary and using local state is fine, but there are some benefits to having a full, serializable application state. You can capture and include it with a bug report/runtime exception for example. Having redux actions dispatched w…

> full, serializable application state Perhaps I'm dense, but you can serialize the current running state of a Promise in redux-thunk?

One approach is to write a reducer which has `isWaiting`, `error`, `finished` bools (in addition to whatever data said promise eventually modifies), or something similar, and programmatically update them in your actions/thunks. This effectively tracks the state of the promise (resolved/not resolved, error).I think the Flux "standard action" puts something similar in the action object - not sure what they do with it then.

Re: Redesigning Redux

#55

Post by thinkloop »

badestrand wrote: post #27
tomelders wrote: post #9

The strength of redux is that all your interactions with it are through functions. Redux today is far better than the Redux of yesteryear thanks to things like ReSelect, Thunks, Sagas, Higher Order Components etc. All these things augment Redux, and they can do so because of Redux's open embrace of the humble pure function. Once you commit to a config based approach, you're basically closing the door to a future you…

> The strength of redux is that all your interactions with it are through functions I think it's the other way around: The greatest weakness of Redux is that (unnecessarily) message passing instead of function calls are used. Why do a `store.dispatch({type: 'INCREMENT', value: 10})` when it could be a `store.count.increment(10)`? In basically all cases every action is handled by exactly one reducer so just let the re…

One of the original reasons for message passing is that multiple reducers can respond to the same action. There have been many libraries since the beginning that try to shrink that relationship (ex reducks), but I never understood it, my code is replete with multiple responders.

Re: Redesigning Redux

#56

Post by woah »

While Redux is great because it enforces a single source of truth, the whole thing with "actions" and "reducers" in Redux is a huge source of boilerplate. In almost every Redux project I have worked on, developers bring in some weird scheme to reduce the boilerplate load of having to come up with a bunch of events when all that anyone wants to do is call some functions.

The fact that Redux forces you to use events to modify the store is a useless complication which has spawned reams and reams of crazy libraries like redux-thunk, redux-saga, standard action formats, etc. The craziest thing yet is Ducks: https://medium.freecodecamp.org/scaling-your-redux-app-with-.... This is a pattern which tries as hard as possible to make using events not feel like using events, by tying each event intimately to its listener.

This library is a step in the right direction, but wrapping Redux seems unnecessary. Here's a similar approach in 100 LOC: https://github.com/didierfranc/react-stateful

Re: Redesigning Redux

#57

Post by SeeThruHead »

badestrand wrote: post #27
tomelders wrote: post #9

The strength of redux is that all your interactions with it are through functions. Redux today is far better than the Redux of yesteryear thanks to things like ReSelect, Thunks, Sagas, Higher Order Components etc. All these things augment Redux, and they can do so because of Redux's open embrace of the humble pure function. Once you commit to a config based approach, you're basically closing the door to a future you…

> The strength of redux is that all your interactions with it are through functions I think it's the other way around: The greatest weakness of Redux is that (unnecessarily) message passing instead of function calls are used. Why do a `store.dispatch({type: 'INCREMENT', value: 10})` when it could be a `store.count.increment(10)`? In basically all cases every action is handled by exactly one reducer so just let the re…

"In basically all cases every action is handled by exactly one reducer" this is patently false

Re: Redesigning Redux

#58

Post by eropple »

dvlsg wrote: post #53
eropple wrote: post #26

Earlier quoted context omitted.

I write separate business logic into which are passed their dependencies and/or the data to operate on. If you have a defined API client, you can pass that to your business logic and let it work with the API client, but to do so means that in testing you have to mock your API client. So my business logic objects tend to work on groups of domain objects (in a functional manner, usually using ImmutableJS these days). F…

_Can_ you put actions in a proper redux store? I thought the whole point was to keep them distinctly separate.

That's effectively what redux-thunk seems to want you to be doing: running asynchronous operations inside of its control.

That makes me super nervous.

Re: Redesigning Redux

#59

Post by eropple »

silversmith wrote: post #23
eropple wrote: post #6

I've never really understood the point of redux-thunk. But, then, I also don't use asynchronous actions in my datastore . Asynchronous actions feel, to me, that they belong at the component layer where niceties such as spinners are being rendered, and then the backing store is updated with the results of the triggered action. What drives people to put all of that into their store?

Thunk is not about storing async state in the datastore, it's more akin to multithreading in my opinion. In backend, you might spin up a thread to do expensive operation like API access, and that thread has it's own database connection, to read and persist data. With thunk, you dispatch a thunk-ed action to do expensive operation like fetching data from backend, and that action has it's own access to redux in form of…

How do you test the code being run inside the Redux store? How do you mock your API client?

Re: Redesigning Redux

#60

Post by the_gipsy »

kenforthewin wrote: post #38

Is Redux too complex? That's the central argument this article makes but I find it to be patently false. What drew me to redux was its simplicity: Abramov said from the beginning that it's not anything you can't code yourself, it just provides a thin framework around making changes to some base state object. Its main strength (to me) is that it forces developers to think about state changes as mutations rather than r…

It's too much boilerplate. In my current project, I have to describe one action 7 times:

  1. The constant var `const ACTION_NAME = ...`
  2. The constant's value `... = Symbol('ACTION_NAME')`
  3. The "action creator" function `const doAction = arg => ...` (extra creativity to add a verb here?)
  4. The action creator's return struct: `... => ({ type: ACTION_NAME, payload: arg })`
  5. The reducer switch clause `case ACTION NAME:`
  6. The container action to callback mapping `onClickThing: dispatch(doAction(42))`
  7: The jsx/component calling the callback `onClick={onClickThing}`
compare that to The Elm Architecture, from which redux is inspired AFAIK. An action only needs to be referenced in 3 places:

  1. The tag on the Msg type: `type Msg = ActionName arg | ...`
  2. The `case` pattern matcher in the update function
  3. The view sending said Msg/action
Post reply on HN