Create plan and design docs for moving `Mover` + `MoveActions` to core

[cpcallen]

This is a tracking bug for design work to move Mover and the associated MoveActions from this repository to core.

Background: moving blocks with the keyboard

One of our goals for adding keyboard accessibility to Blockly is to provide parity between keyboard-driven and mouse-driven interactions, and so earlier in 2025 we added code to the @blockly/keyboard-navigation plugin package (which now lives in this repository) to allow users to move blocks (and workspace comments) using only the keyboard, without needing to use a pointer device.

The resulting code, in src/actions/move.ts, src/actions/mover.ts, and src/block_drag_strategy.ts, was initially written as a proof-of-concept and, although it has subsequently been polished in to a quite usable implementation, its origins as a quick hack are still much in evidence: the simplest way to make sure keyboard users could do everything a mouse user could do was to (ab)use the existing dragger (and therefore draggable) implementations, even though the former was never intended to be used this way, and doing so entailed Mover generating fake PointerEvents to pass to Dragger even though no pointer activity is actually occurring—not to mention illegally accessing private fields on various core classes for good bad measure.

Moving Mover to core

As part of our efforts to make accessibility a first-class feature of Blockly, we're planning to move support for moving workspace items using the keyboard from this plugin to the core Blockly repository. Unfortunately, for the reasons outlined above, the existing code is not suitable for inclusion in core as-is, so this issue tracks the task of planning what changes we might need to make both to core Blockly and to the plugin code in order to facilitate and then implement that move.

The custom dragging APIs

At the moment both Blockly's core (pointer) dragging support allow customisation through:

• Custom draggables, which implement IDraggable,
• Custom drag strategies, which implement IDragStrategy, and
• Custom draggers, which implement IDragger.

When these APIs were designed they were focused specifically on supporting moving items using a pointer (mouse, trackpad, or touch), but provision was made for using IDraggable and IDragStrategy for programmatic moves too by making the PointerEvent parameter to many of the methods in those APIs optional. (The same is not true for IDragger: its PointerEvent parameters are required, and hence the aforementioned shenanigans.)

A large part of the work involved in moving Mover to core is to figure out to what extent Mover can be modified to make (correct, as-intended) use of the existing custom dragging APIs, and to what extent those APIs will need to be modified/enhanced to support keyboard moves.

Tasks tracked in this issue (and sub-issues):

A rough outline of the work to be done:

• Learn more about how existing apps make use of the custom dragging APIs.
  • Read relevant code in google/blockly, google/blockly-samples and google/blockly-keyboard-experimentation
  • Post on the forum to request information about external developers use of these APIs.
• Propose approach to handle keyboard events in core dragging code #722
• Design revised IDraggable / IDragStrategy API #739
• Figure out what cleanup we want to do to existing Mover, KeyboardDragStrategy before moving them, and create tracking bug(s).
  • See also Review mover design and APIs #644.
• Figure out if we should (and if so, how to) unify KeyboardDragStragegy with the existing BlockDragStrategy / BubbleDragStrategy / CommentDragStratey.
  • E.g. the (relevant parts of) KeyboardDragStrategy might become a mixin for or superclass of BlockDS / BubbleDS / CommentDS, to avoid the need to patch the drag strategy at move start time.
• Figure out in what order to move Mover et al., + move action, to core
• Create a tracking bug for moving code to core, with issues for individual tasks as appropriate.
  • Revise APIs (IDragStrategy et al).
  • Revise existing drag strategies in core to implement relevant portions of revised APIs.
  • Revise BlockSvg.prototype.getDragTarget to not require a PointerEvent?
  • Revise existing drag strategies to implement rest of revised APIs, using improved version of relevant code from KeyboardDragStrategy.
  • Update Dragger to use new API.
  • Port Mover from BKE.
  • Port Move action from BKE.
  • Delete code from BKE.

[cpcallen]

I'm now considering how to make it possible to support keyboard moves in core, while ensuring that keyboard users can benefit from any custom dragging features you may have implemented—while ensuring that we minimise developer toil.

Current usage of custom dragging APIs

This comment contains my notes about what I have learned about how the custom dragging API is currently used (in core, in this and our other plugins, and by external partners' applications)

IDragger

Notes about implementations of IDragger:

• The core Dragger implementation is responsible both for translating pointer events into move offsets (in workspace coordinates), as well as implementing "drag behaviour" such as interactions between draggables and drag targets.
• Scratch Blocks v2 usesa custom dragger to (amongst other things) allow blocks to be dragged from the workspace and dropped on top of other, non-Blockly UI elements.

IDraggable / IDragStrategy

Notes about implementations of IDraggable and IDragStrategy, and in particular about use of the PointerEvent parameter:

• The core BlockDragStrategy implementation checks for modifier keys on drag start and decides based on them whether to disconnect child blocks (heal stack).
• Scratch Blocks v2.x uses custom IDraggables to implement duplicate-on-drag for procedure parameter blocks.

  Aside: I notice I am confused about one aspect of this: class DuplicateOnDragDraggable implements IDraggable rather than IDragStrategy, even though the resulting objects are passed to this.setDragStrategy():

  • On the one hand, I expect the duplicate-on-drag to need a custom getRelativeToSurfaceXY implementation because of the way it delegates the drag to the copy.
  • On the other hand, I can't see how this ever gets called, because BlockSvg.prototype.getRelativeToSurfaceXY does not delegate to this.dragStrategy, and none of the other code in src/blocks/procedures.ts seems to call this directly either.

• In this repo, Mover uses a special KeyboardDragStrategy that temporarily replaces a block's usual drag strategy for the duration of a keyboard move.
  • KeyboardDragStrategy inherits from BlockDragStrategy and ignores the block's original .dragStrategy (stored temporarily on the Mover as .oldDragStrategy), so any custom drag strategy behaviour (such as the aforementioned duplicate-on-drag strategy used by Scratch Blocks) will not be applied for keyboard move.
  • KeyboardDragStrategy.prototype.drag the e?: PointerEvent parameter to receive up/down/left/right drag direction information that is smuggled by Mover through the Dragger as extra properties added to a fake PointerEvent, and uses this direction information to move itself to the next connection candidate when a constrained move is being performed. THis appears to be contrary to the intention of the original design of the custom dragging API, which notes that:

    The [IDragger] [not the IDraggable] handles calculating where the IDraggable should be moved to in workspace coordinates.

[cpcallen]

Possible changes to custom dragging APIs and our implementations and usages thereof

This comment contains my thoughts about possible changes we might make (to the plugin and to core, and in particular to the core custom dragging APIs) to supporting keyboard moves using those APIs.

Changes to the IDraggable / IDragStrategy API

We should consider changing the type signature of methods on IDraggable and IDragTarget in one or more of the following ways:

1. By changing their event parameter from e?: PointerEvent to e?: PointerEvent | KeyboardEvent or e?: UIEvent, we would allow custom draggers/movers to pass along user activity information in a way that would allow custom draggables / drag strategies maximum flexibility in responding to user activity.
2. By supplementing—and perhaps eventually supplanting entire—the event parameter with an options object, we would allow custom draggers (and the hopefully soon core Mover to communicate arbitrary information the draggable / drag strategy in an input-device-agnostic way. This might be something along the lines of:

   interface DragInfo {
     /** The UI event that triggered the current call to the IDraggable API, if any. */
     event?: UIEvent;
   
     /** If true, heal stack on dragStart. */
     healStack?: boolean;
   
     /** Connection candidate to use (draggable to find own if not supplied. */
     connectionCandidate?: ConnectionCandidate;
   
     /** Coordinates used when checking for interactions with drag targets.  (Screen or workspace?) */
     hotspot?: Coordinate;
   }

   Custom IDragger implementations (and other sources of move activity) could add extra properties to this options object, to communicate additional needed information to custom IDraggable / IDragStrategy implementations—though doing so in TypeScript might require casts, since it's not clear that BlockSvg can be templated on subtypes of DragInfo.

We might also make the drag strategy responsible for implementing drag features like interaction with drag targets—see below under "Move support of 'dragger back end' features to the drag strategy".

Changes to the IDragger API

No changes to IDragger are contemplated, but it might be supplemented with a new, input-device-agnostic API; see next section.

Changes to Dragger

Splitting Dragger

We might consider splitting the existing Dragger implementation into two parts:

1. The 'dragger front end', implementing IDragger, that is concerned with decoding PointerEvents and translating them into move offset, and
2. The 'dragger back end', implementing a new input-device-agnostic movement API, concerned with enacting drag behaviour (e.g. interaction with drag targets) in an input-device-agnostic way.

This would allow Mover to be rewritten so as not to (ab)use the existing IDragger API, but instead make use of a new intermediate API to use the 'dragger back end' to implement the features that it presently uses Dragger for, without the need to generate fake PointerEvents.

This change would not require developers to make any changes to existing custom IDraggable implementations, but we'd likely encourage them to migrate custom dragging behaviour to this new to that new back end API as soon as convenient, in order to ensure that their custom dragging behaviour was available to keyboard users as well.

Move support of 'dragger back end' features to the drag strategy

As an alternative to the aforementioned new 'dragger back end' API, we could split Dragger but move the responsibility for 'dragger back end' features to the drag strategy.

When I participated in the inital implementation of the custom dragging API in core, I actually proposed in a PR making the various *DragStrategy classes, rather than Dragger, implement drag features like interaction with IDragTargets.

My reasoning was that it seemed it would simplify Dragger more than it would complexify the drag strategies. I now see that this intuition was related to the dual responsibility that Dragger currently has.

The argument against this was that this would result in duplication of this code in all three of BlockDragStrategy, BubbleDragStrategy and CommentDragStrategy—though I pointed out that using a common base class could avoid this.

I think this alternate division of responsibility might be worth revisiting: this change would considerably simplify Dragger, and remove from it all the functionality that Mover presently uses. Mover could then directly communicate with IDraggables instead of going via Dragger, without losing drag features like interaction with drag targets.

This would notionally be a more substantial breaking change to the custom dragging APIs, because custom IDragStrategy implementations would need to implement (e.g.) interaction with IDragTargets—but in practice since most are likely to inherit from one of the built-in strategies (BlockDragStrategy in particular) they would probably in most cases end up getting this for free from the posited common base class.

Changes to Mover

It might be better to give Mover responsibility for deciding where to move a block to when doing a constrained move, just as it presently does for unconstrained moves. This would necessitate some way for Mover to communicate the initial / next connection candidate to the block (when dragging a block—obviously this does not apply to the other core draggables), as the existing connection-candidate machinery in BlockDragStrategy cannot be guaranteed to find the correct connection candidate based purely on the position of the moving block (hence the proposal above for a DragInfo interface with a connectionCandidate field).

Changes to KeyboardDragStrategy

Broadly I think it is desirable to move most of the current functionality of this class to other classes:

• Selection of the next connection candidate when doing constrained block moves, and positioning the moved block accordingly, should probably be moved to Mover as discussed above.
• Previewing connection candidates should be done by (a minimally modified version of) the existing machinery in the core BlockDragStrategy.

An alternative would be to keep it essentially as it is, but use the event parameter to the IDragStrategy methods to pass in KeyboardEvents instead of fake PointerEvents. Unfortunately, having KeyboardDragStrategy taking KeyboardEvents to decide on the next connection candidate when doing constrained moves would have the undesirable effect of making this responsible for mapping key strokes on to directions, when it should properly be the responsibility of the keyboard shortcuts. It would be strange to need to modify KeyboardDragStrategy to remap movement from cursor keys to WASD!

[rachel-fenichel]

THis appears to be contrary to the intention of the original design of the custom dragging API, which notes that:
The [IDragger] [not the IDraggable] handles calculating where the IDraggable should be moved to in workspace coordinates.

The problem is that we never anticipated the target location being an object, rather than a set of coordinates. And in order to know which object to move to, you need to know the type of the object being moved.

But we don't know that in the Dragger because it's supposed to be agnostic: only the Draggable (and/or its DragStrategy) knows or cares about the type of the moving object.

[rachel-fenichel]

ScratchDragger question: Why does it extend the Dragger to add dragging out of bounds, instead of just extending the DragStrategy?

[cpcallen]

I've had some conversations with teammates (notably @rachel-fenichel, who is quoted below) about the above proposals, and some questions / comments have arisen:

How are you thinking about keyboard drag for comments or bubbles, if at all?

AFAICT they don't have any equivalent of constrained moves, so the only changes that would be needed to their drag strategies would be for cosmetic things like the move indicator. This could be handled by having BlockDragStrategy, CommentDragStrategy and BubbleDragStrategy inherit from a common base class.

The only other special case (or rather, non-special case) would be that Mover would only try to do constrained moves for blocks; everything else gets unconstrained moves regardless of modifier key.

Specifically, I increasingly think that "Move support of 'dragger back end' features to the drag strategy" is the correct move
even though it makes me twitch

Putting 'dragger back end' features (e.g. interaction with drag targets) in the drag strategy would definitely simplify things on the Dragger/Mover side of the API—and using a common DragStrategy base class should eliminate the need for any significant code duplication between the strategies, while also allowing different kinds of draggables to further customise their drag behaviour (though with the tradeoff of making it easier to have unintentionally inconsistent behaviour).

This would entail a fairly substantial refactor of Dragger and the drag strategies. (But we're already considering other even more substantial refactors.)

I think most of the keyboard-specific logic needs to go into BlockDragStrategy, not Mover

I am ambivalent about this.

In favour:

• It seems to adhere to the sprit of the original custom dragging API design that "The IDragger is a generalization of block draggers and bubble draggers that treats IDraggable things generically." The whole design specifically avoided the need for Dragger to special-case handling of different kinds of draggables, but instead to allow such differentiation via different strategies. Within that framework it makes sense that handling constrained moves, which are only relevant to (and require deep knowledge of) blocks, should also be handled by BlockDragStrategy.
• This is how is KeyboardDragStrategy currently works, so though API changes and code cleanup would be required it would not involve quite as substantial changes on the Mover/Dragger side of things as the alternatives I proposed above.
• It makes it easier to fine-tune differences in keyboard vs. pointer moves—for example we could explicitly decide not to support interaction with delete targets when using the keyboard (rather than that feature merely being somewhat broken due to autoscroll).
• Also, it improves extensibility: at the moment we think only Blocks do constrained moves, but maybe in future we realise (or a developer wants) other draggables should be able to too. Having Mover special-case blocks for constrained movement would make that much more difficult to support.

Against:

• It seems contrary to the spirt (if not the letter) of the original custom dragging API design that "the IDragger handles calculating where the IDraggable should be moved to in workspace coordinates."
• The IDraggable/IDragStrategy APIs will need to be changed in order to provide a way for Mover to communicate the direction of constrained moves.
  • This should probably not just be via sending a KeyboardEvent, because really it should be the shortcut, not the strategy, that is responsible for mapping from key to direction. (Consider if we wanted to change the keys from arrows to WASD.)
  • It should probably also not be limited just to up/down/left/right, because we have at times supported other navigation shortcuts like jump-to-next-stack, and those should probably work for moves too.
• The APIs will also need to provide a way to communicate where a draggable has gone, when it has gone to a location other than those specified by the coordinates supplied to dragStart / drag / dragEnd.
  • Dragger gets the total delta from the gesture, and that's fine because it should track the pointer movement exactly, but for keyboard moves there is no similar absolute source of truth.
  • Originally the experimental DragMover implementation just kept track of the total delta itself, but when constrained dragging was added it was necessary for Mover to be able to find out where the draggable had gone in order for mixed constrained/unconstrained moves to work properly.
  • Currently this is done by Mover.prototype.updateTotalDelta(), which special-cases BlockSvg to directly access block's .relativeCoords.
  • In principle it should be possible to use IDraggable's .getRelativeToSurfaceXY() instead, but…
  • Unfortunately, both .relativeCoords and .getRelativeToSurfaceXY() have a problem: they return that block's coordinates, which is normally fine, but is with both our and Scratch's implementation of duplicate-on-drag, both of which proxy IDraggable API calls from the original block to the duplicate.
    • N.B. that Scratch's DuplicateOnDragDraggable includes a .getRelativeToSurfaceXY() that does try to delegate, but as far as I can tell this never gets called, because getRelativeToSurfaceXY is part of IDraggable but not part of IDragStrategy, so BlockSvg.prototype.getRelativeToSurfaceXY makes no effort to call this.dragStrategy.getRelativeToSurfaceXY().

Both approaches involve some changes to the IDraggable / IDragStrategy APIs, but I pitched solutions involving having Mover (rather than BlockDragStrategy) deal constrained mvoes because this seemed to reduce the overall scope of the changes to the API (the API changes were less likely to be breaking, and likely to break things less badly if they were)—but at the cost of needing special special casing blocks on the side of the system that was supposed to avoid special casing.

I'm happy to revisit that. A few additional thoughts:

• If the drag strategy is going to be responsible for deciding where to move blocks for constrained moves it probably makes sense for it to decide same for unconstrained moves too; that would mean that only for actual drags would the IDraggable be receiving a Coordinate.
• This again invites the question of whether we make breaking changes to IDraggable, or alternatively deprecate it and instead enhance IMovable with methods that are general enough to handle both mouse and keyboard moves.

but also, I keep thinking that in the context of a constrained move, a Connection is essentially a DragTarget

My reaction is 💯😱💀: this insight is both amazing and terrifying.

I agree with you and would go further: I think connections are essentially drag targets not only for constrained moves but for every kind of move including drags.

So if constrained moves are essentially snap-to-drag-target for connections, maybe they should be snap-to-drag-target for other kinds of drag targets too?

Would we contemplate a refactor so thatclass RenderedConnection implements IDragTarget?!? That is wild but maybe not entirely unreasonable.

[BenHenning]

I wonder if connections are incidentally a drag target in the perspective of specific movement strategies. Surely there could be other strategies that make sense (maybe a movement strategy for dragging and dropping blocks into a grid-like layout for organization?).

I actually want to take a step back and question what the ideal data flow is here as that helps clarify what components are useful to introduce/change and what their responsibilities should be. This is very much from the "what if we were doing this from scratch?" perspective, so it should certainly be taken with a grain of salt. To me, the dataflow roughly seems to be:

1. The platform detects that the user wishes to move a block (start dragging or initiate keyboard movement).
2. The user sends movement indication events based on how they want to move the block (pointer events or key events).
3. The events are interpreted based on the movement strategy to determine how the event should influence where the block be moved (this is where considering connections comes into play, constrained vs. unconstrained movements, and calculating coordinates).
4. The possible move location is represented visually to provide a preview to the user (using the drag layer and other visual effects).

From a datatype perspective, we basically have the following:

• Keyboard and pointer events that are filtered to calculate candidate locations for the block or other component.
• Candidate locations would be an abstraction for ultimately a coordinate. For unconstrained movement this is just the coordinate itself, but for constrained movement this coordinate could be backed by something like a connection.
• Locations can be previewed independently of the rest of the movement system. We know what component is being moved (e.g. a block) and where its current candidate location is, so it can be previewed.
• There's a way to 'save' to the location or cancel the movement operation.

I think this is largely similar to existing designs that have been discussed, but I find it a bit easier to grok myself because it emphasizes the location candidate as the key bit of data being processed which, I think, might simplify things:

• It allows abstracting dragging vs. keyboard movement very early in the pipeline (as this doesn't really need to bubble past determining how particular events determine the next location candidate for the block). I consider this to be a lot of what 'drag strategy' does now.
• It splits out previewing (i.e. managing the drag layer) from processing the events which allows the same previewing mechanism to be fully reused regardless of how the user is trying to move the block.
• It allows constrained and unconstrained movement to work in exactly the same way for previewing as well.
• It possibly allows for higher-level abstraction than blocks for introducing movement support (dragging + keyboard) for non-blocks without having separate systems.

The main drawback of this line of thinking is that it would be a fundamentally different approach than what is currently being done, and I'm not entirely sure how interoperable it could be (I suspect the existing drag API could be built with a bridge onto such a system for backward compatibility, but extensibility would surely break and need to be redone).

[rachel-fenichel]

There are two distinct movement modes happening here, with (sometimes) the ability to swap between them.

Mode 1: coordinates

In coordinate mode, the dragged object 1) moves to a location and then logic kicks in to 2) find a nearby drag target, if any exist. As a last step, 3) a preview (e.g. insertion marker) may be shown if a drag target is found.

Mode 2: objects

In object mode, the first step 1) is to find a drag target. Once a drag target has been found, 2) the dragged object is moved to a location relative to the drag target and 3) a preview may be shown.

My thoughts

Notably, step 2 of mode 2 does not mean moving directly to the location of the drag target. We offset a block from a connection to avoid visual overlap during constrained keyboard movement, but not during unconstrained keyboard movement or mouse/touch/pointer dragging.

This distinction is not only at the level of previews. We actually update the block's location and locations of its connections as we drag it around, and that information is used to calculate next steps during drags.

Currently, mouse/touch/pointer dragging operates only in mode 1. Keyboard movement can operate in both mode 1 and mode 2, and can switch between them at any time.

In my opinion, this means we have to make mouse/touch/pointer dragging more like keyboard movement, rather than trying to shoehorn keyboard movement into the existing drag code.

[rachel-fenichel]

To @cpcallen's points above:

On coordinate math and drag target handling

It seems to adhere to the sprit of the original custom dragging API design that "The IDragger is a generalization of block draggers and bubble draggers that treats IDraggable things generically." The whole design specifically avoided the need for Dragger to special-case handling of different kinds of draggables, but instead to allow such differentiation via different strategies. Within that framework it makes sense that handling constrained moves, which are only relevant to (and require deep knowledge of) blocks, should also be handled by BlockDragStrategy.

It seems contrary to the spirt (if not the letter) of the original custom dragging API design that "the IDragger handles calculating where the IDraggable should be moved to in workspace coordinates."

Obviously these two conflict, since one is in pros and one is in cons.

I think that the first one, which corresponds to generic treatment of IDraggable things, is much more important than the second. Workspace coordinates can be calculated anywhere that we have access to the object and to the workspace. Reducing duplicated code is nice, but I'd rather duplicate code in order to keep a clean line where the user of IDraggable does not know about the implementation.

This again invites the question of whether we make breaking changes to IDraggable, or alternatively deprecate it and instead enhance IMovable with methods that are general enough to handle both mouse and keyboard moves.

IMO we should make breaking changes to IDraggable and not have IMovable (because "keyboard movement" and "keyboard dragging" both work, and because IDraggable already exists, and because our keyboard movement adheres to the dragging convention of having a defined start and end with movement in the middle).

On API changes

The APIs will also need to provide a way to communicate where a draggable has gone, when it has gone to a location other than those specified by the coordinates supplied to dragStart / drag / dragEnd.

Is this true if all of the coordinate math and drag target handling moves to the DragStrategy side?

The IDraggable/IDragStrategy APIs will need to be changed in order to provide a way for Mover to communicate the direction of constrained moves.

Agree. I like your idea of passing an object rather than the event itself.

On DragTargets

but also, I keep thinking that in the context of a constrained move, a Connection is essentially a DragTarget

They almost map, but not quite, and so I think this idea is worth flagging but not following deeply now. It would require a lot of deep changes to make this actually be true.

[cpcallen]

ScratchDragger question: Why does it extend the Dragger to add dragging out of bounds, instead of just extending the DragStrategy?

I asked @gonfunko about this. AIUI he thinks it was probably just a typo made when it was initially implemented. He mentioned adding the getRelativeToSurfaceXY method (which I believe is never actually called) just to satisfy tsc when this code was migrated from JS to TS, but I believe we agree that it should have just been an IDragStrategy, because that's how it's used.

On coordinate math and drag target handling

… "The IDragger is a generalization of block draggers and bubble draggers that treats IDraggable things generically." …

… "the IDragger handles calculating where the IDraggable should be moved to in workspace coordinates."

Obviously these two conflict, since one is in pros and one is in cons.

I think that the first one, which corresponds to generic treatment of IDraggable things, is much more important than the second. Workspace coordinates can be calculated anywhere that we have access to the object and to the workspace. Reducing duplicated code is nice, but I'd rather duplicate code in order to keep a clean line where the user of IDraggable does not know about the implementation.

My reading of of the second put the emphasis on "handles calculating where the IDraggable should be moved", not on "in workspace coordinates".

There is an elegance to the draggable never having to worry about where it is being dragged to, only how to make that happen—but a considerable amount of that elegance is lost if the dragger then needs to special-case constrained moves of blocks, and thereby loses its draggable-agnosticism.

IMO we should make breaking changes to IDraggable and not have IMovable (because "keyboard movement" and "keyboard dragging" both work, and because IDraggable already exists, and because our keyboard movement adheres to the dragging convention of having a defined start and end with movement in the middle).

I think we're mostly just discussing naming here but FWIW I suggested IMovable because:

• The new API is probably going to be very different from the current IDraggable API; it might be better to use a new name for it.
• That would allow us to leaving the IDraggable API unmodified, implemented transitionally in terms of the new API.
• The IMovable interface already exists but appears to be completely unused and contains just isMovable.
  • And what use is there to being able to test whether you can move something if the API doesn't provide a way to actually do so?

The APIs will also need to provide a way to communicate where a draggable has gone…

Is this true if all of the coordinate math and drag target handling moves to the DragStrategy side?

Probably not strictly speaking, no—but I wonder if, in the presence of drag delegation, there might be value in providing API clients with some way of finding out which draggable is actually being moved.

They almost map, but not quite, and so I think this idea is worth flagging but not following deeply now. It would require a lot of deep changes to make this actually be true.

I strongly suspect you are correct. Still: there may be value in using a common internal representation of both candidate connections and IDragTargets within BlockDragStrategy.