Put actions as one batch

[redux-saga]

Put actions as one batch

[Andarist]

@jimbol

No, its doesnt serve the same purpose. You might know yield all() already as yield [...arrayOfEffects]. We've added this all as we prefer keeping things explicit (all effect) rather than implicit (yielding arrays).

all is by no means tied to puts. You can use with any other effect - useful with 2 parallel calls, or forks etc.

Keep in mind that due to synchronous nature of redux-saga and single-threaded javascript if you all([put(ACTION1), put(ACTION2), put(ACTION3)]) they will get dispatched to ur store one by one, probably from the left to right, but I wouldnt count on that order as it might break in the future (it shouldnt, but u know how it is... if we change internals somehow, ordering of this might be affected). This is considered to be a parallel effect and to execute effects in it all at once and such mental model u should apply when working with this.

[yelouafi]

I think this is more related to React/React-redux than redux-saga itself.

Related to 'physical rendering' (patching the real DOM) I think there is no worry here because React will batch (or debounce) multiple renders in the next animation frame.

Now for the 'logical render' (calling the render method of components) I can't say. It depends on how React-redux is implemented. Maybe @gaearon can tell us more about this.

[gaearon]

React won't batch renders by default but you can tell it to with ReactDOM.unstable_batchedUpdates—either manually or via https://github.com/tappleby/redux-batched-subscribe.

In any case this is out of scope of Redux Saga.

[yelouafi]

React won't batch renders by default but you can tell it to

Didn't know that. I thought that animation frame debouncing was automatic

[gaearon]

It batches updates if you're inside an event handler. So for dispatches caused by a click, for example, it will be fine. But it doesn't do that in other cases such as AJAX callbacks. There are plans to implement this for all cases but there hasn't been a dedicated effort yet.

[yelouafi]

So, if we dispatch all actions inside the same (micro)-task queue, this will be fine.

[gaearon]

I'm not well versed in micro tasks in JS. I'm fairly certain React explicitly wraps its event handlers with batching but I don't think it works in other cases. Regardless you can always opt into this with the package I linked to and ReactDOM.unstable_batchedUpdates().

[yelouafi]

micro tasks (like used by promise.then) are executed withing the same event loop. Meaning even if the overall code triggered by the event handler dispatches multiples actions, We'll stay in the same event loop cycle, If React doesn't touch the DOM during this interval, no browser render will occur.

I mentioned them because redux-saga dispatches actions from Sagas using microtasks (using promises). If you look at the real-example bootstrap code you'll see I m delaying the render until the next animation frame. Otherwise, the Render will occur synchronously, and the Sagas may miss some startup events (especially the Router related events) because take effect will run only on a future microtask.

using requestAnimationFrame ensures Sagas are ready to take actions before the UI starts to fire anything. requestAnimationFrame will always be scheduled in a new macro-task, i.e. after all scheduled microtasks terminate

[satispunk]

Interesting! Didn't know about React handlers. I have noticed that there is a difference while dispatching actions in component handlers and promise callbacks

So what do you suggest guys if I have similar code? I would like that last 3 put calls will not call render each time. Shall I use batch-actions for that?

yield put(request())
        try {
            const state = getState()
            const login = state.LOGIN_VIEW.get('login')
            const password = state.LOGIN_VIEW.get('password')
            const data = {login, password}
            invalidate(data)

            const response = yield call(post, loginUrl(), data)
            yield put(success())
            yield put(user(response))
            yield put(navigate(V.USER_INFO_VIEW))
        }
        catch (error) {
            console.error(error)
            yield put(failure(error))
        }

[gaearon]

I suggest you to use redux-batched-subscribe as I said above. Alternatively you can do this: https://github.com/tshelburne/redux-batched-actions

[slorber]

@yelouafi take care with requestAnimationFrame

I've been using it in the past and we got problems with text inputs where the caret jumped. I know Om uses requestAnimationFrame and they used to wrap the default react inputs to avoid this problem. I don't know if it works better by default today.

[satispunk]

@gaearon Thx. I will try.

[yelouafi]

@slorber Didn't know that, thanks.

In the real-world example I m using it only at the startup to delay the first Render. Until Sagas has finished with registring their take actions.

[jimbol]

Does all serve the same purpose as batched-actions? I am assuming no, but perhaps you can shed light on this, @yelouafi.

[jimbol]

Thought so, thanks @Andarist!