sadpandajoe commented on code in PR #45090:
URL: https://github.com/apache/superset/pull/45090#discussion_r4456103338
##########
superset/commands/canvas/apply_ops.py:
##########
@@ -127,17 +132,48 @@ def apply_or_raise(
except OperationError as ex:
raise DefinitionInvalidError(
str(ex),
- issues=[Issue(pointer("ops", ex.index), ex.message)],
- operation_index=ex.index,
+ issues=[Issue(pointer("ops", first_index + ex.index), ex.message)],
+ operation_index=first_index + ex.index,
) from ex
except DefinitionValidationError as ex:
raise DefinitionInvalidError(
"The operations produce an invalid definition",
issues=ex.issues,
- operation_index=ex.operation,
+ operation_index=(
+ None if ex.operation is None else first_index + ex.operation
+ ),
) from ex
+def apply_batches(
+ definition: dict[str, Any],
+ batches: list[list[Operation]],
+ pending: dict[str, StoredWidget] | None = None,
+) -> tuple[dict[str, Any], list[AppliedOperation]]:
+ """
+ Apply each batch in turn, resolving layout once per batch.
+
+ For replaying a draft, whose batches are the requests that built it. Where
+ layout is resolved decides the result: operations in one batch are applied
+ before anything is resolved, so none of them sees where another pushed the
+ widgets, while a later batch sees all of it. Resolving at any other
+ boundary lays the canvas out differently from the plan that was approved --
+ once for the whole log, and a widget dragged over another and back stops
+ pushing it aside; once per operation, and a widget moved by a later
+ operation in the same request pushes a third one it never touched.
+
+ One resolve per batch rather than one for the log, which is why this is
+ kept to the commit path.
+ """
+ applied: list[AppliedOperation] = []
+ first_index = 0
+ for batch in batches:
+ definition, step = apply_or_raise(definition, batch, pending,
first_index)
Review Comment:
Publishing (or undoing/redoing) a draft that created widgets in separate
requests drops the later ones. Each replayed batch goes through
`apply_or_raise` with the default `keep_unplaced=False`, so after batch 1
`forget_unplaced` removes any not-yet-placed widget that only a later batch
places, and that later batch's logged add carries just the widget UUID. Take a
draft where request 1 adds chart A and request 2 adds chart B (both
non-structural, so they live in `draft.widgets`): on commit B is no longer in
`pending`, `save_widgets` never writes it, and the canvas is saved with an
unresolved placeholder for B while the draft is deleted. Should the replay keep
unplaced widgets through the intermediate batches and prune only after the last
one, with a test that publishes a two-request draft creating two widgets and
asserts both are saved?
##########
superset-frontend/src/features/canvas/useDraftHistory.ts:
##########
@@ -0,0 +1,118 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+import { useCallback, useEffect, useRef, useState } from 'react';
+import { t } from '@apache-superset/core/translation';
+import { getClientErrorObject, SupersetClient } from '@superset-ui/core';
+import { useToasts } from 'src/components/MessageToasts/withToasts';
+import { DRAFT_TOKEN_HEADER } from './useCanvasDefinition';
+
+export interface DraftHistory {
+ canUndo: boolean;
+ canRedo: boolean;
+ undo: () => void;
+ redo: () => void;
+ /** Whether a step is in flight. */
+ busy: boolean;
+}
+
+/**
+ * Stepping a draft back and forward through the requests that built it.
+ *
+ * The history belongs to the draft, not to this tab. A canvas is edited by
+ * its agent as well as by hand -- both through the same draft -- so a stack
+ * kept in the browser would be wrong the moment the agent moved something,
+ * and gone on a reload. Each step is a request to the server, which rebuilds
+ * the draft and answers with it.
+ */
+export function useDraftHistory(
+ token: string | undefined,
+ revision: number,
+ /** What the draft reported when it was last fetched. */
+ fetched: { canUndo?: boolean; canRedo?: boolean },
+ reload: () => void,
+): DraftHistory {
+ const { addDangerToast } = useToasts();
+ const [state, setState] = useState({
+ canUndo: Boolean(fetched.canUndo),
+ canRedo: Boolean(fetched.canRedo),
+ });
+ const [busy, setBusy] = useState(false);
+ // The revision this state describes. A write moves the draft on, which
+ // makes a step available and discards anything undone -- the server says
+ // so too, but not until something asks it.
+ const seen = useRef(revision);
+
+ useEffect(() => {
+ setState({
+ canUndo: Boolean(fetched.canUndo),
+ canRedo: Boolean(fetched.canRedo),
+ });
+ seen.current = revision;
+ // Only when the draft itself changes: `fetched` is a fresh object every
+ // render, and following it would undo the optimism below on each one.
+ // eslint-disable-next-line react-hooks/exhaustive-deps
+ }, [token, fetched.canUndo, fetched.canRedo]);
+
+ useEffect(() => {
+ if (revision === seen.current) return;
+ seen.current = revision;
+ setState({ canUndo: true, canRedo: false });
+ }, [revision]);
+
+ const step = useCallback(
+ async (direction: 'undo' | 'redo') => {
+ if (!token) return;
+ setBusy(true);
+ try {
+ const { json } = await SupersetClient.post({
+ endpoint: `/api/v1/canvas/draft/${direction}`,
+ headers: { [DRAFT_TOKEN_HEADER]: token },
+ jsonPayload: { revision },
+ });
+ const result = json?.result ?? {};
+ setState({
+ canUndo: Boolean(result.canUndo),
+ canRedo: Boolean(result.canRedo),
+ });
+ seen.current = result.revision ?? revision;
+ // The step rebuilt the whole definition, which is more than the
+ // layout write path carries, so the canvas is refetched rather than
+ // patched in place.
+ reload();
Review Comment:
`reload()` is not awaited, so `busy` clears while the definition refetch is
still pending and `step` keeps closing over the old `revision`. After undoing
once, pressing undo (or Publish) again before the GET lands sends the previous
revision to a draft the server already advanced, so it answers 409 and the user
sees the failure toast instead of a second undo. Should the step stay busy
until the refetch resolves (or carry `result.revision` forward for the next
request)?
##########
superset-frontend/src/features/canvas/CanvasGridSurface.tsx:
##########
@@ -0,0 +1,1652 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+/**
+ * @fileoverview One grid of a canvas, with drag and resize built in.
+ *
+ * There is no edit mode: a user who may edit gets a drag grip and a resize
+ * corner on each widget, on the canvas as they view it. A user who may not
+ * gets the same grid with no handles. Dragging never covers the widget's own
+ * surface, so a filter or chart underneath stays clickable.
+ *
+ * While a move is live the widget follows the pointer and a dashed outline
+ * marks the cells it would take. A resize has no outline: the widget itself
+ * takes the size, so the answer is the thing being pointed at. Either way,
+ * releasing persists exactly what was shown.
+ */
+
+import {
+ PointerEvent as ReactPointerEvent,
+ MouseEvent as ReactMouseEvent,
+ KeyboardEvent as ReactKeyboardEvent,
+ ReactNode,
+ useCallback,
+ useEffect,
+ useRef,
+ useState,
+} from 'react';
+import { css, styled, useTheme } from '@apache-superset/core/theme';
+import { t } from '@apache-superset/core/translation';
+import { Icons } from '@superset-ui/core/components';
+import {
+ columnWidth,
+ GridMetrics,
+ type GridDelta,
+ gridDelta,
+ movedPlacement,
+ NO_DELTA,
+ placementAt,
+ RESIZE_CORNERS,
+ type ResizeCorner,
+ resizedPlacement,
+ samePlacement,
+} from './gridGeometry';
+import {
+ insertIndex,
+ previewGrid,
+ resolveGrid,
+ swapPartner,
+ swapped,
+} from './resolveGrid';
+import { useCanvasDrag } from './useCanvasDrag';
+import { CanvasWidgetChromeContext } from './widgetChrome';
+import { useCanvasSelection } from './useCanvasSelection';
+import type { GridLayout, GridPlacement, SpanConstraints } from './types';
+
+type GestureKind = 'move' | 'resize';
+
+interface Gesture {
+ nodeId: string;
+ kind: GestureKind;
+ pointerId: number;
+ startX: number;
+ startY: number;
+ /**
+ * Where the grid sat in the viewport when the widget was grabbed.
+ *
+ * Pointer coordinates are relative to the viewport, so scrolling
+ * mid-gesture moves the content under a still pointer and the drag would
+ * report no movement at all. The grid's own position is what this measures
+ * against rather than the page's scroll offset: the canvas does not
+ * necessarily scroll the window -- with the chat panel open the shell is
+ * locked and the content scrolls inside it -- and the grid's rect moves for
+ * any scrolling ancestor, the window included.
+ */
+ startLeft: number;
+ startTop: number;
+ dx: number;
+ dy: number;
+ /**
+ * Where the pointer was last seen. Scrolling moves the content without
+ * moving the pointer, so recomputing then needs the position it held.
+ */
+ lastX: number;
+ lastY: number;
+ /**
+ * Where the widget sat when it was grabbed. The gesture resolves against
+ * this, not against the current placement: a write landing mid-gesture (a
+ * sibling's drop pushing this one down, or a draft poll) would otherwise
+ * move the ground under the pointer and persist the drop relative to a row
+ * the user never aimed at.
+ */
+ origin: GridPlacement;
+ /**
+ * Whether this gesture is actually dragging yet. One begun on a handle is
+ * armed at once; one begun on the widget body waits until the pointer has
+ * travelled `DRAG_THRESHOLD`, so a press that turns out to be a click
+ * reaches the widget underneath instead of nudging it.
+ */
+ armed: boolean;
+ /**
+ * The element the press landed on, so a gesture that arms later can take
+ * the pointer from it. Held rather than looked up when it arms: by then the
+ * pointer may be over something else entirely.
+ */
+ capture: HTMLElement;
+ /**
+ * Where inside the widget it was grabbed, in pixels. A drop into another
+ * grid lands the widget relative to this, so it keeps its hold on the
+ * pointer instead of jumping its own corner under it.
+ */
+ grabX: number;
+ grabY: number;
+ /** For a resize, the corner being dragged; the opposite one stays put. */
+ corner: ResizeCorner;
+ /** The grid's height when it was grabbed; see `Grid`'s `heldHeight`. */
+ heldHeight: number;
+}
+
+/** Pixels of travel before a press on a widget body becomes a drag. */
+const DRAG_THRESHOLD = 4;
+
+/** What each arrow key asks for, in whole cells. */
+const ARROW_STEPS: Record<string, GridDelta> = {
+ ArrowLeft: { cols: -1, rows: 0 },
+ ArrowRight: { cols: 1, rows: 0 },
+ ArrowUp: { cols: 0, rows: -1 },
+ ArrowDown: { cols: 0, rows: 1 },
+};
+
+/**
+ * Presses already claimed by a grid, so one that bubbles through nested grids
+ * starts exactly one gesture: the innermost grid's.
+ */
+const claimedPresses = new WeakSet<Event>();
+
+/**
+ * Controls whose press and whose click are both their own: a form control, a
+ * slider, a link, a button. Pressing one is about the control, and so is
+ * clicking it -- neither moves the widget holding it, and neither selects it.
+ */
+const CONTROLS = [
+ 'input',
+ 'textarea',
+ 'select',
+ 'button',
+ 'a[href]',
+ '[role="slider"]',
+ /*
+ * A button inside the widget, but never the widget's own press surface,
+ * which is itself a button so it can be selected and reached by keyboard.
+ * `closest` would match it from any press within it -- and `contains`
+ * counts an element as containing itself -- so without the exclusion every
+ * press on a body would be read as a control's and body drag would quietly
+ * stop working, leaving only the handles.
+ */
+ '[role="button"]:not([data-canvas-selectable])',
+ '[contenteditable=""]',
+ '[contenteditable="true"]',
+ '[role="scrollbar"]',
+];
+
+/** A control's click is its own, so it is not also a selection. */
+const OWN_CLICK = CONTROLS.join(',');
+
+/**
+ * What a press must not be read as a drag on, which is the controls plus two
+ * more: something the page itself drags, and anything a widget has opted out
+ * with `data-canvas-no-drag`.
+ *
+ * Wider than `OWN_CLICK` on purpose. A chart marks itself, because its click
+ * target is a pixel on a canvas element with nothing for a selector to match
+ * -- but its body *is* the whole widget, so if the marker also stopped it
+ * being selected there would be nowhere left to click. A widget that means to
+ * consume the click as well stops the click itself.
+ */
+const OWN_GESTURE = [
+ ...CONTROLS,
+ '[draggable="true"]',
+ '[data-canvas-no-drag]',
+].join(',');
+
+/**
+ * Whether a press landed on a scrollbar rather than inside the content.
+ *
+ * A scrollbar belongs to the element it scrolls and dragging it scrolls, so a
+ * widget tall enough to scroll -- a table, usually -- would otherwise be
+ * impossible to scroll by hand in a plan. `clientWidth`/`clientHeight` stop
+ * short of the scrollbar, so a press past either is on it; the comparison is
+ * skipped for an element that isn't overflowing, which has no scrollbar to
+ * press. A left-hand scrollbar (RTL) is not detected.
+ */
+const onScrollbar = (
+ target: Element,
+ clientX: number,
+ clientY: number,
+): boolean => {
+ const box = target.getBoundingClientRect();
+ return (
+ (target.scrollHeight > target.clientHeight &&
+ clientX > box.left + target.clientWidth) ||
+ (target.scrollWidth > target.clientWidth &&
+ clientY > box.top + target.clientHeight)
+ );
+};
+
+/**
+ * Whether something inside the widget owns this event, so the grid doesn't.
+ *
+ * `selector` says which question is being asked: `OWN_GESTURE` for a press
+ * that must not become a drag, `OWN_CLICK` for a click that must not become a
+ * selection. They are not the same set.
+ */
+const ownedBy = (
+ event: ReactMouseEvent<HTMLElement>,
+ selector: string,
+): boolean => {
+ const { target } = event;
+ if (!(target instanceof Element)) return false;
+ const owner = target.closest(selector);
+ // Bounded to this widget: a control that happens to sit above the grid in
+ // the page isn't what the press landed on.
+ return (
+ (owner !== null && event.currentTarget.contains(owner)) ||
+ onScrollbar(target, event.clientX, event.clientY)
+ );
+};
+
+/**
+ * A gesture's movement across the grid, scrolling included.
+ *
+ * `left`/`top` are where the grid sits in the viewport now. Content scrolling
+ * under a still pointer moves the grid's rect, and the widget has travelled by
+ * that much relative to the grid even though the pointer has not moved.
+ */
+const travelled = (
+ gesture: Gesture,
+ clientX: number,
+ clientY: number,
+ left: number,
+ top: number,
+) => ({
+ dx: clientX - gesture.startX - (left - gesture.startLeft),
+ dy: clientY - gesture.startY - (top - gesture.startTop),
+});
+
+/**
+ * What an empty container shows instead of nothing.
+ *
+ * A container with no children is a box of blank space: it accepts a drop
+ * anywhere inside it, and says so nowhere. Absolute rather than a grid cell,
+ * so it covers the container's whole area however many rows that is.
+ */
+const EmptyDrop = styled.div<{ $active: boolean }>`
+ ${({ theme, $active }) => css`
+ position: absolute;
+ inset: 0;
+ pointer-events: none;
+ display: flex;
+ align-items: center;
+ justify-content: center;
+ border-radius: ${theme.borderRadius}px;
+ border: 1px dashed
+ ${$active ? theme.colorPrimary : theme.colorBorderSecondary};
+ background: ${$active ? theme.colorPrimaryBg : 'transparent'};
+ color: ${$active ? theme.colorPrimary : theme.colorTextTertiary};
+ transition: background ${theme.motionDurationMid};
+ `}
+`;
+
+const Grid = styled.div<GridMetrics & { heldHeight?: number; $fill?: boolean
}>`
+ display: grid;
+ /* So an empty container's invitation can cover it. Safe: the handles and a
+ widget's controls anchor to their own cell, which is positioned. */
+ position: relative;
+ /*
+ * Inside a container, the grid takes the room the container has left after
+ * its own chrome, rather than only the rows its children fill. That is what
+ * makes the empty space below them part of the grid -- to drop into, and to
+ * measure the real row count from.
+ */
+ ${({ $fill }) => $fill && 'flex: 1 1 auto; min-height: 0;'}
+ grid-template-columns: repeat(${({ columns }) => columns}, minmax(0, 1fr));
+ grid-auto-rows: ${({ rowUnit }) => rowUnit}px;
+ gap: ${({ gap }) => gap}px;
+ /*
+ * Held at the height it had when the gesture started, for as long as the
+ * gesture lasts.
+ *
+ * The preview reflows the grid on every move, and dragging a widget up can
+ * leave it needing fewer rows. Shrinking it while the view is scrolled near
+ * the bottom makes the browser clamp the scroll position, which slides the
+ * content under a still pointer -- and since travel is measured against the
+ * grid's own position, that feeds straight back into the preview, which
+ * reflows again. The result is a drag that fights the user, visible as the
+ * page scrolling by itself. A floor costs nothing: the grid may still grow,
+ * which is what dragging past the end needs.
+ */
+ ${({ heldHeight }) =>
+ heldHeight &&
+ `
+ min-height: ${heldHeight}px;
+ /*
+ * And the browser keeps its hands off the scroll position.
+ *
+ * Scroll anchoring adjusts scrollTop when content above the viewport
+ * changes size, to hold the visible part steady. Dragging a widget
+ * upwards reorders everything above it on every move, so the browser
+ * corrects the scroll, which moves the grid, which is what travel is
+ * measured against -- so the preview moves, which reflows again. The
+ * drag runs away on its own, and only once the target is off-screen,
+ * because that is when there is anything above to anchor to.
+ */
+ overflow-anchor: none;
+ `}
+`;
+
+const GridItem = styled.div<{
+ placement?: GridPlacement;
+ dragging?: boolean;
+ offset?: { x: number; y: number };
+}>`
+ ${({ theme, placement, dragging, offset }) => css`
+ min-width: 0;
+ min-height: 0;
+ position: relative;
+ ${
+ placement &&
+ css`
+ grid-column: ${placement.col} / span ${placement.colSpan};
+ grid-row: ${placement.row} / span ${placement.rowSpan};
+ `
+ }
+ ${
+ dragging &&
+ offset &&
+ css`
+ /* Follow the pointer without reflowing the grid under it. */
+ transform: translate(${offset.x}px, ${offset.y}px);
+ z-index: 2;
+ opacity: 0.85;
+ /*
+ * A widget draws no background of its own, so at less than full
+ * opacity the neighbours and the drop outline show through the one
+ * being dragged and it reads as sliding underneath them. The fill and
+ * the shadow are what make it read as lifted.
+ */
+ background: ${theme.colorBgContainer};
+ box-shadow: ${theme.boxShadowSecondary};
+ border-radius: ${theme.borderRadius}px;
+ `
+ }
+ `}
+`;
+
+/**
+ * Where the widget being dragged will land. No error state: the neighbours
+ * are already rendered where they will end up, so an overlap shows as them
+ * moving aside rather than as a warning colour here.
+ */
+const DropPreview = styled.div<{ placement: GridPlacement }>`
+ ${({ theme, placement }) => css`
+ grid-column: ${placement.col} / span ${placement.colSpan};
+ grid-row: ${placement.row} / span ${placement.rowSpan};
+ border: 2px dashed ${theme.colorPrimary};
+ border-radius: ${theme.borderRadius}px;
+ background: ${theme.colorPrimaryBg};
+ pointer-events: none;
+ z-index: 1;
+ `}
+`;
+
+/**
+ * Wraps a widget so its handles can sit on top of it. The handles stay hidden
+ * until the pointer is over the widget or a handle has focus, so a canvas at
+ * rest looks the same whether or not the user may edit it.
+ *
+ * Only the innermost hovered widget shows its handles and its outline:
+ * `:hover` matches every ancestor, so a container would otherwise light up
+ * alongside whichever of its children the pointer is actually over.
+ */
+const Interactive = styled.div<{
+ showBounds?: boolean;
+ $destination?: boolean;
+}>`
+ ${({ theme, showBounds, $destination }) => css`
+ height: 100%;
+ position: relative;
+ border-radius: ${theme.borderRadius}px;
+ transition: box-shadow ${theme.motionDurationMid};
+
+ ${
+ showBounds &&
+ css`
+ /*
+ * Every widget shows its edges while a drag is running, containers
+ * included. A drop target you cannot see is one you cannot aim at, and
+ * revealing a widget only once the pointer is near it tells you where
+ * it is just as you arrive.
+ *
+ * The container the widget would land in says so louder: "where could
+ * this go" and "where is it going" are different questions, and the
+ * second one has one answer.
+ */
+ box-shadow: ${
+ $destination
+ ? `0 0 0 2px ${theme.colorPrimary}`
+ : `0 0 0 1px ${theme.colorBorderSecondary}`
+ };
+ `
+ }
+
+ /*
+ * Selected is the same as hovered, for as long as it is selected: the
+ * grip, the four corners and the widget's own controls stay where they
+ * can be seen and aimed at, rather than only while the pointer happens
+ * to be over them.
+ */
+ &[aria-pressed='true'] > .canvas-handle {
+ opacity: 1;
+ pointer-events: auto;
+ }
+
+ /* Chrome is only made visible, never clickable as a whole: the layer is
+ transparent to the pointer on purpose, and what it holds takes its own
+ presses. */
+ &[aria-pressed='true'] > .canvas-chrome {
+ opacity: 1;
+ }
+
+ /* Direct children only: hovering a container must not reveal the
+ handles of every widget nested inside it. */
+ & > .canvas-handle {
+ opacity: 0;
+ /*
+ * Transparent is not absent: without this a hidden handle still wins
+ * the hit test over whatever it happens to sit above.
+ */
+ pointer-events: none;
+ transition: opacity ${theme.motionDurationMid};
+ }
+
+ &:hover:not(:has(.canvas-interactive:hover)) {
+ /* Borderless widgets (a metric tile, say) otherwise give no clue which
+ widget the handles belong to. */
+ box-shadow: 0 0 0 1px ${theme.colorBorder};
+ }
+
+ &:hover:not(:has(.canvas-interactive:hover)) > .canvas-handle,
+ & > .canvas-handle:focus-visible {
+ opacity: 1;
+ pointer-events: auto;
+ }
+
+ /* A widget's own chrome appears on the same terms as the handles, and
+ stays while its menu is open. */
+ & > .canvas-chrome {
+ opacity: 0;
+ transition: opacity ${theme.motionDurationMid};
+ }
+
+ &:hover:not(:has(.canvas-interactive:hover)) > .canvas-chrome,
+ & > .canvas-chrome:focus-within,
+ & > .canvas-chrome:has(.ant-dropdown-open) {
+ opacity: 1;
+ }
+ `}
+`;
+
+/** Step between a container's handles and its children's, in size units. */
+const HANDLE_STEP = 8;
+/** Size units a handle itself needs, so an offset can leave room for it. */
+const HANDLE_BOX = 7;
+
+/**
+ * How far a nested grid's handles sit from the widget's edge.
+ *
+ * Nesting steps the offset so a container's handle never lands exactly on its
+ * child's, but it is clamped to the widget's own rendered box: pushing past
+ * that would put the handle over the *next* widget, where it would take
+ * presses meant for that one.
+ */
+const handleOffset = (
+ sizeUnit: number,
+ depth: number,
+ extent: number,
+): number => {
+ const room = Math.max(sizeUnit, extent - sizeUnit * HANDLE_BOX);
+ return Math.min(sizeUnit * (1 + depth * HANDLE_STEP), room);
+};
+
+/**
+ * Whether a widget's handles have a container's handles to clear.
+ *
+ * Only the child sitting under them does. A container's handles are at the
+ * top right of its box, and its box begins where its first row of children
+ * does -- so a child in that row, reaching the container's right edge, would
+ * paint over them and make the container ungrabbable. Every other child has
+ * nothing to clear, and stepping it down would strand its handles in the
+ * middle of the widget for no reason.
+ */
+export const stepsAside = (
+ depth: number,
+ columns: number,
+ placement: { row: number; col: number; colSpan: number } | undefined,
+): boolean =>
+ depth > 0 &&
+ placement !== undefined &&
+ placement.row === 1 &&
+ placement.col + placement.colSpan - 1 >= columns;
+
+/**
+ * Where a widget's top-right controls sit: the grip, and the menu beside it.
+ *
+ * Flush with the top unless they have a container's to clear, in which case
+ * they step down far enough to leave a whole handle's worth of room.
+ */
+export const handleTop = (
+ sizeUnit: number,
+ depth: number,
+ extent: number,
+ stepped = true,
+): number =>
+ depth === 0 || !stepped ? 0 : handleOffset(sizeUnit, depth, extent);
+
+/**
+ * The widget itself, kept inside the cells it was given.
+ *
+ * A widget renders at its natural height — a table with every row, say — so
+ * without this it spills past its own box and over whatever is below. The
+ * handles are siblings rather than children, so they stay pinned to the box
+ * while the content scrolls behind them.
+ */
+const Content = styled.div<{ editable: boolean; overflow: string }>`
+ ${({ editable, overflow }) => css`
+ height: 100%;
+ overflow: ${overflow};
+ /*
+ * A stacking context of its own, so a widget's internal layering stays
+ * inside it rather than competing with the canvas. An antd table's
+ * sticky header sits at columns * 2 + 3 -- nine for three columns, and
+ * higher with every column it gains -- so it would otherwise paint over
+ * the handles and the drop outline, which sit at 3 and 1 and cannot
+ * outbid a number with no ceiling. Isolated, the header can only reach
+ * the top of this box.
+ */
+ isolation: isolate;
+ ${
+ editable &&
+ css`
+ /*
+ * Dragging across text would otherwise select it and move the widget at
+ * once. In a plan the drag wins -- arranging is what a plan is for --
+ * and the published canvas selects normally.
+ */
+ user-select: none;
+
+ /*
+ * While a widget inside this one is being *moved*, stop clipping. A
+ * child dragged towards the edge of its container is leaving the
+ * container's box, and scrolling it back into view is the opposite of
+ * what the gesture means -- it would cut the widget off at the edge
+ * and grow a scrollbar. Only an ancestor matches: the dragged widget's
+ * own content does not contain its grid cell.
+ *
+ * A resize is not a move: the widget stays inside its container, so
+ * unclipping gains nothing and costs plenty. Dropping the clip makes
+ * every scrolling widget inside render at its full height for the
+ * length of the gesture, which for a table means its rows -- and its
+ * sticky header -- spilling out over whatever is below.
+ */
+ &:has([data-dragging='true']) {
+ overflow: visible;
+ }
+ `
+ }
+ `}
+`;
+
+/**
+ * Where a widget's own controls go: over the widget, outside the box its
+ * content scrolls in.
+ *
+ * Transparent to the pointer, so it does not shadow the widget beneath it;
+ * what it holds takes presses for itself.
+ */
+const Chrome = styled.div<{ offset: number }>`
+ ${({ theme, offset }) => css`
+ position: absolute;
+ inset: 0;
+ pointer-events: none;
+
+ .canvas-widget-controls {
+ position: absolute;
+ /*
+ * The same step down the handles take, so the controls stay level with
+ * the grip at every depth. Nested, the grip moves clear of the grip of
+ * the container around it; leaving the menu behind splits what should
+ * read as one row.
+ */
+ top: ${offset}px;
+ /*
+ * Clear of the widget's right edge, where both the resize handle and a
+ * scrollbar live. See WithQuery, which uses the same inset when it
+ * renders in place.
+ */
+ right: ${theme.sizeUnit * 5}px;
+ pointer-events: auto;
+ }
+ `}
+`;
+
+/**
+ * What a widget's box does with anything that does not fit.
+ *
+ * An ordinary widget renders at its natural height -- a table with every row
+ * -- and scrolls. A container does not: what it holds is placed in its own
+ * grid, bounded by the container's rows, so there is nothing below to scroll
+ * to, and a scrollbar inside a group reads as a widget with more in it, which
+ * is never true. While a drag is running it does not clip either: a widget on
+ * its way out of a container is over it, not in it, and cutting it in half at
+ * the border hides the thing being aimed.
+ */
+export const overflowFor = (container: boolean, dragging: boolean): string => {
+ if (!container) return 'auto';
+ return dragging ? 'visible' : 'hidden';
+};
+
+/**
+ * A widget's content, and the node its chrome renders into.
+ *
+ * The two are siblings so chrome escapes the content's scrolling, clipping
+ * and stacking; see `CanvasWidgetChromeContext`.
+ */
+function WidgetBody({
+ editable,
+ offset,
+ overflow,
+ children,
+}: {
+ editable: boolean;
+ /** Where the handles sit, so the chrome can sit level with them. */
+ offset: number;
+ /** How this widget's box treats what does not fit; see `overflowFor`. */
+ overflow: string;
+ children: ReactNode;
+}) {
+ const [chrome, setChrome] = useState<HTMLDivElement | null>(null);
+ return (
+ <>
+ <Content editable={editable} overflow={overflow}>
+ <CanvasWidgetChromeContext.Provider value={chrome}>
+ {children}
+ </CanvasWidgetChromeContext.Provider>
+ </Content>
+ <Chrome ref={setChrome} className="canvas-chrome" offset={offset} />
+ </>
+ );
+}
+
+/**
+ * The mark on the selected widget.
+ *
+ * A sibling of the content rather than an outline on the box around it: the
+ * content sets `isolation: isolate`, so anything it stacks internally paints
+ * after its parent's outline, and a chart's canvas or a table's sticky header
+ * would draw straight over it. An inset shadow takes no space, so selecting a
+ * widget moves nothing on screen.
+ */
+const Selected = styled.div<{ depth: number }>`
+ ${({ theme, depth }) => css`
+ position: absolute;
+ inset: 0;
+ pointer-events: none;
+ border-radius: ${theme.borderRadius}px;
+ box-shadow: inset 0 0 0 2px ${theme.colorPrimary};
+ /* The same ladder the handles climb, so the innermost selection wins a
+ shared edge. */
+ z-index: ${3 + depth};
+ `}
+`;
+
+const Grip = styled.button<{ depth: number; offset: number }>`
+ ${({ theme, depth, offset }) => css`
+ position: absolute;
+ /* Flush with the top, beside the widget's own controls and the resize
+ corners, unless it has a container's grip to clear; see stepsAside. */
+ top: ${offset}px;
+ /* Deeper handles above shallower ones: the innermost wins a shared spot.
*/
+ z-index: ${3 + depth};
+ /*
+ * Left of both the north-east resize corner (4 units at the corner) and a
+ * widget's own controls, which step aside to 5 units while a plan is open
+ * and are 8 units wide (see WithQuery's .canvas-widget-controls). These
+ * handles sit above them in the stack, so overlapping would swallow
+ * presses meant for the menu.
+ */
+ right: ${theme.sizeUnit * 14}px;
+ display: flex;
+ align-items: center;
+ justify-content: center;
+ /* The same box as the controls button beside it, so the two line up. */
+ width: ${theme.sizeUnit * 8}px;
+ height: ${theme.sizeUnit * 8}px;
+ padding: 0;
+ border: none;
+ background: none;
+ color: ${theme.colorTextSecondary};
+ cursor: grab;
+ touch-action: none;
+
+ &:active {
+ cursor: grabbing;
+ }
+ `}
+`;
+
+/** Human-readable names for the four corners, for the handle labels. */
+const CORNER_NAMES: Record<ResizeCorner, () => string> = {
+ nw: () => t('top left'),
+ ne: () => t('top right'),
+ sw: () => t('bottom left'),
+ se: () => t('bottom right'),
+};
+
+const ResizeCorner = styled.button<{
+ corner: ResizeCorner;
+ depth: number;
+ extent: number;
+}>`
+ ${({ theme, corner, depth, extent }) => {
+ const west = corner === 'nw' || corner === 'sw';
+ const north = corner === 'nw' || corner === 'ne';
+ /*
+ * Stepped like the grip: a container's box shares its edges with its
+ * first and last child's, and the container's handles paint later, so
+ * sharing the pixel would make the child's corner unreachable.
+ */
+ const inset =
+ depth === 0 ? 0 : handleOffset(theme.sizeUnit, depth - 1, extent);
+ return css`
+ position: absolute;
+ ${west ? 'left' : 'right'}: ${inset}px;
+ ${north ? 'top' : 'bottom'}: ${inset}px;
+ z-index: ${3 + depth};
+ width: ${theme.sizeUnit * 4}px;
+ height: ${theme.sizeUnit * 4}px;
+ padding: 0;
+ border: none;
+ background: transparent;
+ cursor: ${west === north ? 'nwse-resize' : 'nesw-resize'};
+ touch-action: none;
+
+ /* A two-line corner, the conventional resize affordance. */
+ &::after {
+ content: '';
+ position: absolute;
+ ${west ? 'left' : 'right'}: ${theme.sizeUnit / 2}px;
+ ${north ? 'top' : 'bottom'}: ${theme.sizeUnit / 2}px;
+ width: ${theme.sizeUnit * 2}px;
+ height: ${theme.sizeUnit * 2}px;
+ border-${west ? 'left' : 'right'}: 2px solid ${theme.colorIcon};
+ border-${north ? 'top' : 'bottom'}: 2px solid ${theme.colorIcon};
+ }
+ `;
+ }}
+`;
+
+/** The grid's content width, kept current as the viewport changes. */
+function useElementWidth(): [(element: HTMLDivElement | null) => void, number]
{
+ const [element, setElement] = useState<HTMLDivElement | null>(null);
+ const [width, setWidth] = useState(0);
+
+ useEffect(() => {
+ if (!element) return undefined;
+ const measure = () => setWidth(element.clientWidth);
+ measure();
+ if (typeof ResizeObserver === 'undefined') return undefined;
+ const observer = new ResizeObserver(measure);
+ observer.observe(element);
+ return () => observer.disconnect();
+ }, [element]);
+
+ return [setElement, width];
+}
+
+export interface CanvasGridSurfaceProps {
+ childIds: string[];
+ columns: number;
+ gap: number;
+ rowUnit: number;
+ placements: Record<string, GridPlacement>;
+ /**
+ * Each child's stored layout. The preview resolves from these, as the
+ * server does: an auto-placed child has no `col`/`row`, and resolving from
+ * the rectangle it currently occupies would pin it there in the preview
+ * while the server still places it freely.
+ */
+ layouts: Record<string, GridLayout>;
+ constraints: Record<string, SpanConstraints>;
+ /** Whether the user may drag and resize these widgets. */
+ editable: boolean;
+ /**
+ * How deeply this grid is nested. A container's box begins where its first
+ * child's does and its handles paint last, so without an offset per level a
+ * container's grip would sit over its child's and swallow the click.
+ */
+ depth: number;
+ /** The container this grid lays out; the root grid's own id for the root. */
+ parentId: string;
+ /** Whether a child holds a grid of its own, and so is bounded, not
scrolled. */
+ isContainer?: (nodeId: string) => boolean;
+ /** What to call a widget out loud, for the selection's accessible name. */
+ labelOf?: (nodeId: string) => string;
+ onPlace: (nodeId: string, placement: GridPlacement) => void;
+ /**
+ * Persist two widgets exchanging places, which is what a drop landing
+ * squarely on one widget does.
+ */
+ onSwap: (
+ nodeId: string,
+ placement: GridPlacement,
+ partnerId: string,
+ partnerPlacement: GridPlacement,
+ ) => void;
+ /**
+ * Persist a widget dragged into this grid from another one. `index` is
+ * where it belongs in this grid's reading order.
+ */
+ onMove: (
+ nodeId: string,
+ parent: string,
+ index: number,
+ placement: GridPlacement,
+ ) => void;
+ renderNode: (nodeId: string) => ReactNode;
+}
+
+export default function CanvasGridSurface({
+ childIds,
+ columns,
+ gap,
+ rowUnit,
+ placements,
+ layouts,
+ constraints,
+ editable,
+ depth,
+ parentId,
+ isContainer = () => false,
+ labelOf = nodeId => nodeId,
+ onPlace,
+ onSwap,
+ onMove,
+ renderNode,
+}: CanvasGridSurfaceProps) {
+ const theme = useTheme();
+ const drag = useCanvasDrag();
+ const selection = useCanvasSelection();
+ const [measureGrid, width] = useElementWidth();
+ // Registered so a gesture anywhere on the canvas can find this grid under
+ // the pointer, and so this one can find the others.
+ const [gridNode, setGridNode] = useState<HTMLDivElement | null>(null);
+ // Read by another grid's drag, so it has to be current without this grid
+ // re-registering on every render.
+ const contents = useRef({ childIds, layouts });
+ contents.current = { childIds, layouts };
+ const snapshot = useCallback(() => contents.current, []);
+ useEffect(() => {
+ if (!gridNode) return undefined;
+ return drag.register({
+ parentId,
+ element: gridNode,
+ // The container this grid fills, whose box is the whole of what counts
+ // as "inside" it. The root grid has no container and is its own.
+ bounds:
+ gridNode.closest<HTMLElement>('[data-test="canvas-node"]') ?? gridNode,
+ columns,
+ gap,
+ rowUnit,
+ depth,
+ snapshot,
+ });
+ }, [drag, gridNode, parentId, columns, gap, rowUnit, depth, snapshot]);
+
+ // The grid node, for reading where it sits in the viewport mid-gesture.
+ const grid = useRef<HTMLDivElement | null>(null);
+ const gridRef = useCallback(
+ (node: HTMLDivElement | null) => {
+ grid.current = node;
+ setGridNode(node);
+ measureGrid(node);
+ },
+ [measureGrid],
+ );
+
+ /**
+ * Where the dragged widget would land in another grid, when the pointer is
+ * over one.
+ *
+ * A drag only sends `place` while the widget stays put, so without this a
+ * widget cannot leave its container -- dropping a tile below its group just
+ * grows the group. The destination is whichever grid is under the pointer,
+ * and the landing is computed in *its* units: the origin the gesture
+ * started from means nothing there.
+ */
+ const landingFor = useCallback(
+ (current: Gesture, clientX: number, clientY: number) => {
+ if (current.kind !== 'move') return undefined;
+ // Not into itself: a container dragged across its own footprint is
+ // still over its own grid, and asking the server to make it its own
+ // child is refused -- taking an otherwise valid reposition with it.
+ const hit = drag.gridAt(clientX, clientY, current.nodeId);
+ const over = hit?.grid;
+ if (!hit || !over || over.parentId === parentId) return undefined;
+ const metrics: GridMetrics = {
+ columns: over.columns,
+ gap: over.gap,
+ rowUnit: over.rowUnit,
+ };
+ // Placed against the same box it was found by, so detection and the
+ // drop cannot disagree about where the grid is.
+ const placement = placementAt(
+ clientX,
+ clientY,
+ current.grabX,
+ current.grabY,
+ { left: hit.left, top: hit.top, width: hit.width },
+ metrics,
+ current.origin,
+ columns,
+ );
+ // Its place in the destination's reading order, by the rule the server
+ // applies on the drop.
+ const there = over.snapshot();
+ const resolved = resolveGrid(
+ there.childIds.map(id => there.layouts[id] ?? {}),
+ over.columns,
+ );
+ return {
+ nodeId: current.nodeId,
+ parentId: over.parentId,
+ placement,
+ index: insertIndex(resolved, placement),
+ };
+ },
+ [drag, parentId],
+ );
+
+ /**
+ * Where the grid sits in the viewport. Falls back to the gesture's own
+ * origin when the node has gone, so a vanished grid reports no scrolling
+ * rather than a jump to zero.
+ */
+ const originOf = useCallback((gesture: Gesture) => {
+ const box = grid.current?.getBoundingClientRect();
+ return box
+ ? { left: box.left, top: box.top }
+ : { left: gesture.startLeft, top: gesture.startTop };
+ }, []);
+ const [gesture, setGesture] = useState<Gesture>();
+ // The handlers read the gesture directly, so committing never runs as a
+ // side effect inside a state updater.
+ const live = useRef<Gesture>();
+
+ const update = useCallback((next: Gesture | undefined) => {
+ live.current = next;
+ setGesture(next);
+ }, []);
+
+ /** Where `from` would land given a pointer delta, in whole grid units. */
+ const targetOf = useCallback(
+ (
+ nodeId: string,
+ kind: GestureKind,
+ from: GridPlacement,
+ dx: number,
+ dy: number,
+ corner: ResizeCorner = 'se',
+ ) => {
+ const metrics: GridMetrics = { columns, gap, rowUnit };
+ const delta = width > 0 ? gridDelta(dx, dy, width, metrics) : NO_DELTA;
+ return kind === 'move'
+ ? movedPlacement(from, delta, columns)
+ : resizedPlacement(from, delta, columns, constraints[nodeId], corner);
+ },
+ [width, columns, gap, rowUnit, constraints],
+ );
+
+ /**
+ * Persists `next` for `nodeId`, where `from` is the placement the gesture
+ * resolved against.
+ *
+ * Both no-op checks matter. A gesture that moved nothing resolves back to
+ * `from`, and sending that would write the geometry the widget had when it
+ * was grabbed over anything that landed while the button was held -- a plain
+ * click on a handle would revert a draft poll or another editor's resize.
+ * Comparing with the current placement then drops a gesture that happens to
+ * land exactly where the widget already sits.
+ */
+ const commit = useCallback(
+ (
+ nodeId: string,
+ next: GridPlacement | undefined,
+ from: GridPlacement,
+ kind: GestureKind,
+ ) => {
+ const placement = placements[nodeId];
+ if (!next || !placement) return;
+ if (samePlacement(next, from) || samePlacement(next, placement)) return;
+ // Landing squarely on one widget exchanges places with it: it takes
+ // the slot this one came from. Anything less definite -- empty space,
+ // or straddling two -- still pushes the widgets below it down. Only a
+ // move: growing a widget over its neighbour is not an offer to trade
+ // places with it.
+ const partner =
+ kind === 'move'
+ ? swapPartner(childIds, placements, nodeId, next)
+ : undefined;
+ if (partner) {
+ onSwap(
+ nodeId,
+ next,
+ partner,
+ swapped(placements[partner], from, columns),
+ );
+ return;
+ }
+ onPlace(nodeId, next);
+ },
+ [onPlace, onSwap, placements, childIds, columns],
+ );
+
+ const begin =
+ (
+ nodeId: string,
+ kind: GestureKind,
+ armed = true,
+ corner: ResizeCorner = 'se',
+ ) =>
+ (event: ReactPointerEvent<HTMLElement>) => {
+ if (event.button !== 0) return;
+ // React routes events from a portalled child through this handler even
+ // though it renders outside this subtree, so a press inside a modal the
+ // widget opened arrives here looking like a press on the widget. The
+ // DOM knows better than the React tree does.
+ if (
+ !(event.target instanceof Node) ||
+ !event.currentTarget.contains(event.target)
+ ) {
+ return;
+ }
+ // Only a deferred press is checked. A handle press is unambiguous, and
+ // a handle is itself a button, so checking it would reject every one.
+ if (!armed && ownedBy(event, OWN_GESTURE)) return;
+ // One gesture at a time. A second finger on another handle also reports
+ // button 0, and letting it replace the live gesture would strand the
+ // first pointer: its move and up events fail the pointerId guards, so
+ // its drag would be dropped without ever being committed.
+ if (live.current) return;
+ const origin = placements[nodeId];
+ if (!origin) return;
+ // A deferred press does not stop propagation -- a click has to reach
+ // the widget -- so it bubbles to this grid and to every grid containing
+ // it, and each would start its own gesture. The innermost runs first
+ // and claims the press; the rest stand down.
+ if (claimedPresses.has(event.nativeEvent)) return;
+ claimedPresses.add(event.nativeEvent);
+ // Pin where every grid is, before any preview starts moving them: a
+ // container has to stay where the user is aiming rather than being
+ // pushed along with the rest of its grid. At the press, because that is
+ // the last moment the targets are where the user aimed.
+ drag.freeze();
+ // A handle press is a drag from the start; a press on the body is a
+ // click until it travels, and says so at the threshold instead.
+ if (armed) drag.arm();
+ // Where the grid sits now, so later moves can tell scrolling apart from
+ // pointer travel.
+ const box = grid.current?.getBoundingClientRect();
+ if (armed) {
+ event.preventDefault();
+ event.stopPropagation();
+ // A handle owns the pointer from the first move. A deferred press
+ // must not, or the release and the click after it would be
+ // retargeted here from whatever was actually pressed.
+ event.currentTarget.setPointerCapture(event.pointerId);
+ }
+ update({
+ nodeId,
+ kind,
+ pointerId: event.pointerId,
+ startX: event.clientX,
+ startY: event.clientY,
+ startLeft: box?.left ?? 0,
+ startTop: box?.top ?? 0,
+ // Measured against where the widget sits in this grid, which is the
+ // only place its origin means anything.
+ grabX:
+ event.clientX -
+ ((box?.left ?? 0) +
+ (origin.col - 1) *
+ (columnWidth(width, { columns, gap, rowUnit }) + gap)),
+ grabY:
+ event.clientY -
+ ((box?.top ?? 0) + (origin.row - 1) * (rowUnit + gap)),
+ dx: 0,
+ dy: 0,
+ lastX: event.clientX,
+ lastY: event.clientY,
+ origin,
+ armed,
+ capture: event.currentTarget,
+ corner,
+ heldHeight: grid.current?.offsetHeight ?? 0,
+ });
+ };
+
+ /**
+ * A live gesture is moved and released from the window, not from the widget
+ * it started on.
+ *
+ * An unarmed body press holds no pointer capture -- it has to let a click
+ * through to the widget -- so its events go wherever the pointer is: over a
+ * neighbour, outside the grid, or onto a child that stops them. None of
+ * those reach the widget that was pressed, so it would never see the
+ * release, and since only one gesture may be live at a time the grid would
+ * then refuse every later drag and resize. The window sees every pointer
+ * event, captured or not, which makes it the one place a gesture can always
+ * be released from. It is also how a fast drag arms at all: the first move
+ * after the press can already be well outside the widget.
+ */
+ const gestureLive = gesture !== undefined;
+ useEffect(() => {
+ if (!gestureLive) return undefined;
+
+ const onPointerMove = (event: PointerEvent) => {
+ const { current } = live;
+ if (!current || current.pointerId !== event.pointerId) return;
+ const at = originOf(current);
+ const moved = travelled(
+ current,
+ event.clientX,
+ event.clientY,
+ at.left,
+ at.top,
+ );
+ /*
+ * A deferred gesture arms only once the *pointer* has really travelled.
+ *
+ * Measured from where the press landed, not from `moved`, which folds
+ * in how far the content has scrolled since. Holding a widget and
+ * wheel-scrolling a few rows without moving the hand would otherwise
+ * put the threshold behind you, so the next pixel of pointer movement
+ * arms a drag the user never began -- and releasing writes it.
+ */
+ const armed =
+ current.armed ||
+ Math.hypot(
+ event.clientX - current.startX,
+ event.clientY - current.startY,
+ ) >= DRAG_THRESHOLD;
+ if (!armed) return;
+ if (!current.armed) {
+ // It is a drag after all. The canvas is told here rather than at the
+ // press, so a plain click does not flash every widget's edges.
+ drag.arm();
+ if (current.capture.isConnected) {
+ // Take the pointer from here on. Capturing on the press instead
+ // would retarget the release and the click after it, and the
+ // widget's own controls would never fire.
+ current.capture.setPointerCapture(current.pointerId);
+ }
+ }
+ update({
+ ...current,
+ ...moved,
+ lastX: event.clientX,
+ lastY: event.clientY,
+ armed,
+ });
+ // Over another grid? Then that grid shows the drop, and this one
+ // reflows as though the widget had already left.
+ drag.setLanding(landingFor(current, event.clientX, event.clientY));
+ };
+
+ /**
+ * Scrolling moves the content under a still pointer, so the widget has
+ * travelled even though no pointer event fires. The release folds that in,
+ * so without this the drop would land somewhere the preview never showed.
+ *
+ * Only an armed gesture follows it: a press held while the user scrolls is
+ * not a drag, and arming on scroll alone would move a widget the user only
+ * meant to scroll past.
+ */
+ const onScroll = () => {
+ const { current } = live;
+ if (!current || !current.armed) return;
+ const at = originOf(current);
+ update({
+ ...current,
+ ...travelled(current, current.lastX, current.lastY, at.left, at.top),
+ });
+ };
+
+ const onUp = (event: PointerEvent) => {
+ const { current } = live;
+ if (!current || current.pointerId !== event.pointerId) return;
+ update(undefined);
+ // Where it landed, from the release event's own position: the pointer
+ // can travel between the last move and the release, and the drop
+ // belongs where the user let go.
+ const landed = current.armed
+ ? landingFor(current, event.clientX, event.clientY)
+ : undefined;
+ drag.setLanding(undefined);
+ drag.release();
+ if (!current.armed) return;
+ if (landed) {
+ // It left its container, which the server takes as a different
+ // operation: the layout alone cannot say where a widget now lives.
+ onMove(landed.nodeId, landed.parentId, landed.index, landed.placement);
+ return;
+ }
+ const at = originOf(current);
+ const { dx, dy } = travelled(
+ current,
+ event.clientX,
+ event.clientY,
+ at.left,
+ at.top,
+ );
+ commit(
+ current.nodeId,
+ targetOf(
+ current.nodeId,
+ current.kind,
+ current.origin,
+ dx,
+ dy,
+ current.corner,
+ ),
+ current.origin,
+ current.kind,
+ );
+ };
+
+ // Only the pointer that owns the gesture may cancel it, so a second
+ // pointer going away elsewhere doesn't discard this one.
+ const onCancel = (event: PointerEvent) => {
+ const { current } = live;
+ if (!current || current.pointerId !== event.pointerId) return;
+ update(undefined);
+ drag.setLanding(undefined);
+ drag.release();
+ };
+
+ // Capture phase, so these run before anything in the document: a widget
+ // that stops `pointerup` for its own reasons would otherwise keep the
+ // release from ever reaching here.
+ window.addEventListener('pointermove', onPointerMove, true);
+ window.addEventListener('pointerup', onUp, true);
+ window.addEventListener('pointercancel', onCancel, true);
+ // Capture phase for `scroll` as well, which does not bubble: a listener
+ // here still sees a scroll on any element on its way down.
+ window.addEventListener('scroll', onScroll, true);
+ return () => {
+ window.removeEventListener('pointermove', onPointerMove, true);
+ window.removeEventListener('pointerup', onUp, true);
+ window.removeEventListener('pointercancel', onCancel, true);
+ window.removeEventListener('scroll', onScroll, true);
+ };
+ }, [gestureLive, commit, targetOf, update, drag, landingFor, onMove]);
+
+ // A gesture whose node stops being placeable, or that editing has stopped
+ // allowing, can never be released by its own handle: that handle is gone,
+ // so its up and cancel events never fire. Without this the gesture would
+ // persist, leaving the drop preview on screen and -- because only one
+ // gesture may be live at a time -- blocking every later drag and resize.
+ useEffect(() => {
+ const { current } = live;
+ if (!current) return;
+ // `childIds` as well as `placements`: placements are canvas-wide, so a
+ // node moved into another container is still placed, just not here -- and
+ // its handle has unmounted, so it can never release the gesture itself.
+ if (
+ !editable ||
+ !placements[current.nodeId] ||
+ !childIds.includes(current.nodeId)
+ ) {
+ update(undefined);
Review Comment:
When a live gesture is dropped here because its node left this grid, a draft
poll removed it, or editing stopped, only the local gesture is cleared. The
pointer-up and `onCancel` paths also call `drag.setLanding(undefined)` and
`drag.release()`, so on this path `dragging` stays true (container clipping
stays off) and another grid can keep showing a stale drop preview. Drag a
widget while the draft is refetched and the widget moves into another
container: the preview and unclipped state persist until some later gesture
finishes. Should this branch release the shared drag state as well, with a test
that removes the dragged node mid-gesture and asserts the landing preview is
gone?
##########
superset-frontend/src/features/canvas/useCanvasSelection.test.ts:
##########
@@ -0,0 +1,89 @@
+/**
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+import { act, renderHook } from '@testing-library/react';
+import type { GridPlacement } from './types';
+import { useCanvasSelectionState } from './useCanvasSelection';
+
+const KPI: GridPlacement = { col: 1, row: 1, colSpan: 6, rowSpan: 4 };
+const TREND: GridPlacement = { col: 1, row: 5, colSpan: 24, rowSpan: 8 };
+const both = { kpi: KPI, trend: TREND };
+
+const render = (
+ editable = true,
+ placements: Record<string, GridPlacement> = both,
+) =>
+ renderHook(props => useCanvasSelectionState(props), {
+ initialProps: { editable, placements },
+ });
+
+test('a widget can be selected and let go', () => {
+ const { result } = render();
+
+ act(() => result.current.select('kpi'));
+ expect(result.current.selectedId).toBe('kpi');
+
+ act(() => result.current.select());
+ expect(result.current.selectedId).toBeUndefined();
+});
+
+test('nothing is selectable unless the canvas may be edited', () => {
+ // On a published canvas a selection drives nothing, and the canvas should
+ // look the same for everyone looking at it.
+ const { result } = render(false);
+
+ act(() => result.current.select('kpi'));
+
+ expect(result.current.selectedId).toBeUndefined();
+});
+
+test('editing stopping lets the selection go', () => {
Review Comment:
This test still passes if the `!editable` clearing effect in
`useCanvasSelectionState` is deleted, because the returned `selectedId` is
already masked with `editable ? selectedId : undefined`. The stale id then
comes back when editing resumes: select `kpi`, publish (editable false), start
a new draft (editable true) and `kpi` reappears selected. Could the test
rerender back to `editable: true` with the same placements and assert
`selectedId` is still undefined?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
