@limetech/lime-crm-building-blocks 2.0.4 → 2.2.0

package/dist/types/components/condition-tree/condition-tree.types.d.ts

@@ -0,0 +1,323 @@
+import { EventEmitter } from '../../stencil-public-runtime';
+import { IconName, MenuItem } from '@limetech/lime-elements';
+import { ComponentDescriptor, LimeWebComponentContext, LimeWebComponentPlatform } from '@limetech/lime-web-components';
+/**
+ * How a group joins the conditions inside it.
+ *
+ * - `all` — every condition must hold (`AND`)
+ * - `any` — at least one condition must hold (`OR`)
+ * - `not-all` — at least one condition must fail (`NOT AND`)
+ * - `none` — every condition must fail (`NOT OR`)
+ *
+ * The last two are the negations of the first two. Consumers whose data model
+ * expresses negation as a wrapper (`NOT[AND[…]]`, `not(all(…))`) fold that
+ * wrapper into the combinator in `describe`, and unfold it again in `group`. A
+ * consumer that would rather not expose the negated forms to its users lists
+ * only the ones it wants via `combinators`.
+ *
+ * @public
+ */
+export type ConditionTreeCombinator = 'all' | 'any' | 'not-all' | 'none';
+/**
+ * How one condition reads when it is collapsed.
+ *
+ * This is the whole vocabulary the tree itself has for a condition: a name, a
+ * value, an icon, and whether something is wrong with it. It says nothing
+ * about what the condition *means* — that is the consumer's business, and a
+ * consumer whose chips need to say more replaces the chip through
+ * `component`.
+ *
+ * @public
+ */
+export interface ConditionTreeChip {
+    /**
+     * The name of what is being tested — typically a property name, but for an
+     * opaque condition simply its title (e.g. "User is an administrator").
+     *
+     * It also becomes the heading of the editor when the condition is opened.
+     */
+    label?: string;
+    /**
+     * The value(s) tested against.
+     */
+    value?: string | string[];
+    /**
+     * The glyph shown between the label and the value.
+     */
+    icon?: IconName;
+    /**
+     * Set to `true` to mark the condition as unresolvable or malformed.
+     */
+    invalid?: boolean;
+    /**
+     * A component to draw in place of the built-in chip, for a condition whose
+     * summary needs more than the four fields above can say.
+     *
+     * The tree knows nothing about filters, operators or data types, so a
+     * consumer that wants the full `limebb-filter-chip` summary — the glyph
+     * and wording derived from a condition and a property type — names that
+     * component here and passes the rest through `props`:
+     *
+     * ```ts
+     * component: {
+     *     name: 'limebb-filter-chip',
+     *     props: { condition: 'greater-than', propertyType: 'date' },
+     * }
+     * ```
+     *
+     * The four fields above are still forwarded, and the tree's own state
+     * always wins over `props`. See {@link ConditionChip} for the contract the
+     * component is held to.
+     */
+    component?: ComponentDescriptor;
+}
+/**
+ * What the tree should draw for one of the consumer's nodes that holds others.
+ *
+ * @public
+ */
+export interface ConditionTreeGroupDescription<T> {
+    kind: 'group';
+    /**
+     * How the conditions inside the group are joined.
+     */
+    combinator: ConditionTreeCombinator;
+    /**
+     * The consumer's own nodes inside this group, in display order. They are
+     * passed straight back to `describe` one level down, so they need no
+     * translating: a group hands over what it already holds.
+     */
+    children: T[];
+    /**
+     * Problems to show on the group, for example from a validation pass.
+     */
+    issues?: string[];
+}
+/**
+ * What the tree should draw for one of the consumer's nodes that is a single
+ * condition: a chip, and the editor that opens when it is clicked.
+ *
+ * @public
+ */
+export interface ConditionTreeLeafDescription {
+    kind: 'leaf';
+    /**
+     * How the condition reads when collapsed.
+     */
+    chip: ConditionTreeChip;
+    /**
+     * The component to mount in the condition's editor popover. It is created
+     * by tag name and receives `platform`, `context` and the condition itself
+     * as `value`, alongside the `props` given here, so a consumer can hand over
+     * any editor it likes — including one supplied by a third party — without
+     * the tree knowing what it edits. See {@link ConditionEditor} for the
+     * contract that editor is held to.
+     *
+     * A leaf without an editor is not clickable.
+     */
+    editor?: ComponentDescriptor;
+    /**
+     * Whether this condition is negated.
+     *
+     * Leave it `undefined` when the condition carries its own polarity — one
+     * that tests a property can say "is not between" in its own vocabulary of
+     * conditions, and a second, outer negation there would be both redundant
+     * and ambiguous. The tree then renders no negation control.
+     *
+     * Set it — to `false` as much as to `true` — for an opaque condition that
+     * is simply true or false, with nothing inside it able to express the
+     * opposite, so that wrapping it is the only negation available. The tree
+     * then offers the control, and rebuilds the condition through
+     * `ConditionTreeAdapter.negate` when it is used.
+     */
+    negated?: boolean;
+    /**
+     * Set to `true` to open this condition's editor as soon as it appears,
+     * for example because the user just added it and it has nothing in it yet.
+     *
+     * It is acted on once per condition, so there is no need to clear it
+     * afterwards: a condition the user has closed stays closed, and the next
+     * condition to carry the flag still opens.
+     */
+    autoOpen?: boolean;
+    /**
+     * Problems to show on the condition, for example from a validation pass.
+     */
+    issues?: string[];
+}
+/**
+ * What the tree should draw for one of the consumer's nodes: either a group of
+ * others, or a single condition.
+ *
+ * @public
+ */
+export type ConditionTreeDescription<T> = ConditionTreeGroupDescription<T> | ConditionTreeLeafDescription;
+/**
+ * What the tree knows about the user's dealings with one node, handed to
+ * `describe` so a consumer does not have to keep the tally itself.
+ *
+ * @public
+ */
+export interface ConditionTreeNodeState {
+    /**
+     * Whether the user has opened this condition's editor and closed it again.
+     *
+     * The tree is the only thing that knows this — it opens the editors — so
+     * it is the tree that remembers. A consumer uses it to tell a condition
+     * nobody has reached yet from one the user saw and left as it is: the
+     * first is not at fault for being empty, the second may well be.
+     *
+     * Always `false` for a group, which has no editor to open.
+     */
+    visited: boolean;
+}
+/**
+ * How `limebb-condition-tree` reads and rebuilds a consumer's own tree.
+ *
+ * The tree holds no model of its own. It is given the consumer's tree as-is,
+ * asks this adapter what each node should look like, and — when the user
+ * changes something — hands back a tree of the same kind with the change
+ * applied. Conditions travel by identity: the tree moves the very objects it
+ * was given, and only asks for groups to be rebuilt, because only a group's
+ * combinator and children can change.
+ *
+ * Build the adapter once and hold on to it. One built inside `render()` is a
+ * new object every time, which makes the tree re-render for no reason.
+ *
+ * @public
+ */
+export interface ConditionTreeAdapter<T> {
+    /**
+     * What the tree should draw for one of the consumer's nodes.
+     *
+     * This runs for every node on every render, so it must be pure and cheap.
+     * Work that is not — resolving a property name against a repository, say —
+     * belongs in the consumer's own state, resolved once and read from here.
+     *
+     * `state` is what the tree knows about the user's dealings with this node.
+     * Most consumers ignore it; one that marks a condition the user left
+     * unfinished reads `visited` from it, rather than keeping that tally
+     * itself.
+     * @param node
+     * @param state
+     */
+    describe(node: T, state: ConditionTreeNodeState): ConditionTreeDescription<T>;
+    /**
+     * A group of the consumer's own kind, joining `children` the way
+     * `combinator` says.
+     *
+     * The tree calls this for every group along the path from the edit up to
+     * the root, so a consumer whose model wraps negation (`NOT[AND[…]]`)
+     * unfolds `not-all` and `none` back into that wrapper here.
+     *
+     * `children` is empty in one case only: the user asked for a new group
+     * while `addOptions` is set, so the tree cannot know which kind of
+     * condition to put in it and leaves that to the user. A group emptied by
+     * an edit is dropped rather than rebuilt, so it never reaches here.
+     * @param combinator
+     * @param children
+     */
+    group(combinator: ConditionTreeCombinator, children: T[]): T;
+    /**
+     * A new condition, for the user to fill in.
+     *
+     * `item` is the kind the user picked from `addOptions`, and is absent when
+     * the tree was given no options to offer: the consumer is then free to
+     * decide what a new condition is — typically a blank one, left for its
+     * editor to fill in.
+     * @param item
+     */
+    createLeaf(item?: MenuItem): T;
+    /**
+     * The same condition, negated or not.
+     *
+     * Leave it out and the tree offers no negation control, whatever a leaf
+     * description says about `negated`.
+     * @param node
+     * @param negated
+     */
+    negate?(node: T, negated: boolean): T;
+}
+/**
+ * The contract an editor mounted by `limebb-condition-tree` is held to.
+ *
+ * The tree sets all five props on the component named by
+ * `ConditionTreeLeafDescription.editor`, and listens for one event.
+ *
+ * @public
+ */
+export interface ConditionEditor<T> {
+    /**
+     * Platform service provider.
+     */
+    platform: LimeWebComponentPlatform;
+    /**
+     * Component context.
+     */
+    context: LimeWebComponentContext;
+    /**
+     * The condition being edited, in the consumer's own model.
+     */
+    value: T;
+    /**
+     * @inheritdoc
+     */
+    readonly: boolean;
+    /**
+     * @inheritdoc
+     */
+    disabled: boolean;
+    /**
+     * Emitted with the replacement condition when the user changes something.
+     *
+     * Named `conditionChange` rather than `change` on purpose: every
+     * `limel-input-field`, `limel-picker` and `limel-select` inside an editor
+     * emits a bubbling, composed `change`, and the tree would catch all of
+     * them.
+     */
+    conditionChange: EventEmitter<T>;
+}
+/**
+ * The contract a chip mounted by `limebb-condition-tree` is held to.
+ *
+ * The tree sets these props on the component named by
+ * `ConditionTreeChip.component`, and listens for two events. Anything else the
+ * chip needs comes from the descriptor's `props`, which the tree passes
+ * through untouched — except where a name below collides, and then the tree
+ * wins: a chip that stayed on screen while the tree was locked must not be the
+ * one place the lock does not reach.
+ *
+ * `limebb-filter-chip` satisfies this contract, which is why it is what the
+ * tree draws when no component is named.
+ *
+ * @public
+ */
+export interface ConditionChip extends Omit<ConditionTreeChip, 'component'> {
+    /**
+     * Platform service provider.
+     */
+    platform: LimeWebComponentPlatform;
+    /**
+     * Whether this condition's editor is the one currently open.
+     */
+    selected: boolean;
+    /**
+     * @inheritdoc
+     */
+    readonly: boolean;
+    /**
+     * @inheritdoc
+     */
+    disabled: boolean;
+    /**
+     * Whether the chip offers a control that deletes the condition. It is
+     * `false` while the tree is read-only.
+     */
+    removable: boolean;
+    /**
+     * Emitted when the user asks for the condition to be deleted. Its payload
+     * is ignored: the tree already knows which condition the chip stands for.
+     */
+    remove: EventEmitter<unknown>;
+}
+//# sourceMappingURL=condition-tree.types.d.ts.map

package/dist/types/components/condition-tree/group-node-view.d.ts

@@ -0,0 +1,30 @@
+import { FunctionalComponent } from '../../stencil-public-runtime';
+import { ConditionTreeDescription, ConditionTreeGroupDescription } from './condition-tree.types';
+import { ConditionTreePath } from './condition-tree-nodes';
+import { ConditionTreeRenderContext } from './condition-tree-view-context';
+/**
+ * Render one of the consumer's nodes, whichever kind the adapter says it is.
+ *
+ * It lives beside `GroupView` because a group is what holds nodes of either
+ * kind: the recursion is the group's, and keeping the choice here is what lets
+ * a group draw a group without two modules importing each other.
+ * @param props
+ */
+export declare const NodeView: FunctionalComponent<{
+    node: unknown;
+    description: ConditionTreeDescription<unknown>;
+    path: ConditionTreePath;
+    ctx: ConditionTreeRenderContext;
+}>;
+/**
+ * A box holding a combinator, the conditions joined by it, and the two buttons
+ * that grow it.
+ * @param props
+ */
+export declare const GroupView: FunctionalComponent<{
+    description: ConditionTreeGroupDescription<unknown>;
+    path: ConditionTreePath;
+    ctx: ConditionTreeRenderContext;
+    placeholder?: boolean;
+}>;
+//# sourceMappingURL=group-node-view.d.ts.map

package/dist/types/components/condition-tree/leaf-node-view.d.ts

@@ -0,0 +1,21 @@
+import { FunctionalComponent } from '../../stencil-public-runtime';
+import { ConditionTreeLeafDescription } from './condition-tree.types';
+import { ConditionTreePath } from './condition-tree-nodes';
+import { ConditionTreeRenderContext } from './condition-tree-view-context';
+/**
+ * What both halves of a condition need: the node itself, what to draw for it,
+ * where it sits, and the state and callbacks of the tree around it.
+ */
+interface LeafProps {
+    node: unknown;
+    description: ConditionTreeLeafDescription;
+    path: ConditionTreePath;
+    ctx: ConditionTreeRenderContext;
+}
+/**
+ * One condition: a chip that summarizes it, and the editor it opens.
+ * @param props
+ */
+export declare const LeafView: FunctionalComponent<LeafProps>;
+export {};
+//# sourceMappingURL=leaf-node-view.d.ts.map

package/dist/types/components/rule-editor/rule-editor-mode-view.d.ts

@@ -0,0 +1,22 @@
+import { FunctionalComponent } from '../../stencil-public-runtime';
+import { Translator } from '@limetech/lime-web-components';
+import { RuleEditorMode } from './rule-editor.types';
+interface ModeProps {
+    modes: RuleEditorMode[];
+    selected: RuleEditorMode;
+    disabled: boolean;
+    translator: Translator;
+    onModeChange: (mode: RuleEditorMode) => void;
+}
+/**
+ * The segmented control that picks how the rule is written.
+ *
+ * `limel-button-group` renders radio inputs in one group, so at most
+ * one mode is ever selected. None is selected when `selected` is a mode
+ * the caller does not offer — a stored condition tree under a setting
+ * that offers only the unconditional modes.
+ * @param props
+ */
+export declare const RuleModeView: FunctionalComponent<ModeProps>;
+export {};
+//# sourceMappingURL=rule-editor-mode-view.d.ts.map

package/dist/types/components/rule-editor/rule-editor-modes.d.ts

@@ -0,0 +1,43 @@
+import { Rule } from '@limetech/lime-web-components';
+import { RuleEditorMode } from './rule-editor.types';
+/**
+ * The id of the platform's "no condition" rule primitive. It reads
+ * nothing and always holds, which makes it the literal the
+ * unconditional modes are written with. Build those through
+ * {@link RULE_ALWAYS} and {@link RULE_NEVER} rather than from the id.
+ *
+ * @internal
+ */
+export declare const ALWAYS_PRIMITIVE_ID = "limetech.always";
+/**
+ * The rule that always holds.
+ *
+ * @alpha
+ */
+export declare const RULE_ALWAYS: Rule;
+/**
+ * The rule that never holds.
+ *
+ * @alpha
+ */
+export declare const RULE_NEVER: Rule;
+/**
+ * The rule a mode writes. `conditional` writes no rule of its own —
+ * its rule is whatever tree the author builds.
+ * @param mode
+ * @alpha
+ */
+export declare function ruleForMode(mode: RuleEditorMode): Rule | undefined;
+/**
+ * The mode a rule reads back as, or `undefined` when there is no rule.
+ *
+ * The match is structural: only the two sentinels read back as an
+ * unconditional mode, and everything else — a group, a ref, a negation
+ * of anything but the always primitive — reads back as `conditional`.
+ * So a rule authored elsewhere as `all(always)` is `conditional` with
+ * one condition in it, even though it holds just as unconditionally.
+ * @param rule
+ * @alpha
+ */
+export declare function ruleMode(rule: Rule | undefined): RuleEditorMode | undefined;
+//# sourceMappingURL=rule-editor-modes.d.ts.map

package/dist/types/components/rule-editor/rule-editor.d.ts

@@ -1,6 +1,7 @@
 import { EventEmitter } from '../../stencil-public-runtime';
 import { FormComponent } from '@limetech/lime-elements';
 import { ContextMap, LimeWebComponent, LimeWebComponentContext, LimeWebComponentPlatform, Rule } from '@limetech/lime-web-components';
+import { RuleEditorMode } from './rule-editor.types';
 /**
  * Tree editor for {@link Rule}.
  *
@@ -31,7 +32,17 @@ import { ContextMap, LimeWebComponent, LimeWebComponentContext, LimeWebComponent
  * default (e.g. an admin form's "no selection" context) doesn't shadow a
  * DOM-provided one.
  *
+ * Pass `modes` to offer the author a few pre-defined answers above the
+ * tree — "Never", "Always", "Conditionally" — so an
+ * unconditional state is one click instead of an empty tree they have
+ * to reason about. A mode is a way of writing a rule, not a second
+ * output: all of them end up in `value`, and `ruleForMode` builds the
+ * same rule a click does.
+ *
  * @exampleComponent limebb-example-rule-editor
+ * @exampleComponent limebb-example-rule-editor-modes
+ * @exampleComponent limebb-example-rule-editor-invalid
+ * @exampleComponent limebb-example-rule-editor-help
  *
  * @alpha
  * @private
@@ -57,6 +68,24 @@ export declare class RuleEditor implements LimeWebComponent, FormComponent<Rule
      * the saved-rule library.
      */
     availableContexts?: (keyof ContextMap)[];
+    /**
+     * The ways of writing a rule offered above the tree, in the order
+     * given. Leave it unset to offer none, and render the tree alone.
+     *
+     * Which modes make sense is the caller's to decide, because it
+     * differs per setting: a "when to show" toggle offers `always` and
+     * `conditional`, while a "when to make required" one also offers
+     * `never`. `conditional` is not forced into the list — a caller
+     * passing only the unconditional modes usually gets a plain toggle
+     * with no tree, which is a legitimate thing to want.
+     *
+     * "Usually", because the offered modes do not constrain `value`. A
+     * stored condition tree is still drawn, and the control then shows
+     * no mode as selected, because none of the offered ones describes
+     * what is stored. Hiding a rule the author cannot otherwise see
+     * would be worse than an unselected control.
+     */
+    modes?: RuleEditorMode[];
     /**
      * @inheritdoc
      */
@@ -76,6 +105,17 @@ export declare class RuleEditor implements LimeWebComponent, FormComponent<Rule
      * @inheritdoc
      */
     disabled: boolean;
+    /**
+     * Set to `true` to mark the rule as invalid, which reddens the
+     * outline and the helper text.
+     *
+     * This is the caller's verdict on the rule as a whole — typically a
+     * form reporting that the field is required and empty. It is
+     * separate from the diagnostics the editor finds itself, which mark
+     * the individual nodes they belong to and show regardless of this
+     * prop.
+     */
+    invalid: boolean;
     /**
      * @inheritdoc
      */
@@ -84,6 +124,15 @@ export declare class RuleEditor implements LimeWebComponent, FormComponent<Rule
      * @inheritdoc
      */
     helperText: string;
+    /**
+     * Contextual help for the setting as a whole, rendered as a `?`
+     * beside the label that opens a popover on click. Markdown.
+     *
+     * For what a rule *is* rather than what this one is for — the
+     * helper text is the shorter, always-legible answer, and the two
+     * are meant to be used together rather than instead of each other.
+     */
+    help?: string;
     /**
      * Emitted when the rule tree is mutated. Detail is the new rule, or
      * `undefined` when the user has cleared the editor to an empty root
@@ -94,13 +143,35 @@ export declare class RuleEditor implements LimeWebComponent, FormComponent<Rule
     private resolvedContext?;
     private issues;
     private openChipPath;
+    /**
+     * The mode the author last clicked, held until `value` reads back
+     * as it.
+     *
+     * A purely derived mode cannot express one case: `conditional` with
+     * nothing to restore emits no rule, so the derivation would fall
+     * back to the first offered mode and snap the control away from
+     * what the author just clicked.
+     */
+    private modeOverride;
     private focusOnOpen;
     private metadataById;
     private allPrimitiveOptions;
     private availablePrimitiveOptions;
     private reachableSlots;
+    /**
+     * The conditional rule the author had when they switched to an
+     * unconditional mode, put back when they switch to `conditional`
+     * again.
+     *
+     * It is not emitted, so a remount loses it. That is the trade:
+     * a mis-click is forgiven without inventing a state the emitted
+     * `Rule` has no way to carry.
+     */
+    private stashedTree;
     private normalizedCache;
     private hasLoaded;
+    private readonly labelId;
+    private readonly helperTextId;
     componentWillLoad(): void;
     private rebuildFromRegistries;
     /**
@@ -114,9 +185,48 @@ export declare class RuleEditor implements LimeWebComponent, FormComponent<Rule
     protected onValueChange(): void;
     protected onAvailableContextsChange(): void;
     render(): any;
-    private renderLabel;
-    private renderHelperText;
+    private renderModes;
+    /**
+     * The condition tree, shown unless a mode other than `conditional`
+     * is selected — an unconditional rule has no conditions to show.
+     * A caller offering no modes at all gets the tree, as before.
+     */
+    private renderTree;
+    private renderHelperLine;
+    private renderHelp;
     private createRenderContext;
+    /**
+     * The mode the editor is in, or `undefined` when it offers none —
+     * then it is the plain tree editor it was before modes existed.
+     *
+     * Derived from `value`, falling back to the first offered mode for
+     * a caller who has not stored a rule yet: the control has to show
+     * something, and nothing is emitted until the author picks.
+     */
+    private get currentMode();
+    /**
+     * Write the picked mode as a rule and emit it. The tree the author
+     * had is stashed on the way out, so picking `conditional` again
+     * puts it back instead of starting from empty. An emptied tree is
+     * stashed too — restoring it is what tells the author their
+     * conditions are gone, rather than handing back the ones they
+     * removed. With nothing stashed, `conditional` emits no rule, which
+     * is how the editor already says "the author cleared this".
+     * @param mode
+     */
+    private handleModeChange;
+    /**
+     * Drop the override once `value` contradicts it, handing the mode
+     * back to the derivation — that is how a later value from the
+     * caller wins over the mode the author picked.
+     *
+     * A value that expresses no mode at all does not contradict
+     * anything: an emptied tree emits no rule, and the author is still
+     * in `conditional`. Dropping the override there would read the
+     * empty value back as the first offered mode and rewrite the
+     * setting under the author.
+     */
+    private clearReachedModeOverride;
     private handleDelete;
     private handleUpdateArgs;
     private handleReplaceNode;
@@ -146,9 +256,12 @@ export declare class RuleEditor implements LimeWebComponent, FormComponent<Rule
     /**
      * The subset of registered metadata offered for adding in the
      * palette: primitives whose `reads` aren't fully covered by the
-     * reachable slots are dropped. Filtering only the palette — not the
-     * full `allPrimitiveOptions` — keeps already-placed chips resolving
-     * to their proper title even when their read slot isn't reachable.
+     * reachable slots are dropped, and so is the always primitive —
+     * it reads nothing, so it is always covered, but an "Always" chip
+     * among a group's conditions says nothing. Filtering only the
+     * palette — not the full `allPrimitiveOptions` — keeps
+     * already-placed chips resolving to their proper title even when
+     * their read slot isn't reachable.
      */
     private availablePrimitiveMetadata;
     /**
@@ -166,6 +279,13 @@ export declare class RuleEditor implements LimeWebComponent, FormComponent<Rule
      */
     private computeReachableSlots;
     private runValidation;
+    /**
+     * Emit an edited tree. Editing the tree is only possible in
+     * `conditional`, so the edit itself records the mode: an edit that
+     * empties the tree emits no rule, and without this the empty value
+     * would read back as the first offered mode.
+     * @param next
+     */
     private emitIfChanged;
     /**
      * Wrap any non-group `value` in a top-level `all` so the editor
@@ -174,6 +294,10 @@ export declare class RuleEditor implements LimeWebComponent, FormComponent<Rule
      * `emitNormalization` will *not* push that placeholder back to the
      * caller, so an unset value stays unset until the user edits.
      *
+     * An unconditional mode is the exception: its sentinel is left
+     * exactly as it came in, because wrapping it would rewrite the
+     * shape the mode is read back from.
+     *
      * Memoized so callers that read this several times in one handler
      * see the same reference — the identity check in `emitIfChanged`
      * depends on it.

package/dist/types/components/rule-editor/rule-editor.types.d.ts

@@ -0,0 +1,16 @@
+/**
+ * A way of writing a rule.
+ *
+ * - `never` — the rule never holds
+ * - `always` — the rule always holds
+ * - `conditional` — the rule holds when the author's conditions are met
+ *
+ * The first two are one click each, which spares the author from
+ * reasoning about an empty condition tree to say something
+ * unconditional. All three end up in the same `Rule` value — a mode is
+ * a way of writing a rule, not a second output.
+ *
+ * @public
+ */
+export type RuleEditorMode = 'never' | 'always' | 'conditional';
+//# sourceMappingURL=rule-editor.types.d.ts.map