2 Commits

Author	SHA1	Message	Date
Ken Sternberg	ee58cf0c1c	web: add HTMLTagNameElementMaps to everything to activate lit analyzer (#10217) ... * 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: add more linting * A reliable test for the extra code needed in analyzer, passing shellcheck * web: re-enable custom-element-manifest and enable component checking in Typescript This commit includes a monkeypatch to allow custom-element-manifest (CEM) to work correctly again despite our rich collection of mixins, reactive controllers, symbol-oriented event handlers, and the like. With that monkeypatch in place, we can now create the CEM manifest file and then exploit it so that IDEs and the Typescript compilation pass can tell when a component is being used incorrectly; when the wrong types are being passed to it, or when a required attribute is not initialized. * Added building the manifest to the build process, rather than storing it. It is not appreciably slow. * web: the most boring PR in the universe: Add HTMLTagNameElementMap to everyhing This commit adds HTMLTagNameElementMap entries to every web component in the front end. Activating and associating the HTMLTagNamElementMap with its class has enabled [LitAnalyzer](https://github.com/runem/lit-analyzer/tree/master/packages/lit-analyzer) to reveal a *lot* of basic problems within the UI, the most popular of which is "missing import." We usually get away with it because the object being imported was already registered with the browser elsewhere, but it still surprises me that we haven't gotten any complaints over things like: ``` ./src/flow/stages/base.ts Missing import for <ak-form-static> 96: <ak-form-static no-missing-import ``` Given how early and fundamental that seems to be in our code, I'd have expected to hear _something_ about it. I have not enabled most of the possible checks because, well, there are just a ton of warnings when I do. I'd like to get in and fix those. Aside from this, I have also _removed_ `customElement` declarations from anything declared as an `abstract class`. It makes no sense to try and instantiate something that cannot, by definition, be instantiated. If the class is capable of running on its own, it's not abstract, it just needs to be overridden in child classes. Before removing the declaration I did check to make sure no other piece of code was even *trying* to instantiate it, and so far I have detected no failures. Those elements were: - elements/forms/Form.ts - element-/wizard/WizardFormPage.ts The one that blows my mind, though, is this: ``` src/elements/forms/ProxyForm.ts 6-@customElement("ak-proxy-form") 7:export abstract class ProxyForm extends Form<unknown> { ``` Which, despite being `abstract`, is somehow instantiable? ``` src/admin/outposts/ServiceConnectionListPage.ts: <ak-proxy-form src/admin/providers/ProviderListPage.ts: <ak-proxy-form src/admin/sources/SourceWizard.ts: <ak-proxy-form src/admin/sources/SourceListPage.ts: <ak-proxy-form src/admin/providers/ProviderWizard.ts: <ak-proxy-form type=${type.component}></ak-proxy-form> src/admin/stages/StageListPage.ts: <ak-proxy-form ``` I've made a note to investigate. I've started a new folder where all of my one-off tools for *how* a certain PR was run. It has a README describing what it's for, and the first tool, `add-htmlelementtagnamemaps-to-everything`, is its first entry. That tool is also documented internally. ``` Gilbert & Sullivan I've got a little list, I've got a little list, Of all the code that would never be missed, The duplicate code of cute-and-paste, The weak abstractions that lead to waste, The embedded templates-- you get the gist, There ain't none of 'em that will ever be missed, And that's why I've got them on my list! ```	2024-07-15 10:54:22 -07:00
Ken Sternberg	6792bf8876	web: package up horizontal elements into their own components (#7053) ... * web: laying the groundwork for future expansion This commit is a hodge-podge of updates and changes to the web. Functional changes: - Makefile: Fixed a bug in the `help` section that prevented the WIDTH from being accurately calculated if `help` was included rather than in-lined. - ESLint: Modified the "unused vars" rule so that variables starting with an underline are not considered by the rule. This allows for elided variables in event handlers. It's not a perfect solution-- a better one would be to use Typescript's function-specialization typing, but there are too many places where we elide or ignore some variables in a function's usage that switching over to specialization would be a huge lift. - locale: It turns out, lit-locale does its own context management. We don't need to have a context at all in this space, and that's one less listener we need to attach t othe DOM. - ModalButton: A small thing, but using `nothing` instead of "html``" allows lit better control over rendering and reduces the number of actual renders of the page. - FormGroup: Provided a means to modify the aria-label, rather than stick with the just the word "Details." Specializing this field will both help users of screen readers in the future, and will allow test suites to find specific form groups now. - RadioButton: provide a more consistent interface to the RadioButton. First, we dispatch the events to the outside world, and we set the value locally so that the current `Form.ts` continues to behave as expected. We also prevent the "button lost value" event from propagating; this presents a unified select-like interface to users of the RadioButtonGroup. The current value semantics are preserved; other clients of the RadioButton do not see a change in behavior. - EventEmitter: If the custom event detail is *not* an object, do not use the object-like semantics for forwarding it; just send it as-is. - Comments: In the course of laying the groundwork for the application wizard, I throw a LOT of comments into the code, describing APIs, interfaces, class and function signatures, to better document the behavior inside and as signposts for future work. * web: permit arrays to be sent in custom events without interpolation. * actually use assignValue or rather serializeFieldRecursive Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: package up horizontal elements into their own components. This commit introduces a number of "components." Jens has this idiom: ``` <ak-form-element-horizontal label=${msg("Name")} name="name" ?required=${true}> <input type="text" value="${ifDefined(this.instance?.name)}" class="pf-c-form-control" required /> </ak-form-element-horizontal> ``` It's a very web-oriented idiom in that it's built out of two building blocks, the "element-horizontal" descriptor, and the input object itself. This idiom is repeated a lot throughout the code. As an alternative, let's wrap everything into an inheritable interface: ``` <ak-text-input name="name" label=${msg("Name")} value="${ifDefined(this.instance?.name)} required > </ak-text-input> ``` This preserves all the information of the above, makes it much clearer what kind of interaction we're having (sometimes the `type=` information in an input is lost or easily missed), and while it does require you know that there are provided components rather than the pair of layout-behavior as in the original it also gives the developer more precision over the look and feel of the components. *Right now* these components are placed into the LightDOM, as they are in the existing source code, because the Form handler has a need to be able to "peer into" the "element-horizontal" component to find the values of the input objects. In a future revision I hope to place the burden of type/value processing onto the input objects themselves such that the form handler will need only look for the `.value` of the associated input control. Other fixes: - update the FlowSearch() such that it actually emits an input event when its value changes. - Disable the storybook shortcuts; on Chrome, at least, they get confused with simple inputs - Fix an issue with precommit to not scan any Python with ESLint! :-) * web: provide storybook stories for the components This commit provides storybook stories for the ak-horizontal-element wrappers. A few bugs were found along the way, including one rather nasty one from Radio where we were still getting the "set/unset" pair in the wrong order, so I had to knuckle down and fix the event handler properly. * web: test oauth2 provider "guinea pig" for new components I used the Oauth2 provider page as my experiment in seeing if the horizontal-element wrappers could be used instead of the raw wrappers themselves, and I wanted to make sure a test existed that asserts that filling out THAT form in the ProvidersList and ProvidersForm didn't break anything. This commit updates the WDIO tests to do just that; the test is simple, but it does exercise the `name` field of the Provider, something not needed in the Wizard because it's set automatically based on the Application name, and it even asserts that the new Provider exists in the list of available Providers when it's done. * web: making sure ESlint and Prettier are happy * "fix" lint Signed-off-by: Jens Langhammer <jens@goauthentik.io> --------- Signed-off-by: Jens Langhammer <jens@goauthentik.io> Co-authored-by: Jens Langhammer <jens@goauthentik.io>	2023-10-04 13:07:52 -07:00