7 ms·

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 tha

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.

baddox 8y ago
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): https://github.com/acdlite/recompose/blob/master/docs/API.md#withreducer https://github.com/acdlite/recompose/blob/master/docs/API.md... 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/reasonml/reason-react/blob/master/docs/state-actions-reducer.md https://github.com/reasonml/reason-react/blob/master/docs/st...