-
Notifications
You must be signed in to change notification settings - Fork 64
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
Implement KLiveRegion and useKLiveRegion #668
Comments
To decide/discuss(1)
|
Discussed with the team, so moving from the proposal stage. Decisions:
|
Summary
This is a proposal for a new component and an accompanying composable,
<KLiveRegion>
anduseKLiveRegion
.<KLiveRegion>
will render itself as two live regions, one with astatus
role and another with analert
role:A single
<KLiveRegion>
is supposed to be used in an app and high in the app's structure.useKLiveRegion
can be imported to multiple places in an app that can sendstatus
oralert
messages to<KLiveRegion>
viauseKLiveRegion.sendStatusMessage(<string>)
oruseKLiveRegion.sendAlertMessage(<string>)
.The documentation will contain brief guidance with relevant references guiding developers on when to use or not use live regions, and what types of information should be sent as status messages and what should be alert messages.
Background
Originally motivated by the ongoing sortable table work. Upon discussing with @radinamatic, it seems that the table will need to utilize live region in some use-cases, particularly to communicate loading/loaded states when re-fetching data when sorting is done on the backend. However, the table itself shouldn’t contain the live region as this would only add another live region to the already many regions in Kolibri. Additionally, a Kolibri audit revealed we use many live regions and we wrap whole components in them, which can lead to a number of problems.
The Value Add
Possible Tradeoffs
Related
Resources
The text was updated successfully, but these errors were encountered: