A few thoughts: * For the "Show new changes" case, what you might do is maintain an object that does id->item storage of tasks, then have separate arrays of "t

A few thoughts: * For the "Show new changes" case, what you might do is maintain an object that does id->item storage of tasks, then have separate arrays of "task IDs being shown" and "task IDs that are new". The task list only cares about the "being shown" values, and in mapStateToProps, could show the "Show new changes" button if the "new tasks" size is > 0. * You can also add additional logic in your mapStateToProps, or your component's componentWillReceiveProps functions to see how things might be changing. * Per-component state in the Redux store is a topic of open exploration. I also have a list of Redux-related libraries over at https://github.com/markerikson/redux-ecosystem-links https://github.com/markerikson/redux-ecosystem-links , and the "Component State" category lists at least a dozen libs that can dynamically put per-component data into Redux. That said, it's also entirely valid to keep data in your UI component's state as well - it's up to you. Finally, if you're doing shallow-cloning and proper immutable updates to your state, that process shouldn't generally be a performance concern. Also, React Redux does a _lot_ of work to make sure that your wrapped component only updates when it absolutely has to.