MapStateToProps not being called even after changing STATE in reducer.

[shivateja-madipalli]

Do you want to request a feature or report a bug?

I am retrieving data from Salesforce using JS remote Actions and populating data in React JS.

The structure of my application:

My component1.js:

import React from 'react';
const component1 = React.createClass({

  getInitialState() {
    return {
      basicData : {},
      interestData : {},
      accountingData : {},
      isLoading : true
    }
  },

  componentWillMount() {
    console.log('componentWillMount');
  },

  componentDidMount() {
    console.log('componentDidMount');
    this.props.action1();
  },

  componentWillReceiveProps(NextProps) {
    console.log('componentWillReceiveProps', NextProps);
  },

  componentWillUnmount() {
    console.log('componentWillUnmount');
  },

  render()  {
    console.log('RENDERING');
    return (
      <div>
        <p> Loading! </p>
      </div>
    )

  }

});

export default component1;

This is my container.js

import React, { Component } from 'react';
import { connect } from 'react-redux';
import RootComponent from '../components/component1.js';
import { action1 } from '../actions/actionCreators';

function mapStateToProps(globalState) {
  return {
    value1: globalState.value1,
    value2: globalState.value2
  };
}

const mapDispatchToProps = (dispatch) => {
  return {
     getData: () => {
        dispatch(getData())
    }
  }
}

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

Action creator:

export function action1() {
  return {
    type: 'RETRIEVE_REQUESTED_DATA',
    value1: getRecords()
  };
}

Reducer:

        case "RETRIEVE_REQUESTED_DATA":
          action.value1.then(function(data) {
            return testVar = { ...state, basicData: state.basicData, interestData: data, accountingData: state.basicData, isLoading: false};
          });

Though, I am returning altered state from my reducer, MapStateToProps in my container is not being invoked.

The server call returns a promise and that promise is handled in reducer here, once the data is retrieved then I am populating the data to my state.

My view to the issue,

Once data is retrieved from DB (Salesforce), state is altered thus, MapStateToProps should be invoked because it is connected to the Component with Connect.

Please shed some light.

I am very new to Redux and React not sure whether this is a issue or a usage question, pls excuse my ignorance.

[markerikson]

Yeah, this is definitely a usage question.

Also, you should absolutely not be using promises inside of a reducer. Not only does it break how reducers are supposed to behave, the return statement in that "RETRIEVE_REQUESTED_DATA" example doesn't do anything like what you want it to. You're effectively returning undefined from that reducer case.

[shivateja-madipalli]

Yeah! It was my mistake that I couldn't see it,

This is what I am doing currently,

case "RETRIEVE_REQUESTED_DATA":
return {...state, basicData: state.basicData, interestData: state.interestData, accountingData: action.jsonValueOfAccountingPage, isLoading: false};

[cubiccompass]

Does the render function use this.state or this.props for data binding?

My understanding is that mapStateToProps() should replace the need for getInitialState(), and encourage use of this.props.

[markerikson]

@cubiccompass : Those are separate things.

getInitialState is the method used to initialize local component state with the React.createClass() component definition syntax. mapStateToProps is the method that React-Redux's connect function uses to extract pieces of data from the store and pass them to a component as props. Those are not mutually exclusive.

You can have a component that renders data using props retrieved from the Redux store, props passed down by a parent component, and local component state, all at once. How you write your own render functions is up to you. Example:

const MyComponent = React.createClass({
    getInitialState : function() {
        return {
            valueFromLocalComponentState : 42
        };
    }

    render : function() {
        const {propFromReduxState, propFromParent} = this.props;
        const {valueFromLocalComponentState) = this.state;

        return (
            <div>
                <div>Redux prop: {propFromReduxState}</div>
                <div>Parent prop: {propFromParent}</div>
                <div>State value : {valueFromLocalComponentState}</div>
            </div>        
        );
    }
});

const mapState = (state) => {
    return {
        propFromReduxState : state.someValue
    };
}

export default connect(mapState)(MyComponent);

// and in some parent component in another file
<MyComponent propFromParent={123} />

[cubiccompass]

Thanks @markerikson . That's an excellent example of binding to either state or props.

Per @shivateja-madipalli's original question

MapStateToProps in my container is not being invoked

I'm curious to know if the intent of render() was to bind with state or props; and if props, might the troubleshooting benefit from removing getInitialState (?)

[markerikson]

As far as I can tell, the original example is broken because the reducer is trying to A) use a promise, and B) do a return inside that promise. Thus, returning undefined.

Also, conceptually what render() does isn't "binding", so it's probably best to avoid that terminology.

[cubiccompass]

Thanks @markerikson

Related question, what would be the impact of solely using Redux store.subscribe in every component, rather than using react-redux connect() with mapStateToProps?

componentWillMount() {
    store.subscribe(() => {
        this.setState({value: store.getState().someProperty});
    });
},

It appears to accomplish the same thing, but maps Redux state to component state, instead of props.

The import of "store" seems to work fine in this context. But using the Provider approach throws exception "Could not find store".

<Provider store={store}>
  <Application />
</Provider>
// Child components throw "Could not find store"

(note: I'm having similar issue as OP. mapStateToProps event not firing)

[jimbolla]

Every component that connected to the store like this would setState on every store state change, which would destroy performance. It would also run into issues with child components rerendering before parents, which means its state may be out of sync with its props.

[cubiccompass]

React should re-render only if the state actually changes though, correct? At least, that's the perceived benefit of virtual DOM.

mapStateToProps(state) also receives the entire state tree. No?

Is there some conditional magic in react-redux connect that improves performance?

[naw]

To be clear --- there is nothing intrinsically wrong with subscribing to the redux store directly in a component, it's just that react-redux does extra things for you that you'll have to think about for yourself if you want to subscribe manually.

[naw]

React should re-render only if the state actually changes though, correct?

No. Last time I checked, every time you call setState, React will render (i.e. generate virtual DOM and compare it to the old virtual DOM). This is true even if your state doesn't change. If the state doesn't change, the old and new virtual DOM will be the same, so React won't have to manipulate the DOM (which is good), but it still has to run the comparisons to know that. You can "help" React avoid the comparisons with careful use of setState and/or shouldComponentUpdate.

Is there some conditional magic in react-redux connect that improves performance?

Yes, it has a fairly intelligent shouldComponentUpdate that checks object identity equality on each key of the object returned by mapStateToProps. You could do something similar in your example prior to calling setState to achieve similar performance gains.

[cubiccompass]

Thanks for clarifying. So something like this could be performant:

componentWillMount: function() {
    store.subscribe(() => {
        var data = store.getState();
        if(data.someProperty != this.state.someProperty){
            this.setState({someProperty: data.someProperty});
        }
    });
},

shouldComponentUpdate: function(nextProps, nextState) {     
    return (nextState.someProperty != this.state.someProperty);
},

Understood that connect() handles a lot of this already, but in a props context.

Checking equality for objects or collections would likely need some flavor of immutable JS.

If this approach doesn't grossly violate the Redux data flow, then I'm inclined to stick with it. Mapping state-to-state seems logically easier to comprehend.

[markerikson]

No, that's the anti-pattern that was described. Or rather: connect already does that step for you, so that your real component only re-renders when the mapped data actually changes.

I'm really not clear why you're pursuing this approach.

[jimbolla]

subscribing in componentWillMount will cause memory leaks if you're doing server-side-rendering. In that case, you have to use componentDidMount, which leads to cases where you also have to do a state compare and call forceUpdate if relevant store state has changed.

If you have nested connected components, and the child depends on props from the parent that were derived from store state, you'll run into issues with your state being updated before it receives new props, which can cause you issues in either the listener function or render.