You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: