Certain UI elements are visible before theming plugins can finish loading. e.g. in DHC, the background color and loading spinner. In DHE everything in the login form. To improve the user experience, we are storing certain "preload" variables in localStorage and then loading them on next page load independent of the plugins. Preload variable names + default values are currently stored in ThemeModel DEFAULT_PRELOAD_DATA_VARIABLES.
There's a couple of things that don't quite feel right with the current implementation.
Variables for the login page + animation technically shouldn't be needed for DHC preload, but they are needed for DHE.
| '--dh-color-login-form-bg'
| '--dh-color-login-status-message'
| '--dh-color-login-logo-bg'
| '--dh-color-login-footer-fg'
| '--dh-color-random-area-plot-animation-fg-fill'
| '--dh-color-random-area-plot-animation-fg-stroke'
| '--dh-color-random-area-plot-animation-bg'
| '--dh-color-random-area-plot-animation-grid';
It would be nice to have DHE be responsible for these, but this will require a way for apps to provide preload variables that they need
Also, @mofojed has called out that it seems odd for component specific variables to be declared in the preload as opposed to more generic semantic variables. We should think through this one to see if there is a better approach.
Certain UI elements are visible before theming plugins can finish loading. e.g. in DHC, the background color and loading spinner. In DHE everything in the login form. To improve the user experience, we are storing certain "preload" variables in localStorage and then loading them on next page load independent of the plugins. Preload variable names + default values are currently stored in
ThemeModelDEFAULT_PRELOAD_DATA_VARIABLES.There's a couple of things that don't quite feel right with the current implementation.
Variables for the login page + animation technically shouldn't be needed for DHC preload, but they are needed for DHE.
It would be nice to have DHE be responsible for these, but this will require a way for apps to provide preload variables that they need
Also, @mofojed has called out that it seems odd for component specific variables to be declared in the preload as opposed to more generic semantic variables. We should think through this one to see if there is a better approach.