There needs to be a line between UI state and application state.
I've had similar issues with MVVM in WPF. Do you really need a observable property for "UserClickedThisSoMakeButtonGreenAndShiftThisPanelOverALittleBit" in your view model? I'm exaggerating of course, but there is a line. There is nothing wrong with UI specific code in your component.cs code-behind, same story for react.
Thanks for the link. Well, all state transition mechanics benefit from the strict, pure serializability that Redux offers.
In this case, it was a component that not only autocompletes a location, but also offered to geolocate the user (via the browser's geolocation API) and supported a few other features that meant it was several competing concerns wrapped into a single UI. Those can get hairy if you don't do a Redux-type state machine.
I’m curious what the shape of your redux state tree and component tree looked like. It sounds like you had a collection of n components, each with its own autocomplete component. Was there not an obvious parallel in the redux state tree for each of these n components?
Also, as a side note, you may want to check out recompose’s withReducer HOC, which is effectively a way to use the Redux action+reducer flow to manage the state of a single component (without the separate store, the context stuff, etc. that Redux provides):
In case you’re interested, ReasonReact also provides a reducer component as the only way to have a stateful component. The pain of “boilerplate” basically goes away in a typed language:
https://github.com/markerikson/redux-ecosystem-links/blob/ma...
That said, did the component really _need_ the autocomplete state to be stored in Redux in the first place?