@bluepic/embed 0.4.0-next.160 → 0.4.0-next.162

package/dist/util/fieldHints/chipAction.d.ts

@@ -1,19 +1,19 @@
 import type { BluepicField } from '@bluepic/types';
 /**
- * What clicking a hint chip does.
+ * What clicking a chip does.
  *
- * There is no per-field hint MODE any more — hints are simply on or off for the
- * whole campaign (`config.hints.enabled`). What a chip does is inferred from the
- * field itself:
+ * There is no per-field hint MODE — hints are simply on or off for the whole
+ * campaign (`config.hints`). What a chip does is inferred from the field itself:
  *
- * - `upload` — an image field that accepts a device upload. Clicking goes
- *   straight to its own upload flow, which is the only thing anyone wants from
- *   an image chip.
+ * - `upload` — the field accepts a device upload. Clicking goes straight to the
+ *   file picker, which is the only thing anyone wants from a chip sitting on a
+ *   picture. Other sources stay one tap away through the field itself.
  * - `focus`  — everything else, including image fields restricted to libraries.
- *   The chip scrolls the field into view and focuses its control, so the next
- *   keystroke already types into it.
+ *   The chip then does what the hitbox around it does: scroll the field into
+ *   view and focus its control, so the next keystroke already types into it.
  */
 export type ChipAction = 'upload' | 'focus';
+export declare function fieldHasChip(fieldType: BluepicField['type']): boolean;
 /**
  * `field.props` entries may be author expressions (functions) rather than
  * literals, so a prop can only be read through the host's evaluator — the same

package/dist/util/fieldHints/fieldFocus.d.ts

@@ -4,10 +4,10 @@ import type { BluepicField } from '@bluepic/types';
  * Opens a field's own primary editing flow — for an image field, the "Select
  * image" popup (or the device file picker, when that's all it offers).
  *
- * Registered BY the field component, because only it knows that flow. An
- * `interact` hint reproducing it would mean duplicating image libraries,
- * cropping, background removal and auto-crop on the overlay, and then watching
- * the two copies drift.
+ * Registered BY the field component, because only it knows that flow. Having the
+ * overlay reproduce it would mean duplicating image libraries, cropping,
+ * background removal and auto-crop up there, and then watching the two copies
+ * drift.
  */
 export type FieldActivator = () => void;
 /**
@@ -18,13 +18,14 @@ export type FieldActivator = () => void;
  * provided by `BxTemplateEditor` and injected at both ends rather than threaded
  * through props.
  *
- * DESKTOP registers elements here and focuses them directly. MOBILE does not:
- * one field slide is on screen at a time, so "focus" there means swiping the
- * swiper to the right slide, which only `BxTemplateEditor` can do. That
- * asymmetry is why `focus()` is a controller method and not just a lookup.
+ * BOTH layouts register their elements here, because both end up focusing one:
+ * mobile mounts every swiper slide at once, so the control exists even while the
+ * swiper is still travelling to it. What differs is how it is brought on screen
+ * — desktop scrolls the panel, mobile swipes — and only `BxTemplateEditor` can
+ * do the latter, which is why `focus()` is a controller method and not just a
+ * lookup.
  */
 export type FieldFocusController = {
-    /** Desktop only; mobile slides are addressed by index, not by element. */
     register(field: BluepicField, el: HTMLElement | null): void;
     focus(field: BluepicField): void;
     /** Field components self-register; pass `null` on unmount. */
@@ -42,16 +43,24 @@ export declare function useFieldFocus(): FieldFocusController | undefined;
 /** Marks the focused field for a moment so the eye can follow the jump. */
 export declare const FIELD_FOCUS_FLASH_CLASS = "bx-field-hint-target";
 /**
- * Scroll a field's control into view, flash it, and focus the first thing in it
- * that can take focus.
+ * Scroll a field's control into view, flash it, and focus what you type into —
+ * falling back to whatever else in it can take focus.
  *
  * `block: 'nearest'` rather than 'center': the fields panel is a scroll
  * container, and centering yanks the whole list even when the target was
  * already comfortably visible.
+ *
+ * `scroll: false` for the MOBILE layout. Every slide is mounted at once inside
+ * swiper's transformed track, so a field that is off screen is off screen by
+ * TRANSFORM, not by scroll position — asking the browser to scroll it into view
+ * shifts the track's own scroller and leaves swiper's idea of the offset wrong.
+ * There, `slideTo` does the travelling and this only has to focus.
  */
-export declare function revealFieldElement(el: HTMLElement | null | undefined): HTMLElement | undefined;
+export declare function revealFieldElement(el: HTMLElement | null | undefined, { scroll }?: {
+    scroll?: boolean;
+}): HTMLElement | undefined;
 /**
- * Creates the desktop half: a registry keyed by the field object itself.
+ * The element/activator registry, keyed by the field object itself.
  *
  * A WeakMap (not a Map) because fields are plain objects off the serial — when
  * the serial is swapped the old field objects should simply be collectable,

package/dist/util/fieldHints/index.d.ts

@@ -9,13 +9,11 @@ export type { FieldHitbox } from './useFieldHitboxes';
 export { useHintReveal } from './useHintReveal';
 export { createFieldElementRegistry, provideFieldFocus, revealFieldElement, useFieldFocus, FIELD_FOCUS_KEY, FIELD_FOCUS_FLASH_CLASS, } from './fieldFocus';
 export type { FieldFocusController } from './fieldFocus';
-export { chipActionFor, readFieldProp } from './chipAction';
+export { chipActionFor, fieldHasChip, readFieldProp } from './chipAction';
 export type { ChipAction } from './chipAction';
 export { textGeometryProbe } from './textProbe';
 export type { CaretGeometry, SelectionQuad, TextGeometryResult, TextIndexResult } from './textProbe';
 export { useCanvasTextEditing } from './useCanvasTextEditing';
 export type { CanvasTextState, SelectionHandle } from './useCanvasTextEditing';
-export { chooseChipPlacement, chipIsCentered, estimateChipWidth, arrowRotationForSide } from './placement';
-export type { ChipSide, PlacementResult } from './placement';
 export { useFieldActivator } from './fieldFocus';
 export type { FieldActivator } from './fieldFocus';

package/dist/util/fieldHints/useFieldHitboxes.d.ts

@@ -48,7 +48,7 @@ export declare function useFieldHitboxes(options: {
     data: Ref<{
         [k: string]: unknown;
     }>;
-    /** Campaign gate (`config.hints?.enabled === true`). */
+    /** Campaign gate (`config.hints?.enabled !== false` — on by default). */
     enabled: Ref<boolean>;
 }): {
     hitboxes: Ref<{

package/dist/util/fieldHints/useHintReveal.d.ts

@@ -1,7 +1,7 @@
 import { type Ref } from 'vue';
 export declare function useHintReveal(enabled: Ref<boolean>): {
     revealed: import("vue").ComputedRef<boolean>;
-    hide: () => void;
+    reveal: () => void;
     onPointerEnter: (event: PointerEvent) => void;
     onPointerLeave: (event: PointerEvent) => void;
     onPointerDown: (event: PointerEvent) => void;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bluepic/embed",
-  "version": "0.4.0-next.160",
+  "version": "0.4.0-next.162",
   "description": "Bluepic embed sdk",
   "type": "module",
   "sideEffects": false,

package/dist/util/fieldHints/placement.d.ts

@@ -1,72 +0,0 @@
-import type { BluepicField } from '@bluepic/types';
-/**
- * Where a hint chip sits relative to its hitbox.
- *
- * Deliberately a small synchronous solver rather than `@floating-ui`, which
- * this package already depends on: hints re-project on EVERY pan/zoom frame,
- * and floating-ui's `computePosition` is async and DOM-measuring. Running one
- * per hint per frame would lag the overlay behind the canvas it is annotating.
- * A pure function over numbers also means the placement rules can be tested
- * without a DOM.
- */
-export type ChipSide = 'top' | 'bottom' | 'left' | 'right';
-export type Rect = {
-    x: number;
-    y: number;
-    width: number;
-    height: number;
-};
-export type PlacementInput = {
-    /** Hitbox AABB in overlay pixels. */
-    box: Rect;
-    /** Measured (or estimated) chip size. */
-    chip: {
-        width: number;
-        height: number;
-    };
-    /** Visible overlay area. */
-    viewport: {
-        width: number;
-        height: number;
-    };
-    /** Distance from the hitbox edge to the chip edge — room for the arrow. */
-    gap: number;
-    /** Keep-inside-the-viewport padding. */
-    margin: number;
-};
-export type PlacementResult = {
-    side: ChipSide;
-    /** Chip top-left in overlay pixels. */
-    x: number;
-    y: number;
-    /**
-     * Arrow tip anchor, RELATIVE to the chip's top-left. Tracks the hitbox centre
-     * even after the chip has been shifted to stay on screen — otherwise a
-     * clamped chip would point at empty space.
-     */
-    arrowX: number;
-    arrowY: number;
-};
-export declare function chipIsCentered(fieldType: BluepicField['type']): boolean;
-export declare function chooseChipPlacement(input: PlacementInput): PlacementResult;
-/**
- * Chip width before the real element has been measured. Only used for the very
- * first frame — the layer measures the rendered chip and re-solves — but a wild
- * guess here would place the first paint visibly wrong.
- */
-export declare function estimateChipWidth(label: string, max?: number): number;
-/**
- * The arrow artwork points RIGHT at rest — the path's tip is authored on the
- * left, but `popoverArrow`'s outer `matrix(-1,0,-0,-1,...)` flips it. Verified
- * by rasterising the mask: the left edge is ~97% covered (the flat base) and
- * the right edge ~4% (the point).
- */
-export declare const ARROW_NATIVE_DIRECTION: {
-    x: number;
-    y: number;
-};
-/**
- * Degrees to rotate the arrow so it points from the chip back at its hitbox.
- * CSS rotation is clockwise with y pointing down.
- */
-export declare function arrowRotationForSide(side: ChipSide): number;