Agfdhyk

I'm encountering a rather strange problem with my ReactJS x Redux app that I've never seen before and am having a hard time figuring out.

In my ReactJS component I'm wiring up an action creator function that's using redux-thunk to make async calls before dispatching to a reducer using the connect() function from react-redux + the object mapDispatchToProps notation. It looks like this:

const mapStateToProps = (state) => ({

    ...state.single_pano

});



const mapDispatchToProps = {

    loadPano

};



export default connect(mapStateToProps, mapDispatchToProps)(PanoView);

For the sake of simplicity, let's say the loadPano action creator looks something like this:

export const loadPano = (id) => {

  console.log('Action creator called.');

  return async (dispatch) => {

    console.log('Dispatch function called.');

    const doc = await db.doc('/path/to/doc/'+id).get();

    dispatch({

      type: 'LOAD_ACTION',

      payload: doc

    });

  }

}

Here's where things get weird:

In my componentDidMount() lifecycle function, I'm making a call to this.props.loadPano(panoID) which works exactly as expected (both console.log() calls in the action creator are invoked, the async/await returns and the action is dispatched to the reducer).

Later, I need to call this.props.loadPano(panoID) again in the component's componentWillReceiveProps() lifecycle function because a URL parameter is changed, and some data needs to be fetched and reloaded. HOWEVER, what ends up happening this time is the action creator (loadPano) is called, but the redux-thunk dispatch function (return (dispatch) => { ... }) never gets called. I can tell this is the case because the first console.log() is called, but the second one never is never logged to the console.

Other things slighty out of the ordinary that I'm doing that might be related, but so far I've been unable to confirm any of it:

• The PanoView component makes use of shouldComponentUpdate() lifecycle method to control when the DOM is rendered.


• I'm being a little hacky / not best practice-y using a variable outside of the PanoView component's state to store an 3rd party library object that modifies the DOM directly via a DOM ref, and can't really be used properly in conjunction with ReactJS. However I believe this to be isolated, and can't see how it would be interfering with Redux / Thunk. Especially because the dispatch function fires correctly the first time.

Relevant dependencies + versions (installed via yarn):

"firebase": "^5.2.0",

"photo-sphere-viewer": "^3.4.0",

"react": "^16.4.1",

"react-dom": "^16.4.1",

"react-redux": "^5.0.7",

"react-router-dom": "^4.3.1",

"redux": "^4.0.0",

"redux-thunk": "^2.3.0"

Requested updates:

My componentWillReceiveProps lifecylce function for the PanoView component looks as follows:

componentWillReceiveProps(newProps) {

  // Pano received

  const oldPanoID = this.props.match.params.panoID;

  const newPanoID = newProps.match.params.panoID;



  if (oldPanoID !== newPanoID) {

    loadPano(newPanoID);

  }

}

It is hard (almost impossible) to guess where the problem is when we don't know anything about your code. How does your componentWillReceiveProps look like?

This is a good practice that might cause a confusion:

const mapDispatchToProps = {

    loadPano

};

Redux thunk is essentially a middleware that checks every dispatched action. If the action returns a function, then it calls the function and then it passes dispatch and state parameters to the returned function and then it also calls this function.

So my guess is:

1. In componendDidMount you are calling this.props.loadPano(id)
   


2. In componentWillReceiveProps you calling only loadPano.

The first one is store.dispatch(loadPano) and gets into the reducer. The second one is just loadPano and returns a promise. (your action creator)