73751e5cd9
* web: break circular dependency between AKElement & Interface.
This commit changes the way the root node of the web application shell is
discovered by child components, such that the base class shared by both
no longer results in a circular dependency between the two models.
I've run this in isolation and have seen no failures of discovery; the identity
token exists as soon as the Interface is constructed and is found by every item
on the page.
* web: fix broken typescript references
This built... and then it didn't? Anyway, the current fix is to
provide type information the AkInterface for the data that consumers
require.
* A quality of life thing: `<ak-status-label good>`
There's an idiom throughout the UI:
``` HTML
<ak-label color=${item.enabled ? PFColor.Green : PFColor.Red}>
${item.enabled ? msg("Yes") : msg("No")}
</ak-label>
```
There are two problems with this.
- Repeating the conditional multiple times is error-prone
- The color scheme doesn't communicate much.
There are uses for ak-label that aren't like this, but I'm focusing on this particular use case,
which occurs about 20 times throughout the UI.
Since it's so common, let's isolate the most common case: `<ak-status-label good />` gives you the
"good" status, and `<ak-status-label/>` gives you the "bad" status, which is the default (no
arguments to the function).
There wasn't much clarity in the system for when to use orange vs red vs grey, but looking through
the use cases, it became clear that Red meant fail/inaccessible, Orange meant "Warning, but not
blocking," and Grey just means "info: this thing is off".
So let's define that with meaning: there are three types, error, warning, and info. Which
corresponds to debugging levels, but whatever, nerds grok that stuff.
So that example at the top becomes
```<ak-status-label ?good=${item.enabled}></ak-status-label>```
... and we can now more clearly understand what that conveys.
There is some heavy tension in this case: this is an easier and quicker-to-write solution to
informing the user of a binary status in an iconic way, but the developer has to remember that it
exists.
Story provided, and changes to the existing uses of the existing idiom provided.
* Added the 'compact label' story to storybook.
|
||
|---|---|---|
| .. | ||
| .storybook | ||
| authentik/sources | ||
| icons | ||
| scripts | ||
| src | ||
| xliff | ||
| .babelrc | ||
| .dockerignore | ||
| .eslintignore | ||
| .eslintrc.json | ||
| .eslintrc.precommit.json | ||
| .gitignore | ||
| .prettierignore | ||
| .prettierrc.json | ||
| lit-localize.json | ||
| package-lock.json | ||
| package.json | ||
| README.md | ||
| robots.txt | ||
| rollup.config.mjs | ||
| rollup.proxy.mjs | ||
| security.txt | ||
| static.go | ||
| static_outpost.go | ||
| tsconfig.json | ||
| web-test-runner.config.mjs | ||
authentik WebUI
This is the default UI for the authentik server. The documentation is going to be a little sparse for awhile, but at least let's get started.
Comments
NOTE: The comments in this section are for specific changes to this repository that cannot be reliably documented any other way. For the most part, they contain comments related to custom settings in JSON files, which do not support comments.
tsconfig.json:compilerOptions.useDefineForClassFields: falseis required to make TSC use the "classic" form of field definition when compiling class definitions. Storybook does not handle the ESNext proposed definition mechanism (yet).compilerOptions.plugins.ts-lit-plugin.rules.no-unknown-tag-name: "off": required to support rapidoc, which exports its tag late.compilerOptions.plugins.ts-lit-plugin.rules.no-missing-import: "off": lit-analyzer currently does not support path aliases very well, and cannot find the definition files associated with imports using them.compilerOptions.plugins.ts-lit-plugin.rules.no-incompatible-type-binding: "warn": lit-analyzer does not support generics well when parsing a subtype ofHTMLElement. As a result, this threw too many errors to be supportable.