@fusion.dev/helix-core 0.2.0 → 0.4.0

package/dist/helix-form-element/helix-form-element.js

@@ -6,161 +6,27 @@ var __decorate = (this && this.__decorate) || function (decorators, target, key,
 };
 import { property, state } from 'lit/decorators.js';
 import { HelixElement } from '../helix-element/helix-element.js';
-/**
- * @summary Base for every element that participates in a form.
- *
- * @description
- * This has to be a class rather than a mixin or controller, and that is not a
- * style preference: the browser reads `formAssociated` off the constructor
- * during element upgrade, which cannot be delegated to a composed object.
- *
- * `internals` comes from `HelixElement`, which attaches it for every component.
- * `attachInternals()` throws on a second call, so there is exactly one owner.
- *
- * Deliberately small. It carries what every form participant needs and nothing
- * more; `value`, validity, and the reset and restore callbacks land when the
- * first input does, rather than being designed against components that do not
- * exist yet.
- *
- * @since 0.1.0
- * @status experimental
- * @documentation https://helix.fusion.dev/core/form-element
- */
 export class HelixFormElement extends HelixElement {
     constructor() {
         super(...arguments);
-        /**
-         * Whether the control is non-interactive.
-         *
-         * Reflected, because the styled tier selects on it, and mirrored to
-         * `aria-disabled` rather than removing the element from the accessibility
-         * tree, so a screen reader can still announce that the control exists.
-         *
-         * The mirror itself is in `willUpdate` below, here rather than in each
-         * control, because here is where `disabled` is.
-         */
         this.disabled = false;
-        /**
-         * Whether an ancestor `<fieldset disabled>` has switched this control off.
-         *
-         * The platform tells a form-associated element through `formDisabledCallback`
-         * and nothing else does, so without this a control inside a disabled fieldset
-         * stays fully typeable and announces itself as enabled.
-         *
-         * The submission half is already the platform's: measured, the fieldset's
-         * controls are absent from the form's entry list and the host matches
-         * `:disabled`, so the value never goes anywhere. What is missing without this
-         * is everything a reader can see or touch.
-         *
-         * State rather than the `disabled` property. Writing that would reflect an
-         * attribute the consumer's server markup does not have, which React reports
-         * on hydration and does not patch up, and it would also silently overwrite
-         * what the consumer set.
-         */
         this.formDisabled = false;
-        /**
-         * Name submitted with the form.
-         *
-         * **Reflected, and it is the exception to "reflect only what CSS selects
-         * on".** The platform builds a form's entry list from the `name` *content
-         * attribute*, not from the property, so a control named through the property
-         * submitted under no name at all and was silently dropped. Measured: two
-         * inputs in one form, one named by attribute and one by property, and the
-         * form carried a single entry.
-         *
-         * Safe for a React consumer, which is what the rule is protecting: React
-         * renders a custom element's props as attributes on the server, so the name
-         * is already in the markup being hydrated and reflecting it writes what is
-         * there. It is only a change to the markup when a consumer assigns it
-         * imperatively later, and nothing is hydrating by then.
-         *
-         * Here rather than on each control.
-         */
         this.name = '';
     }
-    /** Opts the element into form ownership, labels, and submission. */
     static { this.formAssociated = true; }
-    /**
-     * Whether the control is off, by its own attribute or by an ancestor.
-     *
-     * What a component should bind to rather than `disabled`, which is only the
-     * half of it the consumer wrote.
-     *
-     * @internal Read by the component itself and by nothing outside it: every
-     * call in the library is `this.isDisabled`. Public, it prints a row on
-     * twenty-four families in both tiers, forty-eight in all, on every form
-     * control's reference page.
-     *
-     * **A consumer loses nothing, which was measured rather than assumed.**
-     * `element.matches(':disabled')` answers the same question, is the platform's
-     * own, and works on a native control too. Checked in a browser across the
-     * three cases: a control disabled by its own attribute, one inside a
-     * `<fieldset>` before and after that fieldset is disabled, and one that is
-     * neither. `:disabled` agreed with `isDisabled` in every one, including the
-     * inheritance case that is the only reason this getter exists.
-     *
-     * Documented away rather than made `protected`, because a subclass in
-     * `helix/styled` binds to it and that is exactly what it is for.
-     */
     get isDisabled() {
         return this.disabled || this.formDisabled;
     }
-    /**
-     * The platform's notice that an ancestor fieldset changed.
-     *
-     * **The argument is the effective state, and taking it whole is what latched
-     * every control in the library.** The platform calls this for the element's
-     * own `disabled` as well as for a fieldset, and our own arrives here at the
-     * worst possible moment: reflecting `disabled` to the attribute happens
-     * inside Lit's `update()`, the UA fires this synchronously from that write,
-     * and a reactive write during an update is a change-in-update Lit does not
-     * re-render for. So `formDisabled` ran exactly one update behind forever.
-     *
-     * Measured on Slider, logging what `render` saw:
-     *
-     * ```
-     * set true    disabled true   formDisabled false  isDisabled true
-     * set false   disabled false  formDisabled true   isDisabled true   <- stale
-     * (no third render)
-     * ```
-     *
-     * The host came out right every time, `disabled` false, `:disabled` not
-     * matching, and the inner control kept the attribute, so a control disabled
-     * once could never be re-enabled. It only shows when something re-enables,
-     * which is the same shape of bug `inheritDisabled` was written for.
-     *
-     * Our own half is already in `this.disabled` and `isDisabled` is an or, so
-     * this records only what the fieldset adds. That also removes the write
-     * entirely on the own-disabled path rather than moving it.
-     *
-     * The one case this cannot see is a control that is disabled itself *and*
-     * inside a disabled fieldset, whose own `disabled` is then removed: the
-     * effective state does not change, so the platform does not call again, and
-     * the fieldset's hold is not recorded. There is no callback to learn it from
-     * and reading `:disabled` here would answer about the attribute we are in the
-     * middle of removing.
-     */
     formDisabledCallback(disabled) {
         this.formDisabled = disabled && !this.disabled;
     }
     willUpdate(changed) {
         super.willUpdate(changed);
-        // Off for either reason, and said once for every control in the library.
         this.internals.ariaDisabled = this.isDisabled ? 'true' : null;
     }
-    /**
-     * The form this control belongs to, if any.
-     *
-     * @reference https://html.spec.whatwg.org/multipage/custom-elements.html#form-associated-custom-elements form-associated custom elements
-     */
     get form() {
         return this.internals.form;
     }
-    /**
-     * Labels associated with this control.
-     *
-     * @reference https://html.spec.whatwg.org/multipage/custom-elements.html#form-associated-custom-elements form-associated custom elements
-     */
     get labels() {
         return this.internals.labels;
     }
@@ -173,12 +39,6 @@ __decorate([
 ], HelixFormElement.prototype, "formDisabled", void 0);
 __decorate([
     property({
-        /* Empty means absent, which plain reflection cannot say. `name = ''` is the
-           default and Lit reflects it as `name=""`, so every button, switch and
-           calendar in the library would ship an empty name attribute the consumer
-           never wrote. Returning `null` removes the attribute instead. Same trap
-           `hostAria` exists for: a name of no characters is not the absence of
-           one. */
         converter: {
             fromAttribute: (value) => value ?? '',
             toAttribute: (value) => (value === '' ? null : value),

package/dist/mixins/mixin-chart-source/mixin-chart-source.js

@@ -8,111 +8,34 @@ import { property } from 'lit/decorators.js';
 import { ChartPointerController } from '../../controllers/chart-pointer-controller/chart-pointer-controller.js';
 import { SourceController } from '../../controllers/source-controller/source-controller.js';
 import { readRows, readSeries } from '../../utils/read-series/read-series.js';
-/**
- * How many colors the series palette has, and so where it starts over.
- *
- * Here rather than in each chart, because a number two files have to agree on
- * is a number that will stop agreeing: when the palette went from eight to
- * twenty-four, one of five copies was missed and drew every ninth series in the
- * first color while the legend beside it named the ninth.
- */
 export const PALETTE = 24;
-/** The palette slot for the nth series, counting from one and wrapping. */
 export const seriesIndex = (depth) => (depth % PALETTE) + 1;
-/**
- * The half of a chart that is about finding its numbers rather than drawing.
- *
- * **A mixin rather than a controller**, by the rule the tier notes give: it
- * introduces `for` and `label`, which a consumer writes. `SourceController` is
- * the other half and stays a controller, because resolving an id and watching
- * for changes is behavior nobody calls.
- *
- * **`Legend` deliberately does not take this.** It reads a table and has no
- * drawing to title, so `label` would be API it never uses, and a mixin applied
- * for four fifths of a fit is how a shared thing starts drifting.
- */
 export const MixinChartSource = (Base) => {
     class ChartSourceElement extends Base {
         constructor() {
             super(...arguments);
-            /** Resolves `for` and re-renders when the table behind it changes. */
             this.source = new SourceController(this);
-            /**
-             * Which reading a pointer is nearest, for a tooltip to sit on.
-             *
-             * Public for the same reason `series` and `named` are: a protected member
-             * cannot be cast onto across unrelated classes, so it would be invisible to
-             * every chart that needs it. Reading where a pointer is resting is a fair
-             * thing to ask a chart anyway.
-             */
             this.pointer = new ChartPointerController(this);
-            /**
-             * The id of the table to read.
-             *
-             * Resolved through `getRootNode()`, so a chart inside another component's
-             * shadow root names a table in that root rather than in the document. A
-             * `<table>` or anything built from grid roles, including `helix-table`.
-             *
-             * **In React this arrives as a property and not as an attribute**, the way
-             * `Tooltip.for` does, so it does not reflect and nothing styles on it.
-             */
             this.for = '';
-            /**
-             * The drawing's name, for a pointer resting on it.
-             *
-             * Absent falls back to the table's own caption, which is usually the right
-             * words and is already written.
-             */
             this.label = '';
         }
-        /**
-         * Re-resolves when the chart is pointed at a different table.
-         *
-         * `SourceController` watches whatever it resolved on connect, and nothing
-         * tells it the id changed. Without this, pointing a chart at a second table
-         * leaves it drawing the first, silently.
-         */
         willUpdate(changed) {
             super.willUpdate(changed);
             if (changed.has('for')) {
                 this.source.watch();
             }
         }
-        /** The columns of the table, one series each, or none if there is no table. */
         get series() {
             const element = this.source.element;
             return element ? readSeries(element) : [];
         }
-        /**
-         * What to call the drawing, the consumer's word or the table's own.
-         *
-         * The fallback is the reason this is shared rather than copied: a caption is
-         * already written, already the right words, and already the thing a reader
-         * of the table sees. A chart that made the consumer say it twice would be
-         * asking for the second one to drift.
-         */
         get named() {
             return this.label || this.source.element?.querySelector('caption')?.textContent?.trim() || '';
         }
-        /**
-         * Every row of the table, with each cell's text as well as its number.
-         *
-         * This is where a tooltip's content comes from, and it is deliberately not
-         * `series`. A chart draws numbers; a reader resting a pointer on one wants
-         * what the table says, which is `$128k` and not `128000`, and often wants
-         * the column beside it that nothing plotted at all.
-         *
-         * **Not `rows`.** It is the source table's rows, and `rows` on a chart is a
-         * name a chart wants for itself: `helix-heatmap` takes `rows="7"` to mean a
-         * calendar week, and declaring that against a base class whose `rows` is a
-         * `Row[]` getter is a type error at best. Name the member for what it holds
-         * rather than for the shortest word available.
-         */
         get sourceRows() {
             const element = this.source.element;
             return element ? readRows(element) : [];
         }
-        /** How many readings there are, which is what the pointer maps onto. */
         get readings() {
             return this.sourceRows.length;
         }

package/dist/mixins/mixin-collection/mixin-collection.js

@@ -6,74 +6,16 @@ var __decorate = (this && this.__decorate) || function (decorators, target, key,
 };
 import { html, nothing } from 'lit';
 import { property, state } from 'lit/decorators.js';
-/**
- * Grafts the two states a collection has that are not its content.
- *
- * **Empty and loading are different answers and a reader can tell them apart.**
- * "No results" under a spinner is a lie for as long as the request is in
- * flight, and a blank box is not an answer at all: a reader cannot know whether
- * a list is empty, still arriving, or broken.
- *
- * **`aria-busy` on the collection, not on the message.** A reader with a screen
- * reader is told the region is changing and then told once, politely, what it
- * settled on: a live region that fires on every intermediate state is a reader
- * being read a progress bar.
- *
- * **The status replaces the rows rather than sitting above them.** A list that
- * shows "Loading" over the last request's results is a list that lies about
- * which question it is answering, and this is the point in a component's life
- * when a consumer is most likely to be looking at stale content.
- *
- * **`empty` and `loading` are documented on each of the five families that
- * apply this, rather than here.** See `MixinField` for why a class-level tag on
- * a mixin reaches no manifest.
- */
 export const MixinCollection = (Base) => {
     class Collection extends Base {
         constructor() {
             super(...arguments);
-            /**
-             * What is said where there are none, and none are coming.
-             */
             this.emptyText = 'Nothing to show';
-            /**
-             * Whether the rows are still on their way.
-             *
-             * Reflected, because a stylesheet needs it: the rows that are already there
-             * are dimmed rather than removed while a new set arrives, and only CSS can
-             * say that without the component knowing what a row looks like.
-             */
             this.loading = false;
-            /**
-             * What is said while they are on their way.
-             */
             this.loadingText = 'Loading';
-            /**
-             * Whether the rows have been looked at yet.
-             */
             this.slotCounted = false;
-            /**
-             * How many there were, the last time anyone looked.
-             *
-             * **Never name this `rows`.** TypeScript's `private` is a compile-time
-             * claim and the runtime field is whatever it is named, so a subclass
-             * declaring `@property() rows` for the data a consumer hands it would share
-             * one field with this counter: the slot count would overwrite the
-             * consumer's array on every `updated`, and `hasRows` would read the array's
-             * length as a slot count. Nothing would throw. `helix-data-table` takes
-             * exactly that property.
-             */
             this.slotRows = 0;
         }
-        /**
-         * Counts what a rows slot was given.
-         *
-         * Emptiness is a fact about light DOM children and the server has none to
-         * count. `slotchange` never fires there, so `counted` is false exactly when
-         * the answer is unknown, and an unknown answer is not "empty": a list that
-         * shipped "Nothing to show" over markup about to have rows in it is the one
-         * thing an empty state must never do.
-         */
         countRows(event) {
             this.slotCounted = true;
             this.slotRows = event.target.assignedElements().length;
@@ -81,24 +23,6 @@ export const MixinCollection = (Base) => {
         get hasRows() {
             return this.slotCounted ? this.slotRows > 0 : true;
         }
-        /**
-         * Counts the rows slot after every render.
-         *
-         * `slotchange` alone is not enough, and the gap is exactly the case this
-         * mixin exists for: the event fires when an assignment *changes*, and a
-         * collection that arrives with nothing in it has no change to report. So a
-         * list that was empty from the start never learned it was empty and said
-         * nothing at all, which is the blank box a reader cannot tell from a broken
-         * one. Measured on Table, whose rows slot starts empty.
-         *
-         * The default slot, by name, because that is where every collection in this
-         * library puts its rows: Listbox its options, Tree its items, Table its
-         * rows, Menu and Drilldown their pages. A named slot is a header or a
-         * footer, and neither is content.
-         *
-         * `updated` never runs on the server, which is what keeps `counted` false
-         * exactly when the answer is unknown.
-         */
         updated(changed) {
             super.updated?.(changed);
             const slot = this.renderRoot?.querySelector?.('slot:not([name])');
@@ -111,13 +35,6 @@ export const MixinCollection = (Base) => {
                 this.slotRows = rows;
             }
         }
-        /**
-         * The status line, or nothing where there is content to show.
-         *
-         * Loading wins over empty. A collection that has not answered yet is not
-         * empty, and saying so is the most common version of this fault: the reader
-         * is told there is nothing a moment before there is something.
-         */
         renderStatus(hasContent) {
             if (this.loading) {
                 return html `<p part="loading" role="status">${this.loadingText}</p>`;

package/dist/mixins/mixin-controller-active/mixin-controller-active.js

@@ -8,57 +8,13 @@ import { property } from 'lit/decorators.js';
 import { HelixActivateEvent, HelixBeforeActivateEvent } from '../../events/events.js';
 import { requestChange } from '../../utils/request-change/request-change.js';
 import { resolveActiveItem, } from '../../utils/resolve-active-item/resolve-active-item.js';
-/**
- * Grafts "which one of these is the current one" onto a container.
- *
- * For a set where one member is current and the set is not a form control:
- * tabs, a tree, a nav bar, a carousel. Where it *is* a form control the value
- * is submitted and belongs to `MixinControllerValue`, which is why these are
- * two mixins and not one with a flag.
- *
- * **Announcing before applying is the part worth sharing.** Writing the current
- * value straight from the item's event leaves a consumer no way to refuse a
- * change, and whether a selection can be refused must not depend on which
- * component a reader is looking at.
- *
- * **The fallback is the other half.** `items.find(match) ?? items[0]` is not
- * the obvious line it looks like: it is what makes a set whose `active` names
- * nothing still show something, which is every set before its consumer has set
- * one and every set whose current item has just been removed. `resolveActive`
- * also skips disabled items in that fallback, or a set opening on a disabled
- * first item shows it as current.
- */
 export const MixinControllerActive = (Base) => {
-    // JSDoc is duplicated from the interface deliberately. The interface is what
-    // TypeScript consumers see; this class is what the manifest analyzer reads
-    // when resolving inherited members into dependent packages.
     class ActiveElement extends Base {
         constructor() {
             super(...arguments);
-            /**
-             * Initial item for uncontrolled use.
-             *
-             * Ignored once `active` is written.
-             */
             this.defaultActive = '';
-            /**
-             * The state, whoever set it, and `undefined` until somebody has.
-             *
-             * One field and not two. Writing always applies, the way a native control
-             * does when a script assigns to it.
-             */
             this.activeState = undefined;
         }
-        /**
-         * Which item is current, by its `value`.
-         *
-         * Not `option.active`, which is the option the keyboard is on: that is a
-         * different question from which one is chosen.
-         *
-         * Writing always applies, so `<helix-tabs active="one">` starts on that
-         * tab, and `default-active` is how markup says where to start without
-         * naming the current one.
-         */
         get active() {
             return this.activeState ?? this.defaultActive;
         }
@@ -67,16 +23,6 @@ export const MixinControllerActive = (Base) => {
             this.activeState = next;
             this.requestUpdate('active', previous);
         }
-        /**
-         * Requests a new current item, and reports whether the request stood.
-         *
-         * Announces before it acts, so `preventDefault()` on the `helix-before-activate` is
-         * a refusal and nothing moves. Unlike a native control, nothing has moved
-         * by the time this runs, so refusing is simply not writing: there is
-         * nothing to put back. Nobody refusing means the set updates itself,
-         * whether or not a consumer declared `active`, a declared property being a
-         * seed and a correction.
-         */
         requestActive(next) {
             if (next === this.active) {
                 return true;
@@ -96,37 +42,9 @@ export const MixinControllerActive = (Base) => {
             }
             return applied;
         }
-        /**
-         * Says the current child moved, once it has.
-         *
-         * `helix-activate` rather than a native word: nothing on the platform means
-         * "a set chose a different member", and borrowing `change` would be a lie
-         * about what moved.
-         *
-         * A consumer who only wants to know which child is current cannot use
-         * `helix-before-activate` for it, that one firing *before* `apply`, so
-         * `currentTarget.active` is the previous value inside the handler and
-         * `detail.value` is a proposal another listener may refuse. `helix-select`
-         * is no substitute either: it fires when an item is *chosen* and not when
-         * `active` is assigned.
-         *
-         * **After `apply`, which is the whole reason it is a second event**, so the
-         * state is on the element by the time a handler reads it. Not cancelable:
-         * the decision was taken by the event before this one, and two refusable
-         * events for one transition are two answers to one question.
-         */
         announceActivated(value) {
             this.dispatchEvent(new HelixActivateEvent({ value }));
         }
-        /**
-         * Which item is current, given what there is to choose from.
-         *
-         * The first enabled one when `active` names nothing, which is a set before
-         * its consumer has chosen and a set whose current item has just been
-         * removed. Disabled items are skipped in the fallback but not in the match:
-         * a consumer who names a disabled item meant it, and quietly moving to
-         * another would be the component overruling them.
-         */
         resolveActive(items) {
             return resolveActiveItem(this.active, items);
         }

package/dist/mixins/mixin-controller-checked/mixin-controller-checked.js

@@ -7,47 +7,13 @@ var __decorate = (this && this.__decorate) || function (decorators, target, key,
 import { property } from 'lit/decorators.js';
 import { HelixBeforeToggleEvent } from '../../events/events.js';
 import { requestChange } from '../../utils/request-change/request-change.js';
-/**
- * Grafts checked state onto a base class.
- *
- * `checked` is a seed and a correction rather than a claim: the element applies
- * its own changes from wherever markup started it, `defaultChecked` is what a
- * reset returns to, and a consumer takes the decision by refusing the
- * `helix-before-toggle`.
- *
- * Records `:state(checked)` whenever the element is checked. Styled tiers
- * select on that rather than on `[checked]`, which is absent until somebody
- * writes it.
- */
 export const MixinControllerChecked = (Base) => {
-    // JSDoc is duplicated from MixinControllerCheckedInterface deliberately. The
-    // interface is what TypeScript consumers see; this class is what the manifest
-    // analyzer reads when resolving inherited members into dependent packages.
     class CheckedElement extends Base {
         constructor() {
             super(...arguments);
-            /**
-             * Initial checked state for uncontrolled use, where nothing declared one.
-             */
             this.defaultChecked = false;
-            /**
-             * The state, whoever set it, and `undefined` until somebody has.
-             *
-             * One field and not two. Writing always applies, the way a native control
-             * does when a script assigns to it.
-             */
             this.checkedState = undefined;
         }
-        /**
-         * Whether the control is checked.
-         *
-         * One property rather than two. Writing always applies;
-         * `<helix-checkbox checked>` is the same statement in markup.
-         *
-         * Not reflected: the attribute is the consumer's input and stays as they
-         * wrote it, and `:state(checked)` carries the resolved state for
-         * stylesheets.
-         */
         get checked() {
             return this.checkedState ?? this.defaultChecked;
         }
@@ -56,33 +22,10 @@ export const MixinControllerChecked = (Base) => {
             this.checkedState = next;
             this.requestUpdate('checked', previous);
         }
-        /**
-         * Records the resolved state as the custom state `checked`.
-         *
-         * **A custom state and never `data-checked`.** An attribute written here
-         * means `<helix-checkbox default-checked>` comes back from a consumer's
-         * server without it and gains it the moment the definition lands, which
-         * React lists as a hydration mismatch and does not patch up.
-         * `HelixElement.toggleState` says why the host is the wrong place to keep a
-         * component's own bookkeeping.
-         *
-         * In `willUpdate`, which is where the resolved state is first known and is
-         * what a subclass rendering from it expects.
-         */
         willUpdate(changed) {
             super.willUpdate(changed);
             this.toggleState('checked', this.checked);
         }
-        /**
-         * Requests a checked change, and reports whether it was applied.
-         *
-         * Announces before it acts, so `preventDefault()` on the
-         * `helix-before-toggle` is a refusal and nothing moves. Nobody refusing
-         * means the element updates itself, whether or not a consumer declared the
-         * property: a declared property is a seed and a correction, the way
-         * `<input value>` is, and a consumer who wants the change for themselves
-         * refuses it and assigns their own.
-         */
         requestChecked(next) {
             if (this.checked === next) {
                 return true;
@@ -98,37 +41,16 @@ export const MixinControllerChecked = (Base) => {
                 next,
             });
             if (applied) {
-                /* `input` here and `change` relayed from the inner control, which is
-                   the pair a native checkbox sends. Announced after `apply`, so a
-                   handler reading `currentTarget.checked` reads the new state. */
                 this.dispatchEvent(new Event('input', { bubbles: true, composed: true }));
             }
             return applied;
         }
-        /** Requests the opposite of the current state. */
         toggleChecked() {
             return this.requestChecked(!this.checked);
         }
-        /**
-         * Restores the control when the browser brings a form back.
-         *
-         * The mixin owns `checked`, so the mixin owns putting it back: written on
-         * one consumer and not the other, a reader who navigates away and comes
-         * back to a restored form finds that control flipped off.
-         *
-         * Through the public accessor rather than the private field, so a restore
-         * takes the same path a script assignment does.
-         */
         formStateRestoreCallback(state) {
             this.checked = state !== null;
         }
-        /**
-         * Drops the recorded state, so the control reads `defaultChecked` again.
-         *
-         * A form reset has to return a control to what its markup declared, and no
-         * assignment to `checked` can do that: any assignment records a state. The
-         * recorded state lives here, so this is where it is dropped.
-         */
         resetChecked() {
             const previous = this.checked;
             this.checkedState = undefined;