9343e3495a67a782e793809aa3c78427d56f4594
3 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
| 1f2654f25f |
web: replace handmade list in Admin Overview with generator, storybook generator, fix storybook, fix bug in list's parent component (#9726)
* 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: provide a test framework
As is typical of a system where a new build engine is involved, this thing is sadly fragile. Use the
wrong import style in wdio.conf.js and it breaks; there are several notes in tsconfig.test.conf and
wdio.conf.ts to tell eslint or tsc not to complain, it's just a different build with different
criteria, the native criteria don't apply.
On the other hand, writing tests is easy and predictable. We can test behaviors at the unit and
component scale in a straightforward manner, and validate our expectations that things work the way
we believe they should.
* Rolling back a reversion.
* web: update storybook, storybook a few things, fix a few things
After examining how people like Adobe and Salesforce do things, I have updated the storybook
configuration to provide run-time configuration of light/dark mode (although right now nothing
happens), inject the correct styling into the page, and update the preview handling so that we can
see the components better. We'll see how this pans out.
I have provided stories for the AggregateCard, AggregatePromiseCard, and a new QuickActionsCard. I
also fixed a bug in AggregatePromiseCard where it would fail to report a fetch error. It will only
report that "the operation falied," but it will give the full error into the console.
**As an experiment**, I have changed the interpreter for `lint:precommit` and `build:watch` to use
[Bun](https://bun.sh/) instead of NodeJS. We have observed significant speed-ups and much better
memory management with Bun for these two operations. Those are both developer-facing operations, the
behavior of the system undur current CI/CD should not change.
And finally, I've switched the QuickActionsCard view in Admin-Overview to use the new component.
Looks the same. Reads *way* easier. :-)
* Slight revision in exception logic.
* Added a ton of documentation; made the failure message configurable.
* A few documentation changes.
* Adjusting paths to work with tests.
* add ci to test
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* linting shenanigans
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
* web: patch spotlight on the fly to fix syntax issue that blocked storybook build
This should be a temporary hack. I have an [open
issue](https://github.com/getsentry/spotlight/issues/419) and [pull
request](https://github.com/getsentry/spotlight/pull/420) with the
Spotlight people already to fix the issue.
* Somehow missed these in the merge.
* Merge missed something.
* Fix for incorrect path to patch file; fix for running patch multiple times.
* Prettier is still havin' opinions.
---------
Signed-off-by: Jens Langhammer <jens@goauthentik.io>
Co-authored-by: Jens Langhammer <jens@goauthentik.io>
|
|||
| 259537ee34 |
web: replace multi-select with dual-select for all propertyMapping invocations (#9359)
* 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: replace multi-select with dual-select for all propertyMapping invocations
All of the uses of <select> to show propertyMappings have been replaced with an invocation to a
variant of dual select that allows for dynamic production of the "selected" list. Instead of giving
a "selected" list of elements, a "selector" function is passed that can, given the elements listed
by the provider, generated the "selected" list dynamically.
This feature is required for propertyMappings because many of the propertyMappings have an alternative
"default selected" feature whereby an object with no property mappings is automatically granted some
by the `.managed` field of the property mapping. The `DualSelectPair` type is now tragically
mis-named, as it it's now a 4-tuple, the fourth being whatever object or field is necessary to
figure out what the default value might be. For example, the Oauth2PropertyMappingsSelector looks
like this:
```
export function makeOAuth2PropertyMappingsSelector(instanceMappings: string[] | undefined) {
const localMappings = instanceMappings ? new Set(instanceMappings) : undefined;
return localMappings
? ([pk, _]: DualSelectPair) => localMappings.has(pk)
: ([_0, _1, _2, scope]: DualSelectPair<ScopeMapping>) =>
scope?.managed?.startsWith("goauthentik.io/providers/oauth2/scope-") &&
scope?.managed !== "goauthentik.io/providers/oauth2/scope-offline_access";
}
```
If there are instanceMappings, we create a Set of them and just look up the pk for "is this
selected" as we generate the component.
If there is not, we look at the `scope` object itself (Oauth2PropertyMappings were called "scopes"
in the original source) and perform a token analysis.
It works well, is reasonably fast, and reasonably memory-friendly.
In the case of RAC, OAuth2, and ProxyProviders, I've also provided external definitions of the
MappingProvider and MappingSelector, so that they can be shared between the Provider and the
ApplicationWizard.
The algorithm for finding the "alternative (default) selections" was *different* between the two
instances of both Oauth and Proxy. I'm not marking this as "ready" until Jens (@BeryJu) and I can go
over why that might have been so, and decide if using a common implementation for both is the
correct thing to do.
Also, a lot of this is (still) cut-and-paste; the dual-select invocation, and the definitions of
Providers and Selectors have a bit of boilerplate that it just didn't make sense to try and abstract
away; the code is DAMP (Descriptive and Meaningful Phrases), and I can live with it. Unfortunately,
that also points to the possibility of something being off; the wrong default token, or the wrong
phrase to describe the "Available" and "Selected" columns. So this is not (yet) ready for a full
pull review.
On the other hand, if this passes muster and we're happy with it, there are 11 more places to put
DualSelect, four of which are pure cut-and-paste lookups of the PaginatedOauthSourceList, plus a
miscellany of Prompts, Sources, Stages, Roles, EventTransports and Policies.
Despite the churn, the difference between the two implementations is 438 lines removed, 231 lines
added, 121 lines new. 86 LOC deleted. Could be better. :-)
* web: make the ...Selector semantics uniform across the definition set.
* web: fix proxy property mapping default criteria
* web: restoring dropped message to user.
* Ensuring the neccessary components are imported.
* web: fix problem with 'selector' overselecting
The 'selector' feature was overselecting, preventing items from
being removed from the "selected" list if they were part of the
host object. This has the shortcoming that `default` items *must*
be in the first page of options from the server, or they probably
won't be registered. Fortunately, that's currently the case.
|
|||
| 3981b55b40 |
web: replace rollup with esbuild (#8699)
* Holding for a moment... * web: replace rollup with esbuild This commit replaces rollup with esbuild. The biggest fix was to alter the way CSS is imported into our system; esbuild delivers it to the browser as text, rather than as a bundle with metadata that, frankly, we never use. ESBuild will bundle the CSS for us just fine, and interpreting those strings *as* CSS turned out to be a small hurdle. Code has been added to AKElement and Interface to ensure that all CSS referenced by an element has been converted to a Browser CSSStyleSheet before being presented to the browser. A similar fix has been provided for the markdown imports. The biggest headache there was that the re-arrangement of our documentation broke Jen's existing parser for fixing relative links. I've provided a corresponding hack that provides the necessary detail, but since the Markdown is being presented to the browser as text, we have to provide a hint in the markdown component for where any relative links should go, and we're importing and processing the markdown at runtime. This doesn't seem to be a big performance hit. The entire build process is driven by the new build script, `build.mjs`, which starts the esbuild process as a service connected to the build script and then runs the commands sent to it as fast as possible. The biggest "hack" in it is actually the replacement for rollup's `rollup-copy-plugin`, which is clever enough I'm surprised it doesn't exist as a standalone file-copy package in its own right. I've also used a filesystem watch library to encode a "watcher" mechanism into the build script. `node build.mjs --watch` will work on MacOS; I haven't tested it elsewhere, at least not yet. `node build.mjs --proxy` does what the old rollup.proxy.js script did. The savings are substantial. It takes less than two seconds to build the whole UI, a huge savings off the older ~45-50 seconds I routinely saw on my old Mac. It's also about 9% smaller. The trade-offs appear to be small: processing the CSS as StyleSheets, and the Markdown as HTML, at run-time is a small performance hit, but I didn't notice it in amongst everything else the UI does as it starts up. Manual chunking is gone; esbuild's support for that is quite difficult to get right compared to Rollup's, although there's been a bit of yelling at ESbuild over it. Codemirror is built into its own chunk; it's just not _named_ distinctly anymore. The one thing I haven't been able to test yet is whether or not the polyfills and runtim shims work as expected on older browsers. * web: continue with performance and build fixes This commit introduces a couple of fixes enabled by esbuild and other features. 1. build-locales `build-locales` is a new NodeJS script in the `./scripts` folder that does pretty much what it says in the name: it translates Xliff files into `.ts` files. It has two DevExp advantages over the old build system. First, it will check the build times of the xlf files and their ts equivalents, and will only run the actual build-locales command if the XLF files are newer than their TS equivalents. Second, it captures the stderr output from the build-locales command and summarizes it. Instead of the thousands of lines of "this string has no translation equivalent," now it just reports the number of missed translations per locale. 2. check-spelling This is a simple wrapper around the `codespell` command, mostly just to reduce the visual clutter of `package.json`, but also to permit it to run just about anywhere without needed hard-coded paths to the dictionaries, using a fairly classic trick with git. 3. pseudolocalize and import-maps These scripts were in TypeScript, but for our purposes I've saved their constructed equivalents instead. This saves on visual clutter in the `package.json` script, and reduced the time they have to run during full builds. They're small enough I feel confident they won't need too much looking over. Also, two lint bugs in Markdown.ts have been fixed. * Removed a few lines that weren't in use. * build-locales was sufficiently complex it needed some comments. * web: formalize that horrible unixy git status checker into a proper function. * Added types for , the Markdown processor for in-line documentation. * re-add dependencies required for storybook Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix optional deps Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix relative links for docs Signed-off-by: Jens Langhammer <jens@goauthentik.io> * only build once on startup Signed-off-by: Jens Langhammer <jens@goauthentik.io> * prevent crash when build fails in watch mode, improve console output Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io> |
