When you first start managing state in React, you will most likely be working with local state. No libraries. No redux. And this is OKAY for very simple prototypes or projects. HOWEVER, for applications at a larger scale, you will find yourself propagating a piece of state down through the tree of components. This state propagation will pollute ever single component that's touched on the way down to the components that depend on the piece of state.

CONS:

• Maintenance - Maintaining prop assignment for every single component in the path(s) to the dependent components
• This basically means that if I change the concept name of the props that propagate that piece of state, I will have to do a search an replace.
• This is ONLY an issue if you CARE about having proper naming that is not misleading(e.g. like calling a collection of resources userData when the type of the resource is really a userSection and not a user) when you are trying to drastically change some concept in your app.
• No Re Use - we cannot re-use these components unless we're propagating the same piece of state to them. Sure we could leave it undefined, but that's dead code lying around that could have un-intended consequences.
• Mixed Concerns - all of the intermediate components that were passed the piece of state on a prop should not even know about or have access that piece of state. It's like having unintended baggage that you carry around with you.
• Testing - Can't remember why it's too hard to test? Something to do with not having pure functions

PROS(this is in comparison to redux):

• Less Abstraction
  • I don't have to try to find out what action is needed to mutate the piece of state
  • I don't have to hunt for where the piece of state is being mutated
  • I don't have to build action creators to handle the preparation and initiation of the action call to the store
• Less Work - I don't have devise and implement a reducer, action, and action creator

NOTE: Need to add something here ... . Assuming you're thinking of redux which is a flux implementation.

These are the trade-offs of local state versus a flux implementation:

• local state
  • Gain - write code faster and clearer
  • Cost - more maintenance, no re-use, mixed concerns, and harder to test
• flux
  • Gain - less maintenance, re-use, isolated concerns, and easy to test
  • Cost - write code slower along with added indirection

1. local state: small packages, projects, or prototypes
2. flux: projects that scale, re-use, testing

• Action: <NOUN>_<VERB>(i.e. TODO_ADD)
• Action Creator: <verb><Noun>(i.e. addTodo)
• Selector: get<Noun>(i.e. getTodo)

• Memoization - Using redux is great for state management so as to not pollute multiple levels of components. BUT the tricky part is that mapStateToProps function will effectively cause a re-render if you build a new prop object. So the key is to use reselect to cache the data you would like to derive.
• Pass Collection Ids - Basically if a connected List Component was re-rendered due to one Item being updated and none of the Item Components were connected to the redux store, then there would be no shallowComparison calls to stop all n items from being rendered. So either pass an id to all of the Item Components connected or perform the shallow comparison yourself. PENDING CONFIRMATION ON THIS IDEA