Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UI State #1

Open
cbrewster opened this issue Dec 24, 2018 · 0 comments
Open

UI State #1

cbrewster opened this issue Dec 24, 2018 · 0 comments

Comments

@cbrewster
Copy link
Owner

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:

  1. Application State
    This is the state managed by the user of the library.

  2. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant