This repository has been archived on 2024-05-31. You can view files and clone it, but cannot push or open issues or pull requests.
authentik/web/.storybook/preview.ts

26 lines
720 B
TypeScript
Raw Normal View History

web: Add storybook (#5865) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * web: add storybook to test components * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. * web: add storybook The delta on this didn't make any sense; putting it back causes no behavioral changes. * web: add Storybook Fixed a typo in the package.json that prevented the TSC check from passing. * web: incorporate storybook This commit includes a number of type and definitional changes needed to make lit-analyze pass. In most cases, it was a matter of reassuring Lit that we were using the right type and the right type converter, or configuring the property such that it should never be called as an attribute. The most controversial change is adding the 'no-incompatible-type-binding' to the LIT analyzer configuration (found in `tsconfig.json`). This "routes around" lit-analyzer not doing very well understanding that some HTML objects can have generic property types, as long as the renderer is configured correctly. The 'no-missing-import: off' setting is required as lit-analyzer also does not use the tsconfig `paths` setting correctly and cannot find objects defined via aliases. It's a shame JSON can't support comments; these should be in the tsconfig.json file directly. As it is, I've started a README file that includes a section to record configuration decisions. Deleted the lingui.config file as we're not using it anymore * ignore storybook build in git 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-06-07 11:05:33 +00:00
import type { Preview } from "@storybook/web-components";
web: basic cleanup of buttons (#6107) * web: basic cleanup of buttons This commit adds Storybook features to the Authentik four-stage button. The four-stage button is used to: - trigger an action - show that the action is running - show when the action has succeeded, then reset - show when the action has failed, then reset It is used mostly for fetching data from the server. The variants are: - ak-spinner-button: The basic form takes a single property argument, `callAction` a function that returns a Promise (an asynchronous function). - ak-action-button: Takes an API request function (which are all asynchronous) and adapts it to the `callAction`. The only difference in behavior with the Spinner button is that on failure the error message will be displayed by a notification. - ak-token-copy-button: A specialized button that, on success, pushes the content of the retrieved object into the clipboard. Cleanup consisted of: - removing a lot of the in-line code from the HTML, decluttering it and making more explicit what the behaviors of each button type are on success and on failure. - Replacing the ad-hoc Promise management with Lit's own `Task` handler. The `Task` handler knows how to notify a Lit-Element of its own internal state change, making it ideal for objects like this button that need to change their appearance as a Promise'd task progresses from idle → running → (success or failure). - Providing JSDoc strings for all of the properties, slots, attributes, elements, and events. - Adding 'pointer-events: none' during the running phases of the action, to prevent the user from clicking the button multiple times and launching multiple queries. - Emitting an event for every stage of the operation: - `ak-button-click` when the button is clicked. - `ak-button-success` when the action completes. The payload is included in `Event.detail.result` - `ak-button-failure` when the action fails. The error message is included in `Event.detail.error` - `ak-button-reset` when the button completes a notification and goes back to idle **Storybook** Since the API requests for both `ak-spinner-button` and `ak-action-button` require only that a promise be returned, Storybooking them was straightforward. `ak-token-copy-button` is a special-purpose derivative with an internal functionality that can't be easily mocked (yet), so there's no Storybook for it. All of the stories provide the required asynchronous function, in this cose one that waits three seconds before emitting either a `response` or `reject` Promise. `ak-action-button`'s Story has event handler code so that pressing on the button will result in a message being written to a display block under the button. I've added a new pair of class mixins, `CustomEmitterElement` and `CustomListenerElement`. These each add an additional method to the classes they're mixed into; one provides a very easy way to emit a custom event and one provides a way to receive the custom event while sweeping all of the custom event type handling under the rug. `emitCustomEvent` replaces this: ``` JavaScript this.dispatchEvent( new CustomEvent('ak-button-click', { composed: true, bubbles: true, detail: { target: this, result: "Some result, huh?" }, }) ); ``` ... with this: ``` JavaScript this.dispatchCustomEvent('ak-button-click', { result: "Some result, huh?" }); ``` The `CustomListenerElement` handler just ensures that the handler being passed to it takes a CustomEvent, and then makes sure that any actual event passed to the handler has been type-guarded to ensure it is a custom event. **Observations** *Composition vs Inheritance, Part 1* The four-state button has three implementations. All three inherit from `BaseTaskButton`: - `spinner` - provides a default `callAction()` - `action` - provides a different name for `callAction` - overrides `onError` to display a Notification. - `token-copy` - provides a custom `callAction` - overrides `onSuccess` to copy the results to the keyboard - overrides `onError` to display a Notification, with special handling for asynchronous processing. The *results* of all of these could be handled higher up as event handlers, and the button could be just a thing that displays the states. As it is, the BaseStateToken has only one reason to change (the Promise changes its state), so I'm satisfied that this is a suitable evolution of the product, and that it does what it says it does. *Developer Ergonomics* The one thing that stands out to me time and again is just how *confusing* all of the Patternfly stuff tends to be; not because it's not logical, but because it overwhelms the human 7±2 ability to remember details like this without any imperative to memorize all of them. I would like to get them under control by marshalling them under a semantic CSS regime, but I'm blocked by some basic disconnects in the current development environment. We can't shake out the CSS as much as we'd like because there's no ESPrima equivalent for Typescript, and the smallest bundle purgeCSS is capable of making for just *one* button is about 55KB. That's a bit too much. It's a great system for getting off the ground, but long-term it needs more love than we (can) give it. * Prettier has opinions. * Removed extraneous debugging code. * Added comments to the BaseTaskButton parent class. * web: fixed two build errors (typing) in the stories. * web: prettier's got opinions * web: refactor the buttons This commit adds URL mocking to Storybook, which in turn allows us to commit a Story for ak-token-copy-button. I have confirmed that the button's algorithm for writing to the clipboard works on Safari, Chrome, and Firefox. I don't know what's up with IE. * ONE BYTE in .storybook/main blocked integration. With the repair of lit-analyze, it's time to fix the rule set to at least let us pass for the moment. * Still looking for the list of exceptions in lit-analyze that will let us pass once more. * web: repair error in EnterpriseLicenseForm This commit continues to find the right configuration for lit-analyze. During the course of this repair, I discovered a bug in the EnterpriseLicenseForm; the original usage could result in the _string_ `undefined` being passed back as a value. To handle the case where the value truly is undefined, the `ifDefined()` directive must be used in the HTML template. I have also instituted a case-by-case stylistic decision to allow the HTML, and only the HTML, to be longer that 100 characters when doing so reduces the visual "noise" of a function.
2023-07-18 15:29:42 +00:00
import "@goauthentik/common/styles/authentik.css";
web: provide a "select / select all" tool for the dual list multiselect **This commit** This commit provides the following new features for dual list multiselect: - The "available" pane, which has all of the entries that are available to be selected. Items that are already selected will remain, but they're marked with a checkmark and can neither be selected or moved. - The "selected" pane, which has *all* of the entries that have been selected. - The Pagination control, which in this case only sends an event upstream. **Plan**: The plan is to have a master control that marries the available-pane, selected-pane, select-controls, and pagination-controls into a single component that receives the list of "currently visible" available entries and keeps the list of "currently selected" entries, as well as a pass-through for the pagination value that allows it to hide the pagination control if there is only one page. A master component *above that* will provide the list of currently visible entries and, at need, read the value of the master control object for the "selected" list. That component will mostly be data-only; it's render will probably just be `<slot></slot>`; its duty will be only to map entries to string keys Lit can use, and to provide the lists we want to provide and the pagination ranges we want to show. Some judicious use of grid will allow me size the controls properly with/without the pagination control. Status and Title are going to be in the master control. A <slot> will be provided for Search, but I have no plans to integrate that into this control as of yet. There is already a planned fallback control; the multi-select experience on mobile is actually excellent, and we should exploit that appropriately.
2023-12-28 01:00:42 +00:00
// import "@goauthentik/common/styles/theme-dark.css";
web: basic cleanup of buttons (#6107) * web: basic cleanup of buttons This commit adds Storybook features to the Authentik four-stage button. The four-stage button is used to: - trigger an action - show that the action is running - show when the action has succeeded, then reset - show when the action has failed, then reset It is used mostly for fetching data from the server. The variants are: - ak-spinner-button: The basic form takes a single property argument, `callAction` a function that returns a Promise (an asynchronous function). - ak-action-button: Takes an API request function (which are all asynchronous) and adapts it to the `callAction`. The only difference in behavior with the Spinner button is that on failure the error message will be displayed by a notification. - ak-token-copy-button: A specialized button that, on success, pushes the content of the retrieved object into the clipboard. Cleanup consisted of: - removing a lot of the in-line code from the HTML, decluttering it and making more explicit what the behaviors of each button type are on success and on failure. - Replacing the ad-hoc Promise management with Lit's own `Task` handler. The `Task` handler knows how to notify a Lit-Element of its own internal state change, making it ideal for objects like this button that need to change their appearance as a Promise'd task progresses from idle → running → (success or failure). - Providing JSDoc strings for all of the properties, slots, attributes, elements, and events. - Adding 'pointer-events: none' during the running phases of the action, to prevent the user from clicking the button multiple times and launching multiple queries. - Emitting an event for every stage of the operation: - `ak-button-click` when the button is clicked. - `ak-button-success` when the action completes. The payload is included in `Event.detail.result` - `ak-button-failure` when the action fails. The error message is included in `Event.detail.error` - `ak-button-reset` when the button completes a notification and goes back to idle **Storybook** Since the API requests for both `ak-spinner-button` and `ak-action-button` require only that a promise be returned, Storybooking them was straightforward. `ak-token-copy-button` is a special-purpose derivative with an internal functionality that can't be easily mocked (yet), so there's no Storybook for it. All of the stories provide the required asynchronous function, in this cose one that waits three seconds before emitting either a `response` or `reject` Promise. `ak-action-button`'s Story has event handler code so that pressing on the button will result in a message being written to a display block under the button. I've added a new pair of class mixins, `CustomEmitterElement` and `CustomListenerElement`. These each add an additional method to the classes they're mixed into; one provides a very easy way to emit a custom event and one provides a way to receive the custom event while sweeping all of the custom event type handling under the rug. `emitCustomEvent` replaces this: ``` JavaScript this.dispatchEvent( new CustomEvent('ak-button-click', { composed: true, bubbles: true, detail: { target: this, result: "Some result, huh?" }, }) ); ``` ... with this: ``` JavaScript this.dispatchCustomEvent('ak-button-click', { result: "Some result, huh?" }); ``` The `CustomListenerElement` handler just ensures that the handler being passed to it takes a CustomEvent, and then makes sure that any actual event passed to the handler has been type-guarded to ensure it is a custom event. **Observations** *Composition vs Inheritance, Part 1* The four-state button has three implementations. All three inherit from `BaseTaskButton`: - `spinner` - provides a default `callAction()` - `action` - provides a different name for `callAction` - overrides `onError` to display a Notification. - `token-copy` - provides a custom `callAction` - overrides `onSuccess` to copy the results to the keyboard - overrides `onError` to display a Notification, with special handling for asynchronous processing. The *results* of all of these could be handled higher up as event handlers, and the button could be just a thing that displays the states. As it is, the BaseStateToken has only one reason to change (the Promise changes its state), so I'm satisfied that this is a suitable evolution of the product, and that it does what it says it does. *Developer Ergonomics* The one thing that stands out to me time and again is just how *confusing* all of the Patternfly stuff tends to be; not because it's not logical, but because it overwhelms the human 7±2 ability to remember details like this without any imperative to memorize all of them. I would like to get them under control by marshalling them under a semantic CSS regime, but I'm blocked by some basic disconnects in the current development environment. We can't shake out the CSS as much as we'd like because there's no ESPrima equivalent for Typescript, and the smallest bundle purgeCSS is capable of making for just *one* button is about 55KB. That's a bit too much. It's a great system for getting off the ground, but long-term it needs more love than we (can) give it. * Prettier has opinions. * Removed extraneous debugging code. * Added comments to the BaseTaskButton parent class. * web: fixed two build errors (typing) in the stories. * web: prettier's got opinions * web: refactor the buttons This commit adds URL mocking to Storybook, which in turn allows us to commit a Story for ak-token-copy-button. I have confirmed that the button's algorithm for writing to the clipboard works on Safari, Chrome, and Firefox. I don't know what's up with IE. * ONE BYTE in .storybook/main blocked integration. With the repair of lit-analyze, it's time to fix the rule set to at least let us pass for the moment. * Still looking for the list of exceptions in lit-analyze that will let us pass once more. * web: repair error in EnterpriseLicenseForm This commit continues to find the right configuration for lit-analyze. During the course of this repair, I discovered a bug in the EnterpriseLicenseForm; the original usage could result in the _string_ `undefined` being passed back as a value. To handle the case where the value truly is undefined, the `ifDefined()` directive must be used in the HTML template. I have also instituted a case-by-case stylistic decision to allow the HTML, and only the HTML, to be longer that 100 characters when doing so reduces the visual "noise" of a function.
2023-07-18 15:29:42 +00:00
import "@patternfly/patternfly/components/Brand/brand.css";
import "@patternfly/patternfly/components/Page/page.css";
web: Add storybook (#5865) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * web: add storybook to test components * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. * web: add storybook The delta on this didn't make any sense; putting it back causes no behavioral changes. * web: add Storybook Fixed a typo in the package.json that prevented the TSC check from passing. * web: incorporate storybook This commit includes a number of type and definitional changes needed to make lit-analyze pass. In most cases, it was a matter of reassuring Lit that we were using the right type and the right type converter, or configuring the property such that it should never be called as an attribute. The most controversial change is adding the 'no-incompatible-type-binding' to the LIT analyzer configuration (found in `tsconfig.json`). This "routes around" lit-analyzer not doing very well understanding that some HTML objects can have generic property types, as long as the renderer is configured correctly. The 'no-missing-import: off' setting is required as lit-analyzer also does not use the tsconfig `paths` setting correctly and cannot find objects defined via aliases. It's a shame JSON can't support comments; these should be in the tsconfig.json file directly. As it is, I've started a README file that includes a section to record configuration decisions. Deleted the lingui.config file as we're not using it anymore * ignore storybook build in git 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-06-07 11:05:33 +00:00
// .storybook/preview.js
web: basic cleanup of buttons (#6107) * web: basic cleanup of buttons This commit adds Storybook features to the Authentik four-stage button. The four-stage button is used to: - trigger an action - show that the action is running - show when the action has succeeded, then reset - show when the action has failed, then reset It is used mostly for fetching data from the server. The variants are: - ak-spinner-button: The basic form takes a single property argument, `callAction` a function that returns a Promise (an asynchronous function). - ak-action-button: Takes an API request function (which are all asynchronous) and adapts it to the `callAction`. The only difference in behavior with the Spinner button is that on failure the error message will be displayed by a notification. - ak-token-copy-button: A specialized button that, on success, pushes the content of the retrieved object into the clipboard. Cleanup consisted of: - removing a lot of the in-line code from the HTML, decluttering it and making more explicit what the behaviors of each button type are on success and on failure. - Replacing the ad-hoc Promise management with Lit's own `Task` handler. The `Task` handler knows how to notify a Lit-Element of its own internal state change, making it ideal for objects like this button that need to change their appearance as a Promise'd task progresses from idle → running → (success or failure). - Providing JSDoc strings for all of the properties, slots, attributes, elements, and events. - Adding 'pointer-events: none' during the running phases of the action, to prevent the user from clicking the button multiple times and launching multiple queries. - Emitting an event for every stage of the operation: - `ak-button-click` when the button is clicked. - `ak-button-success` when the action completes. The payload is included in `Event.detail.result` - `ak-button-failure` when the action fails. The error message is included in `Event.detail.error` - `ak-button-reset` when the button completes a notification and goes back to idle **Storybook** Since the API requests for both `ak-spinner-button` and `ak-action-button` require only that a promise be returned, Storybooking them was straightforward. `ak-token-copy-button` is a special-purpose derivative with an internal functionality that can't be easily mocked (yet), so there's no Storybook for it. All of the stories provide the required asynchronous function, in this cose one that waits three seconds before emitting either a `response` or `reject` Promise. `ak-action-button`'s Story has event handler code so that pressing on the button will result in a message being written to a display block under the button. I've added a new pair of class mixins, `CustomEmitterElement` and `CustomListenerElement`. These each add an additional method to the classes they're mixed into; one provides a very easy way to emit a custom event and one provides a way to receive the custom event while sweeping all of the custom event type handling under the rug. `emitCustomEvent` replaces this: ``` JavaScript this.dispatchEvent( new CustomEvent('ak-button-click', { composed: true, bubbles: true, detail: { target: this, result: "Some result, huh?" }, }) ); ``` ... with this: ``` JavaScript this.dispatchCustomEvent('ak-button-click', { result: "Some result, huh?" }); ``` The `CustomListenerElement` handler just ensures that the handler being passed to it takes a CustomEvent, and then makes sure that any actual event passed to the handler has been type-guarded to ensure it is a custom event. **Observations** *Composition vs Inheritance, Part 1* The four-state button has three implementations. All three inherit from `BaseTaskButton`: - `spinner` - provides a default `callAction()` - `action` - provides a different name for `callAction` - overrides `onError` to display a Notification. - `token-copy` - provides a custom `callAction` - overrides `onSuccess` to copy the results to the keyboard - overrides `onError` to display a Notification, with special handling for asynchronous processing. The *results* of all of these could be handled higher up as event handlers, and the button could be just a thing that displays the states. As it is, the BaseStateToken has only one reason to change (the Promise changes its state), so I'm satisfied that this is a suitable evolution of the product, and that it does what it says it does. *Developer Ergonomics* The one thing that stands out to me time and again is just how *confusing* all of the Patternfly stuff tends to be; not because it's not logical, but because it overwhelms the human 7±2 ability to remember details like this without any imperative to memorize all of them. I would like to get them under control by marshalling them under a semantic CSS regime, but I'm blocked by some basic disconnects in the current development environment. We can't shake out the CSS as much as we'd like because there's no ESPrima equivalent for Typescript, and the smallest bundle purgeCSS is capable of making for just *one* button is about 55KB. That's a bit too much. It's a great system for getting off the ground, but long-term it needs more love than we (can) give it. * Prettier has opinions. * Removed extraneous debugging code. * Added comments to the BaseTaskButton parent class. * web: fixed two build errors (typing) in the stories. * web: prettier's got opinions * web: refactor the buttons This commit adds URL mocking to Storybook, which in turn allows us to commit a Story for ak-token-copy-button. I have confirmed that the button's algorithm for writing to the clipboard works on Safari, Chrome, and Firefox. I don't know what's up with IE. * ONE BYTE in .storybook/main blocked integration. With the repair of lit-analyze, it's time to fix the rule set to at least let us pass for the moment. * Still looking for the list of exceptions in lit-analyze that will let us pass once more. * web: repair error in EnterpriseLicenseForm This commit continues to find the right configuration for lit-analyze. During the course of this repair, I discovered a bug in the EnterpriseLicenseForm; the original usage could result in the _string_ `undefined` being passed back as a value. To handle the case where the value truly is undefined, the `ifDefined()` directive must be used in the HTML template. I have also instituted a case-by-case stylistic decision to allow the HTML, and only the HTML, to be longer that 100 characters when doing so reduces the visual "noise" of a function.
2023-07-18 15:29:42 +00:00
import "@patternfly/patternfly/patternfly-base.css";
web: Add storybook (#5865) * \#\# Details web: replace lingui with lit/localize \#\# Changes This rather massive shift replaces the lingui and `t()` syntax with lit-localize, XLIFF, and the `msg()` syntax used by lit-localize. 90% of this work was mechanized; simple perl scripts found and replaced all uses of `t()` with the appropriate corresponding syntax for `msg()` and `msg(str())`. The XLIFF files were auto-generated from the PO files. They have not been audited, and they should be checked over by professional translators. The actual _strings_ have not been changed, but as this was a mechanized change there is always the possibility of mis-translation-- not by the translator, but by the script. * web: revise lit/localize: fix two installation issues. * web: revise localization TL;DR: - Replaced all of Lingui's `t()` syntax with `msg()` syntax. - Mechanically (i.e with a script) converted all of the PO files to XLIFF files - Refactored the localization code to be a bit smarter: - the function `getBestMatchLocale` takes the locale lists and a requested locale, and returns the first match of: - The locale's code exactly matches the requested locale - The locale code exactly matches the prefix of the requested locale (i.e the "en" part of "en-US") - the locale code's prefix exactly matches the prefix of the requested locale This function is passed to lit-locate's `loadLocale()`. - `activateLocale()` just calls `loadLocale()` now. - `autodetectLanguage` searches the following, and picks the first that returns a valid locale object, before passing it to `loadLocale()`: - The User's settings - A `?locale=` component found in `window.location.search` - The `window.navigator.language` field - English The `msg()` only runs when it's run. This seems obvious, but it means that you cannot cache strings at load time; they must be kept inside functions that are re-run so that the `msg()` engine can look up the strings in the preferred language of the user at that moment. You can use thunks-of-strings if you really need them that way. * Including the 'xliff-converter' in case anyone wants to review it. * The xliff-converter is tagged as 'xliff-converter', but has been deleted. \#\# Details - Resolves #5171 \#\# Changes \#\#\# New Features - Adds a "Add an Application" to the LibraryView if there are no applications and the user is an administrator. \#\#\# Breaking Changes - Adds breaking change which causes \<issue\>. \#\# Checklist - [ ] Local tests pass (`ak test authentik/`) - [ ] The code has been formatted (`make lint-fix`) If an API change has been made - [ ] The API schema has been updated (`make gen-build`) If changes to the frontend have been made - [ ] The code has been formatted (`make web`) - [ ] The translation files have been updated (`make i18n-extract`) If applicable - [ ] The documentation has been updated - [ ] The documentation has been formatted (`make website`) * web: fix redundant locales for zh suite. * web: prettier pass for locale update * web: localization moderization Changed the names of the lit-localize commands to make it clear they're part of the localization effort, and not just "build" and "extract". * web: add storybook to test components * update transifex config Signed-off-by: Jens Langhammer <jens@goauthentik.io> * fix package lock? Signed-off-by: Jens Langhammer <jens@goauthentik.io> * use build not compile Signed-off-by: Jens Langhammer <jens@goauthentik.io> * web: conversion to lit-localize The CI produced a list of problems that I hadn't caught earlier, due to a typo ("localize build" is correct, "localize compile" is not) I had left in package.json. They were minor and linty, but it was still wise to fix them. * web: replace lingui with lit/locale This commit fixes some minor linting issues that were hidden by a typo in package.json. The issues were not apparently problematic from a Javascript point of view, but they pointed to sloppy thinking in the progression of types through the system, so I cleaned them up and formalized the types from LocaleModule to AkLocale. * web: replace lingui with lit/localize One problem that has repeatedly come up is that localize's templates do not produce JavaScript that conforms with our shop style. I've replaced `build-locale` with a two-step that builds the locale *and* ensures that it conforms to the shop style via `prettier` every time. * web: replace lingui with lit-locale This commit applies the most recent bundle of translations to the new lit-locale aspect component. It also revises the algorithm for *finding* the correct locale, replacing the complex fall-back with some rather straightforward regular expressions. In the case of Chinese, the fallback comes at the end of the selection list, which may not be, er, politically valuable (since Taiwan and Hong Kong come before, being exceptions that need to be tested). If we need a different order for presentation, that'll be a future feature. * web: replace lingui with lit/locale Well, that was embarassing. * web: add storybook The delta on this didn't make any sense; putting it back causes no behavioral changes. * web: add Storybook Fixed a typo in the package.json that prevented the TSC check from passing. * web: incorporate storybook This commit includes a number of type and definitional changes needed to make lit-analyze pass. In most cases, it was a matter of reassuring Lit that we were using the right type and the right type converter, or configuring the property such that it should never be called as an attribute. The most controversial change is adding the 'no-incompatible-type-binding' to the LIT analyzer configuration (found in `tsconfig.json`). This "routes around" lit-analyzer not doing very well understanding that some HTML objects can have generic property types, as long as the renderer is configured correctly. The 'no-missing-import: off' setting is required as lit-analyzer also does not use the tsconfig `paths` setting correctly and cannot find objects defined via aliases. It's a shame JSON can't support comments; these should be in the tsconfig.json file directly. As it is, I've started a README file that includes a section to record configuration decisions. Deleted the lingui.config file as we're not using it anymore * ignore storybook build in git 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-06-07 11:05:33 +00:00
const preview: Preview = {
parameters: {
actions: { argTypesRegex: "^on[A-Z].*" },
cssUserPrefs: {
"prefers-color-scheme": "light",
},
controls: {
matchers: {
color: /(background|color)$/i,
date: /Date$/,
},
},
},
};
export default preview;