DragTarget
DragTarget is the small, direct drop target helper in the widget set.
It wraps a child and dispatches one action when something is dropped on it. Use it when the important event is the completed drop itself and you do not need separate drag-enter or drag-leave handling. If you do need hover feedback or file-drop styling, use Dropzone instead.
Example
use fission::prelude::*;
let widget: Widget = DragTarget {
child: Text::new("Drop here to move").into(),
on_drop: Some(ctx.bind(
MoveCardHere,
reduce_with!((|state: &mut BoardState, _action: MoveCardHere, ctx| {
if let Some(bytes) = ctx.input.as_internal_drop() {
state.pending_drop_card_id = Some(String::from_utf8(bytes.to_vec()).unwrap());
}
})),
)),
}
.into();
The dropped payload travels through ctx.input, not through the action type itself. That keeps the drag payload explicit and lets the reducer decide how to decode it.
Field table
| | | |
|---|
| | The visible drop target surface. | |
| | Action dispatched when the runtime delivers a drop to this target. | Defaults to None. Read payloads from ReducerContext::input. |
How drop data reaches your reducer
Internal drags started by Draggable arrive as opaque bytes that you read with ctx.input.as_internal_drop(). External file drops can arrive as file paths, which you read with ctx.input.as_drop_paths(). In both cases the action itself is just the trigger; the extra drop data lives alongside it in ActionInput.
Specific advice
Keep the drag payload small and stable. A database id, path, or serialized enum is usually enough. Do not serialize half your app state into the payload just because it is available.
Production checklist
For DragTarget, review the fields that change behavior before treating the widget as finished: child, on_drop. The goal is to make the product rule visible in state and actions, not hidden inside ad-hoc construction code.
Bind on_drop to explicit reducer actions and test that the reducer handles unavailable, duplicate, or invalid input safely.
When child widgets are generated from data, give reordered or filtered rows an explicit WidgetId so retained local state and scroll behavior do not drift between items.
Check the semantics tree for the user-facing label or role that makes this widget understandable without relying only on pixels.
Add at least one component or harness test that confirms the visible text, semantic role, action dispatch, and layout constraint that matter for this widget in context.
If a screen starts repeating the same DragTarget setup, extract a named component around this widget. That keeps the reference API small while making product code easier to read and safer for generated code to copy.
Draggable, Dropzone, GestureDetector, and Overlay.