imagine
imagine copied to clipboard
UI State
We need to determine how we should handle state within the UI. There is a lot of state in any GUI application, so I believe it should be split up into two main categories:
-
Application State This is the state managed by the user of the library.
-
UI State This is the state of the UI widgets. This includes whether a UI element is hovered, clicked, focused. This also includes text field state: cursor position, selected text, etc...
There are many different approaches to managing this state:
-
Functional The UI is a function of the application state. This method works well for frameworks that are built on top of an already functional UI (like web browser DOM) because the UI state is handled at a lower level. This approach is difficult for this project, because UI state like text field selections would have to be stored along side application state. This also requires the UI to be rebuilt every time state is changed (this can be optimized somewhat, but it is still extra overhead).
-
Imperative With this approach, we create a single UI tree and store handles to each UI component and update components states via those handles. Users can also subscribe to UI component events to determine when actions occur (ex. button click). This method doesn't require reconstructing the UI tree every time the state changes; however, this approach can lead to inconsistent UI states. The internal state may be updated, but the UI may not be updated to reflect that.
-
Hybrid The best approach will probably be some sort of hybrid, but I'm not sure what trade-offs to take yet.