React-redux: Is there an issue with nesting providers?

[3cooper]

I have two apps:

• A field or set of fields that can be edited in place
• A table that displays rows of data.

We want to allow the rows of data to be edited in place. The store shape for a set of fields is different than that of the report, and I'm not sure how I could combine the stores. What I have now that seems to work is nested providers. One provider wraps the table. When a cell in my table is rendered in an editable state, I wrap the field in a form. The form transforms the state from the table to a new state that that it passes to a new provider that wraps the fields. One reason for doing this is that my fields are used in other parts of my app. I am basically taking functionality for editing a few fields and rolling it into the table to update its data.

I understand combining reducers and one store per app. But I'm not sure how two combine these two apps that feel very different. Also, when data in the form's store is being updated, it seems wrong to have all the components in the table subscribe to updates to the form data when it has no effect.

Is this terrible?

Note - I'm new to react, redux, and jsx.

[gaearon]

If you use more than one store in an app (which in most cases we don’t suggest), don’t use <Provider> for nested stores. I would suggest passing store as a prop to any connected components explicitly.

[3cooper]

If I combine the stores, I worry that any update to the form data will cause all the cells to update. I have three questions.

1. If I use the connect method, when the store's data changes - does the mapStateToProps method check if any of the props given were changed before triggering the render on the component?
2. If so, can I have some props populated by mapStateToProps and some populated the standard way by the parent component?
3. And finally, will the check done because of mapStateToProps hinder updates caused by the parent passing new props to the component. Meaning if only a standard props changes, will the component still re-render?

I'm sorry for all the questions. We just started down this path and in my design I'm trying to think ahead to how everything will come together and how performance maybe impacted. Thanks for taking the time to answer and make these libraries.

[iamakulov]

If I use the connect method, when the store's data changes - does the mapStateToProps method check if any of the props given were changed before triggering the render on the component?

Yes. A connect-ed component is only re-rendered when any of the mapped props are changed.

If so, can I have some props populated by mapStateToProps and some populated the standard way by the parent component?

Sure. Both props passed from a parent and props from the connect() method are merged together into the component’s props.

And finally, will the check done because of mapStateToProps hinder updates caused by the parent passing new props to the component. Meaning if only a standard props changes, will the component still re-render?

Yes. A component re-renders when either props from connect(), props from a parent, or the component state is updated.

[gaearon]

^^^ these answers are correct, thanks @iamakulov for answering!

[orporan]

If you use more than one store in an app (which in most cases we don’t suggest), don’t use for nested stores. I would suggest passing store as a prop to any connected components explicitly.

What is the problem with nested Provider? Since all the Provider does it to set children context then when children of the inner provider will get the context from that Provider and not from the parent Provider