I have links to a number of useful utilities for visualizing when and why components re-rendered in the "DevTools#Component Update Monitoring" section of my Red

I have links to a number of useful utilities for visualizing when and why components re-rendered in the "DevTools#Component Update Monitoring" section of my Redux addons catalog [0]. Hopefully those help. I'm a bit curious why you say that "reselect makes it less clear when things are being re-rendered". The overall reasons shouldn't change - connected components will re-render when values from `mapState` or props from the parent component have changed by reference. Thunks are definitely the "minimum viable approach" for handling async logic in Redux, or at least the minimum _suggested_ approach (as opposed to doing async handling purely inside of a component). I agree that sagas (and observables) are a pretty big jump for most devs to make, but then again, async logic in general is more difficult to reason about. Personally, I still think most devs should use thunks until they see a need for something else (per my post "Idiomatic Redux: Thoughts on Thunks" [1]). Redux does deliberately push the question of "how do I handle async logic?" outside of its core, and leave it up to you. That's both because Redux focuses on structuring synchronous state updates, and because (per my post) Dan and Andrew wanted to give devs flexibility in what specific technique they use for handling async. [0] https://github.com/markerikson/redux-ecosystem-links/blob/master/devtools.md#component-update-monitoring https://github.com/markerikson/redux-ecosystem-links/blob/ma... [1] http://blog.isquaredsoftware.com/2017/01/idiomatic-redux-thoughts-on-thunks-sagas-abstraction-and-reusability/ http://blog.isquaredsoftware.com/2017/01/idiomatic-redux-tho...