News for hackers. Stuff that matters.
Re:Architecting UIs for Change by pests on Saturday March 23, 2019 @11:07AM (#19470736)
My determination is:

Do I want this state to survive a page reload, new browser session, or coming from a bookmark?

The value in a drop-down box in some random form? Non-global state.

The main page active tab that they were probably reading? Global state.

Scroll position? Global.

Tooltip Position? Probably not useful, non-global.

Something like a dialog or modal depends on the situation of how important it was and if the user would expect it to be there.

Re:Architecting UIs for Change by lioeters on Saturday March 23, 2019 @01:21PM (#19471328)
I agree with that logic, I think I've encountered every one of those cases.

That makes me see that there isn't a "god" object like the article calls it, that holds all of the app state. There's the root state shared throughout the app, and then each page or component can have its own encapsulated state.

Ideally I like to also keep page- or component-specific state+actions decoupled from their views, functional and testable independently - but often I start/keep them in the component class (and maybe soon hooks).

Re:Architecting UIs for Change by smoyer on Saturday March 23, 2019 @01:27PM (#19471359)
You can also apply the command pattern in some cases and store the undo redo state globally.this at the global store can be generic and the previous specific state will be part of the saved commands. (More applicable to SPAs).