a3673906c7
This commit implements a three-tier sidebar with subcategories. The first thing is that we've refactored the Sidebar into a holistic entity; rather than be built in pieces, it's constructed declaratively from a tree of entries, much in the same way routes are, and for much the same reason<sup>1</sup>. The AdminSidebar element only provides the list of entries to show and some of the controls necessary to show/hide the sidebar. Because the sidebar requires a rich collection of objects retrieved from the back-end, to avoid cluttering the AdminSidebar each of those sublists of TypeCreate have been isolated into their own controllers. The SidebarTypeController isn't even a strongly reactive controller; all it does is fetch the TypeCreate collection and notify the client object that the fetch has completed. The client can then call the `.entries()` method on the controller to get the sub-tree of entries for the TypeCreate object. The Sidebar has been slightly (!) refactored so that it's emphatic about what it does: it shows the brand, nav, and user sections of the sidebar. The styling has been moved to a separate file, the better to emphasize this. The SidebarItems file is where all the magic-- and a lot of ugly-- is hidden. The main purpose of the SidebarItems is to render the tree of entries passed to it. That's it. But it also has to be able to read the URL and highlight which entry is currently being shown by the router, and it has to be able to open up all the parent objects of the "current" link so that the user gets a clear sense of where they are navigationally. Most messy: the `reclick()` function intercepts clicks on anchors and, using the same logic as the router, decides if the router would *not* handle the navigation event. If the router would not, it takes on the responsibility for reaching into the currently visible table, modifying the filter and triggering a new `.fetch()`. Somewhere along the way I boyscoutted another `switch` statement or two into lookup expressions. --- <sup>1</sup> One of the reasons for this is that the Administrator Application's sidebar, routes, and command palette will all get their data from a single source of truth, and that single source will be independent of any of those. This is a step in that direction. |
||
|---|---|---|
| .. | ||
| .storybook | ||
| authentik/sources | ||
| icons | ||
| scripts | ||
| src | ||
| xliff | ||
| .babelrc | ||
| .dockerignore | ||
| .eslintignore | ||
| .eslintrc.json | ||
| .eslintrc.precommit.json | ||
| .gitignore | ||
| .prettierignore | ||
| .prettierrc.json | ||
| README.md | ||
| lit-localize.json | ||
| package-lock.json | ||
| package.json | ||
| robots.txt | ||
| rollup.config.mjs | ||
| rollup.proxy.mjs | ||
| security.txt | ||
| static.go | ||
| static_outpost.go | ||
| tsconfig.json | ||
| web-test-runner.config.mjs | ||
README.md
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.