@formicoidea/labre-core 0.31.0 → 0.33.0

package/dist/_pkgs/affine-widget-toolbar/toolbar.js

@@ -16,7 +16,7 @@ import { css, unsafeCSS } from 'lit';
 import groupBy from 'lodash-es/groupBy.js';
 import throttle from 'lodash-es/throttle.js';
 import toPairs from 'lodash-es/toPairs.js';
-import { autoUpdatePosition, renderToolbar, sideMap } from './utils.js';
+import { autoUpdatePosition, sideMap, ToolbarFitter } from './utils.js';
 export const AFFINE_TOOLBAR_WIDGET = 'affine-toolbar-widget';
 export class AffineToolbarWidget extends WidgetComponent {
     constructor() {
@@ -24,6 +24,11 @@ export class AffineToolbarWidget extends WidgetComponent {
         this.sideOptions$ = signal(null);
         this.referenceElement$ = signal(null);
         this.toolbar = new EditorToolbar();
+        /**
+         * Keeps the row on one line: it renders the toolbar, measures it and hands
+         * the least important entries to the "⋮" menu when the room runs out.
+         */
+        this.fitter = new ToolbarFitter(this.toolbar);
     }
     static { this.styles = css `
     editor-toolbar {
@@ -98,7 +103,19 @@ export class AffineToolbarWidget extends WidgetComponent {
         this.referenceElement$.value = element ? () => element : null;
     }
     setReferenceElementWithBlocks(blocks) {
-        const getClientRects = () => blocks.map(e => e.getBoundingClientRect());
+        // A single position pass asks for the rects twice — once for the common
+        // bound, once for the inline middleware — and the pass runs on every
+        // scroll frame. One measure per frame is enough.
+        let cachedClientRects = null;
+        const getClientRects = () => {
+            if (!cachedClientRects) {
+                cachedClientRects = blocks.map(e => e.getBoundingClientRect());
+                requestAnimationFrame(() => {
+                    cachedClientRects = null;
+                });
+            }
+            return cachedClientRects;
+        };
         this.referenceElement$.value = blocks.length
             ? () => ({
                 getBoundingClientRect: () => {
@@ -113,10 +130,13 @@ export class AffineToolbarWidget extends WidgetComponent {
             : null;
     }
     setReferenceElementWithElements(gfx, elements) {
+        // Measured once per selection change, not on every anchor read: floating-ui
+        // calls `getBoundingClientRect` on each frame of a pan or a zoom, and the
+        // surface bound of a group walks all of its children.
+        const surfaceBounds = getCommonBoundWithRotation(elements);
         const getBoundingClientRect = () => {
-            const bounds = getCommonBoundWithRotation(elements);
             const { x: offsetX, y: offsetY } = this.getBoundingClientRect();
-            const [x, y, w, h] = gfx.viewport.toViewBound(bounds).toXYWH();
+            const [x, y, w, h] = gfx.viewport.toViewBound(surfaceBounds).toXYWH();
             const rect = new DOMRect(x + offsetX, y + offsetY, w, h);
             return rect;
         };
@@ -273,8 +293,12 @@ export class AffineToolbarWidget extends WidgetComponent {
                 // Chencks if block's config exists.
                 if (block) {
                     const modelFlavour = block.model.flavour;
-                    const existed = toolbarRegistry.modules.has(modelFlavour) ||
-                        toolbarRegistry.modules.has(`custom:${modelFlavour}`);
+                    // `modulesFor`, not `modules.has`: the question is whether this
+                    // flavour has a row AT ALL, and since a flavour may be claimed by
+                    // an owner-suffixed contributor as well as by its own key, a raw
+                    // variant lookup would answer "no row" for a flavour that draws one.
+                    const existed = toolbarRegistry.modulesFor(modelFlavour).length > 0 ||
+                        toolbarRegistry.modulesFor(`custom:${modelFlavour}`).length > 0;
                     if (existed) {
                         flavour = modelFlavour;
                     }
@@ -469,6 +493,7 @@ export class AffineToolbarWidget extends WidgetComponent {
             const value = flags.value$.value;
             // Hides toolbar
             if (Flag.None === value || flags.check(Flag.Hiding, value)) {
+                this.fitter.reset();
                 if ('inline' in toolbar.dataset)
                     delete toolbar.dataset.inline;
                 if (toolbar.dataset.open)
@@ -486,8 +511,15 @@ export class AffineToolbarWidget extends WidgetComponent {
             // 3. `Flag.Block`: blocks in note
             // 4. `Flag.Hovering`: inline links in note/database/table
             // 5. `Flag.Surface`: elements in edgeless
-            renderToolbar(toolbar, context, flavour);
+            this.fitter.render(context, flavour);
         }));
+        // The row never wraps, so it has to be told when its room changes. Two
+        // things can change it: the cap `size()` writes on every reposition, and
+        // anything that resizes the toolbar itself (a narrower editor, a zoom, a
+        // font that loaded late) — the observer catches what the cap misses.
+        const resizeObserver = new ResizeObserver(() => this.fitter.resize());
+        resizeObserver.observe(toolbar);
+        disposables.add(() => resizeObserver.disconnect());
         let abortController = new AbortController();
         disposables.add(effect(() => {
             if (!abortController.signal.aborted) {
@@ -509,7 +541,7 @@ export class AffineToolbarWidget extends WidgetComponent {
                 abortController = new AbortController();
             }
             const signal = abortController.signal;
-            const cleanup = autoUpdatePosition(signal, toolbar, referenceElement, flavour, placement, sideOptions);
+            const cleanup = autoUpdatePosition(signal, toolbar, referenceElement, flavour, placement, sideOptions, undefined, () => this.fitter.resize());
             signal.addEventListener('abort', cleanup, { once: true });
             return () => {
                 if (signal.aborted)

package/dist/_pkgs/affine-widget-toolbar/utils.d.ts

@@ -1,5 +1,5 @@
 import { type EditorToolbar } from '../affine-components/toolbar/index.js';
-import { type ToolbarActions, type ToolbarContext, type ToolbarPlacement } from '../affine-shared/services/index.js';
+import { type ToolbarActions, type ToolbarContext, type ToolbarLayoutStep, type ToolbarPlacement } from '../affine-shared/services/index.js';
 import type { AutoUpdateOptions, ReferenceElement, SideObject } from '@floating-ui/dom';
 export declare const sideMap: Map<string, {
     top: number;
@@ -8,8 +8,67 @@ export declare const sideMap: Map<string, {
     top: number;
     bottom: number;
 }>;
-export declare function autoUpdatePosition(signal: AbortSignal, toolbar: EditorToolbar, referenceElement: ReferenceElement, flavour: string, placement: ToolbarPlacement, sideOptions: Partial<SideObject> | null, options?: AutoUpdateOptions): () => void;
+export declare function autoUpdatePosition(signal: AbortSignal, toolbar: EditorToolbar, referenceElement: ReferenceElement, flavour: string, placement: ToolbarPlacement, sideOptions: Partial<SideObject> | null, options?: AutoUpdateOptions, 
+/**
+ * Called whenever the room the row has just changed. This is the only place
+ * that knows it: `size` is what writes the cap, and it re-runs on every
+ * scroll, resize and flip.
+ */
+onAvailableWidth?: () => void): () => void;
 export declare function combine(actions: ToolbarActions, context: ToolbarContext): any[];
+/**
+ * How much of the row an entry has given up, decided by {@link ToolbarFitter}
+ * and re-applied by every render until the room changes again.
+ */
+export interface ToolbarLayout {
+    /** Entries rendered as their icon alone, with the label as tooltip. */
+    shrunk: Set<string>;
+    /** Entries rendered as entries of the "⋮" menu instead of the row. */
+    collapsed: Set<string>;
+}
+export declare function emptyToolbarLayout(): ToolbarLayout;
+/**
+ * What the row is, in two values — the question the plan is asked by.
+ *
+ * The split is the whole of the second half of the PO's recette of 25/08/2026,
+ * and it is the difference between the two things a re-render can invalidate:
+ *
+ * - {@link entries} is WHICH ENTRIES the row has, with their words, their
+ *   icons, their priorities and whether the widget can move them into the "⋮".
+ *   It is what makes a PLAN applicable: a plan is a list of entry ids, and it
+ *   describes this row only for as long as this list holds.
+ * - {@link state} is WHAT THOSE ENTRIES SAY. It changes nothing about which
+ *   degradations exist, and everything about what they are worth: the same
+ *   dropdown naming `Strict` instead of `Sketch` is ten pixels narrower, and a
+ *   group that gained a member is a button wider. It is what makes a
+ *   MEASUREMENT applicable.
+ *
+ * A row whose entries changed is a new row and is planned from scratch. A row
+ * whose state changed keeps the plan it is wearing — the eye sees nothing — and
+ * is only re-measured. A row where neither moved is free, which is what makes
+ * a gesture's re-renders cost nothing at all.
+ */
+export interface ToolbarRow {
+    entries: string;
+    state: string;
+}
+/**
+ * Where the row's plan comes from, asked for by {@link ToolbarRow}.
+ *
+ * Called once per render, AFTER the entries are resolved and BEFORE anything
+ * reaches the DOM — which is the whole point. The mode an entry reads in is a
+ * datum of its render, so the plan has to be in hand before the first
+ * character is written; a plan applied afterwards is a plan the eye has
+ * already seen the row without.
+ */
+export type ToolbarLayoutSource = (row: ToolbarRow) => ToolbarLayout;
+/** What one render of the row tells the fitter about its own room to give. */
+export interface ToolbarFit extends ToolbarRow {
+    /** Every degradation available, in the order they must be spent. */
+    steps: ToolbarLayoutStep[];
+    /** Whether the rendered row already carries a "⋮" button. */
+    hasMenu: boolean;
+}
 /**
  * Renders toolbar
  *
@@ -19,4 +78,88 @@ export declare function combine(actions: ToolbarActions, context: ToolbarContext
  * 3. `affine:*`
  * 4. `custom:affine:*`
  */
-export declare function renderToolbar(toolbar: EditorToolbar, context: ToolbarContext, flavour: string): void;
+export declare function renderToolbar(toolbar: EditorToolbar, context: ToolbarContext, flavour: string, source?: ToolbarLayoutSource): ToolbarFit | null;
+/**
+ * Keeps the contextual toolbar on ONE line.
+ *
+ * Owns the two halves the pure planner cannot: MEASURING the row, and
+ * RE-RENDERING it once the planner has said which entries give way. The order
+ * they give way in is not decided here — it comes from what the entries
+ * declared (`priority`, `icon`, `label`), so this class never learns that a
+ * block or a framework exists.
+ *
+ * The row is measured ONCE per ROW, while it is still whole. Every later
+ * resize replans from those numbers instead of flashing the row back to its
+ * full width just to measure it again — which is also what makes the collapse
+ * reversible: widen the editor and the plan simply spends fewer steps.
+ *
+ * "Per row", not per render: the widget re-renders for reasons that have
+ * nothing to do with width, and a re-render is not a new row. Which row it is
+ * is answered by {@link ToolbarRow}, and a row that has not changed keeps the
+ * plan it is wearing — see {@link ToolbarFitter.render}.
+ *
+ * A row that changed only what it SAYS keeps it too, and is simply re-measured
+ * where it stands ({@link ToolbarFitter.#remeasure}). That is the generalisation
+ * the PO's recette of 25/08/2026 asked for: the components' row is made
+ * entirely of entries the widget draws itself, so the list of entries is a
+ * complete description of it and the first half of {@link ToolbarRow} was
+ * enough; a framework background's row is mostly OPAQUE — toggles grouped by
+ * the framework, a dropdown naming the level of requirement in force — and for
+ * that row the list says nothing about what it costs.
+ *
+ * And it replans only at the ACCALMIE. While the room is still moving — a zoom,
+ * a pan, a window being dragged — the plan on screen is frozen: see
+ * {@link ToolbarFitter.resize}.
+ */
+export declare class ToolbarFitter {
+    #private;
+    private readonly toolbar;
+    constructor(toolbar: EditorToolbar);
+    /**
+     * Renders the row, in the mode the plan on screen says.
+     *
+     * The widget re-renders for a great many reasons that have nothing to do
+     * with the row's width — an element updated anywhere on the canvas, a block
+     * updated, a selection re-emitted, something hovered — and any of them can
+     * land on any frame of a gesture. So this asks a question first: is the row
+     * about to be drawn the row already on screen?
+     *
+     * - **Yes** (same {@link ToolbarRow}, both halves): it is drawn wearing the
+     *   plan it is already wearing, entry by entry, and nothing is measured.
+     *   The DOM does not change, so there is nothing to see — which is the
+     *   PO's recette of 25/08/2026. Before, every one of these re-renders threw
+     *   the plan away, painted the whole row, and only then measured and
+     *   degraded it again: one flash of "Read this component" per re-render,
+     *   plus a full replan at whatever width the gesture happened to be at,
+     *   straight through the freeze the accalmie was supposed to give.
+     * - **The same entries, saying something new** — a dropdown naming another
+     *   profile, a group that gained a member: the PLAN still describes the row
+     *   and stays on it, so again there is nothing to see. Only the widths it was
+     *   made from are out of date, and {@link ToolbarFitter.#remeasure} reads
+     *   them back off the row as it is drawn.
+     * - **No**: a different row. Then, and only then, it is rendered whole,
+     *   measured, and spends what it must.
+     */
+    render(context: ToolbarContext, flavour: string): void;
+    /** The toolbar is going away: stop measuring it. */
+    reset(): void;
+    /**
+     * The room the row has may have changed.
+     *
+     * Two answers are refused before anything is replanned, and the PO's second
+     * pass of 02/08/2026 is about both:
+     *
+     * 1. **A change too small to mean anything.** Two measurements a pixel apart
+     *    are the same measurement, and a row that believes them alternates
+     *    between two compositions for as long as they alternate.
+     * 2. **A change that is still happening.** A zoom moves the room on every
+     *    frame; replanning on each of them re-composes the row under the cursor,
+     *    and every new width moves the anchoring with it — which is the toolbar
+     *    "hesitating between anchor points" the PO reported. The plan on screen
+     *    is FROZEN for the whole gesture and spent once, when the viewport lands.
+     *
+     * The room is remembered as it goes by, so the plan that is finally made is
+     * the one for the width the gesture ended on, not the width it started from.
+     */
+    resize(): void;
+}