the previous project is a mixture of state and redux. The logic of distinction is mostly:
- whether this state is shared by other components. For example, the role information of the logged-in user. Many components have different renderings depending on the character.
- after destroying the component, reload whether the component needs to be initialized to its last state. For example, the last query condition or result. Switch routes and then switch back hoping to still see the last data.
later, it was very confusing, simply using redux to discard all state components. Triggers use lifecycles, otherwise they are all function components.
but recently I have been thinking about a problem.
if there is a case of component nesting, such as
function Father(props){
const { a , b } = props;
return {
<div>
<A state={a}/>
<B state={b}/>
</div>
}
}
function B(props) {
const { c } = props;
return {
<div>
<C state={c} />
</div>
}
}if connect changes any part of the store on Father, such as store.b.c, it will cause other components to re-render. Will the performance be not as good as that on state? If the store.b.c exists on the state of B, then only component B should be refreshed and Father and A
should not be affected.ask the great god to solve the doubt