The "store" is purely data that is on the client. What data you put in the store is up to you. It may be a mixture of domain data from the server ("what items do I have in cache"), application-specific data ("the current selected item is #42"), and UI state ("there is a modal that is visible, of type ItemEditor"). It's certainly possible to put every single bit of data in your app into Redux, but there are definitely reasons to want to keep some of it in local component state. The classic example is "a dropdown is open" - other components probably wouldn't care about that, and it's not something you'd want to persist or toggle during time-traveling. It's up to you as a developer to decide what state should live where.

There's a couple recent articles that cover this topic: https://medium.freecodecamp.com/where-do-i-belong-a-guide-to... and http://jamesknelson.com/5-types-react-application-state/ . The Redux FAQ also discusses this: http://redux.js.org/docs/FAQ.html#organizing-state-only-redu... .

The UI can be purely a function of the store state, or not; whichever makes more sense in your project. I find it useful to use transient component state (ie. setState) also, for things like you mention - selecting something or keeping track of the "isOpen" state of a dropdown. Any state which does not need to live longer than the UI itself.

> the whole "UI is just a function" paradigm kind of breaks down.

Not really, it just goes from "UI is a function of the store state" to "UI is a function of the store state AND the component's internal transient state". Since internal state should only be modified by the component itself calling setState, this doesn't really add much complexity - in fact it usually reduces app complexity by obviating the need for a complicated global state structure for storing eg. the open state of every possible dropdown on the page.