On: Designing simpler React components

[svachalek]

I wouldn't say it's addressing these concerns so much as it agrees with some of the same solutions this article suggests (immutability, pure functions) and turns them into requirements. At least until you want asynchronous actions (and you will) in which case it seems to shrug and encourage using addons with side effects.

The standard "react-redux" bindings make use of the presentation/container component pattern described here as well.

[tracker1 → svachalek]

The community seams to be using action creators combined with either redux-thunks, or redux-promise...

I have simple action creators that are simple actions, where the reducers only update state... actions creators will do anything more complex...

    export const doSomethingAsync = input => async (dispatch, getState) => {
      try {
        dispatch(updateStatus('loading'));
        var response = await client.get('...');
        dispatch(updateStatus('success', response.data));
      }catch(err){
        dispatch(updateStatus('failure', err));
      }
    }

I prefer the redux-thunks with async functions, as this lets me be more explicit and do a bit more work, if I need more status levels than loading/success/failure modes. This is a relatively simple example, and pretty close to how the defaults for redux-promise works...

There's no side-effects to having your async calls inside your action creators... Well, there's a chance that an intermediate action may be dispatched in between the loading and success, but even then, unless things are very brittle, it's easy enough to mitigate, and that's only for portions of the tree that are shared.

[tracker1 → tracker1]

Okay, it is subject to side effects, since the input from the original method call isn't the only point of intersection/input, the async call is part of it...

Just the same, the exposure is still minimal, and easily testable.

[djfm → svachalek]

> At least until you want asynchronous actions (and you will) in which case it seems to shrug and encourage using addons with side effects.

Imho there's nothing special with async actions and you don't necessarily need an addon, they're just actions arriving to the reducer later, and it can't see the difference. Your data fetching is no more async than a user clicking on a button.

[svachalek → djfm]

Well, rather than getting into a debate on what constitutes "nothing special" or "side effect", I'll let the docs explain the details.

http://redux.js.org/docs/advanced/AsyncActions.html

Note however that it does say "This function doesn’t need to be pure; it is thus allowed to have side effects, including executing asynchronous API calls."

[amackera → svachalek]

Out of curiosity, would it be possible to be able to do async actions without side effects?

[adyus → amackera]

setTimeout() ?

[danmaz74 → adyus]

Creating a timeout modifies the global state and is therefore a side effect.