habsi/authentik
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

web: preserve selected list when provider updates (#9200)

Browse Source 
* web: fix esbuild issue with style sheets

Getting ESBuild, Lit, and Storybook to all agree on how to read and parse stylesheets is a serious
pain. This fix better identifies the value types (instances) being passed from various sources in
the repo to the three *different* kinds of style processors we're using (the native one, the
polyfill one, and whatever the heck Storybook does internally).

Falling back to using older CSS instantiating techniques one era at a time seems to do the trick.
It's ugly, but in the face of the aggressive styling we use to avoid Flashes of Unstyled Content
(FLoUC), it's the logic with which we're left.

In standard mode, the following warning appears on the console when running a Flow:

```
Autofocus processing was blocked because a document already has a focused element.
```

In compatibility mode, the following **error** appears on the console when running a Flow:

```
crawler-inject.js:1106 Uncaught TypeError: Failed to execute 'observe' on 'MutationObserver': parameter 1 is not of type 'Node'.
    at initDomMutationObservers (crawler-inject.js:1106:18)
    at crawler-inject.js:1114:24
    at Array.forEach (<anonymous>)
    at initDomMutationObservers (crawler-inject.js:1114:10)
    at crawler-inject.js:1549:1
initDomMutationObservers @ crawler-inject.js:1106
(anonymous) @ crawler-inject.js:1114
initDomMutationObservers @ crawler-inject.js:1114
(anonymous) @ crawler-inject.js:1549
```

Despite this error, nothing seems to be broken and flows work as anticipated.

* web: preserve selected list when provider updates

The impulse to preserve the functionality of the system given a change of provider was... admirable,
but unnecessary in this case. A premature optimization that doesn't make a difference. Observations:

1. change from the client will bring a new `selected`. But changes from the outside shouldn't happen
   once the interactive experience is "settled."
2. the client is perfectly capable of listening to the `change` event and reading the content of the
   value list for selecteds. If the client is going to change the provider, it should provide the
   most up-to-date copy of selecteds as well.
3. We set the selecteds from two locations: from the client on start-up, and from the "selected"
   pane during user interaction.  Anything more is risk.  I shouldn't have taken that risk.
This commit is contained in:
Ken Sternberg
2024-04-09 15:12:33 -07:00
committed by GitHub
parent 5139bc9a80
commit 0bfce6e29d
1 changed files with 4 additions and 8 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
web/src/elements/ak-dual-select/ak-dual-select-provider.ts
View File

@ -55,8 +55,6 @@ export class AkDualSelectProvider extends CustomListenerElement(AKElement) {
private pagination?: Pagination;
selectedMap: WeakMap<DataProvider, DualSelectPair[]> = new WeakMap();
constructor() {
super();
setTimeout(() => this.fetch(1), 0);
@ -72,16 +70,14 @@ export class AkDualSelectProvider extends CustomListenerElement(AKElement) {
willUpdate(changedProperties: PropertyValues<this>) {
if (changedProperties.has("searchDelay")) {
this.doSearch = debounce(this.doSearch.bind(this), this.searchDelay);
this.doSearch = debounce(
AkDualSelectProvider.prototype.doSearch.bind(this),
this.searchDelay,
);
}
if (changedProperties.has("provider")) {
this.pagination = undefined;
const previousProvider = changedProperties.get("provider");
if (previousProvider) {
this.selectedMap.set(previousProvider, this.selected);
this.selected = this.selectedMap.get(this.provider) ?? [];
}
this.fetch();
}
}