Well, at least theoretically, the way I organize state management allows me to pull in "slices" of app state/actions (or even moved into shared libs/modules), to compose a smaller subset for an API or CLI. So the latter can choose to not include any of the UI-related state.
In practice I haven't used it so much, but I like the idea of treating the UI as just another render target / consumer of app state/actions. It enables "remote control" of the app logic, makes testing simpler, and allows reuse for various interfaces like CLI, API, maybe React Native too.
I've been playing around switching web-apps and other user programs between devices on a single-ususer facing kubernetes system. Part of that relies on all state being sent to the server for distribution if a device switch happens.
I also have played around with a wrapper functions and that can bubble any callback/hook up to the data for further processing. The client no longer worries about sending actions. The server spys on client actions and performs actions on their behalf.
In practice I haven't used it so much, but I like the idea of treating the UI as just another render target / consumer of app state/actions. It enables "remote control" of the app logic, makes testing simpler, and allows reuse for various interfaces like CLI, API, maybe React Native too.