Redux: Where is a good place to re-fetch data in response to a state change?

[gyzerok]

Lets assume I have a list of products and a filter system for it. User clicks on a filter to add. My filters reducer knows the correct logic of adding the filter to list. But when should I send the request to the server with new filter list to get right products list? If I do it before I pass it to reducer I need to duplicate reducer logic. But if reducers come first I have to determine filter list update in the view and send one more action to get list of products based on resolved filter list.

What is the right way to handle this?

[gaearon]

If you use React,

componentWillReceiveProps(nextProps) {
  if (nextProps.filters !== this.props.filters) {
    this.props.dispatch(requestItems(nextProps.filters));
  }
}

[gyzerok]

@gaearon Thank you for such a quick reply!

It feels like now view contains logic it have not to contain. Doesn't it break SoC? Mb it's a payoff for using unidirectional data flow? What do you think about this?

[gaearon]

I don't quite agree. It's the _component_ that _wants_ the data to be fetched. It only needs to be fetched because that component wants to render it. If component wasn't mounted, this wouldn't matter. Therefore it's component's responsibility.

[gyzerok]

@gaearon Ok, can we live this open until I have a simple example? I'm face this not the first time. Guess its not only my problem. So we can add this later as a best practice.

[gaearon]

OK.

[smashercosmo]

In my app I use completely different approach. My filter triggers two actions FILTER_CHANGED and GET_PRODUCTS. And getProducts action creator fetchs new data using getState().filter as a param to server request. @gaearon what do you think about such approach?

[danharper]

^ I'm also doing that. I like it, but I also can't tell if using getState is an anti-pattern (or rather, something to use as a last resort). I'm kind of in two minds about it, need to experiment more.

Edit: Well, I call _one_ action creator, which calls two action creators (filter_changed and fetch_data)

[stooboo]

if you do (as suggested) in componentWillReceiveProps
.. and there are two 'instances' of the component
.. or you have two 'different' 'view' components for the same data ..

the 'requestItems' will be dispatched multiple times...

isn't this a problem .. or should that scenario be dealt with in the actionCreator so it 'debounces' the implementation of requestItems ?

[gaearon]

I think the action creator should be like

// Assuming redux-thunk
function requestFeed() {
  return function (dispatch, getState) {
    if (getState().feed.isFetching) {
      return;
    }

    return dispatch(fetchFeed());
  };
}

[gaearon]

In my app I use completely different approach. My filter triggers two actions FILTER_CHANGED and GET_PRODUCTS. And getProducts action creator fetchs new data using getState().filter as a param to server request. @gaearon what do you think about such approach?

This is also sensible.

[gyzerok]

Comment from @stooboo seems sensible to me.

What about some kind of 3-step actions? First you update the store with payload from the view, then you do server request based on new store state and finally you update store with the response. All in one async action. Here we just need to be able to use getState() after the 1st step. What do you think guys?

[gaearon]

I'm closing because this workflow is covered by the async example.