News for hackers. Stuff that matters.
Re:Architecting UIs for Change by lioeters on Saturday March 23, 2019 @01:36PM (#19471391)
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.

Re:Architecting UIs for Change by pests on Sunday March 24, 2019 @08:35AM (#19475971)
I do agree for the consistent mental model.

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.

I plan on posting a blog post about the his soon.