User story
As a PM planning on a FigJam board, when I have two GitJam cards on the same board and the underlying GitLab issues are linked (blocks / blocked_by / relates_to), the widget should automatically draw a FigJam connector between the cards with an arrowhead matching the relationship direction.
Inspiration: Miro's Jira integration does this. When you drop two linked Jira cards on a Miro board, an arrow appears between them showing the dependency.
Scope
Discovery
- Scan the current page for other GitJam widget nodes via
figma.currentPage.findAll(n => n.type === "WIDGET" && n.widgetId === OUR_WIDGET_ID).
- For each, read its
useSyncedState("card", ...) to map widget node → issue reference (project path + iid).
Link resolution
- For the active card, fetch
GET /projects/:id/issues/:iid/links.
- For each link, check whether the target issue is represented by another widget on the current page. Skip if not.
Connector creation
- For each matched pair, create a FigJam connector via
figma.createConnector().
connectorStart = source widget node via magnet "AUTO", connectorEnd = target widget node via magnet "AUTO".
- Arrow direction follows the link semantics:
blocks → arrow from blocker to blocked
is_blocked_by → same arrow inverted
relates_to → double-ended or neutral
- Connector colour / line style hints the type (e.g. red-ish for blocks, neutral grey for relates).
Stale connector cleanup
- Tag connectors created by GitJam (e.g. plugin-data on the connector:
{ gitjam: true, fromIid, toIid }).
- Before creating, check for an existing connector with the same endpoints + plugin data; skip duplicates.
- When a card is removed or its reference changes, remove the connectors we created for it.
Trigger
- Manual action on the card: "Connect related" button in the property menu.
- Possibly also on card load, but manual-first keeps surprises low.
Open questions / feasibility risks
figma.createConnector() is documented for FigJam plugins. Need to verify it's callable from a widget event handler.
- Connector
magnet positioning: "AUTO" should pick sensible edges. Verify with two cards side by side vs stacked.
- Cross-board limitation: only cards on the same page can be connected. Users who want cross-page relations see nothing.
- Large relationship graphs could create a lot of connectors – add a cap (e.g. max 10 per card) to avoid visual noise.
Prior art
- Miro Jira integration's "visualise dependencies" feature.
- The widget-typings
widgetApi.1.0.0 surface does include node-creation APIs in FigJam – to be verified in a quick spike before full implementation.
Dependencies
Builds on #19 (linked issues data is the same endpoint). Ship #19 first as the data/UX fallback, then this as the visual stretch.
Acceptance criteria
User story
As a PM planning on a FigJam board, when I have two GitJam cards on the same board and the underlying GitLab issues are linked (blocks / blocked_by / relates_to), the widget should automatically draw a FigJam connector between the cards with an arrowhead matching the relationship direction.
Inspiration: Miro's Jira integration does this. When you drop two linked Jira cards on a Miro board, an arrow appears between them showing the dependency.
Scope
Discovery
figma.currentPage.findAll(n => n.type === "WIDGET" && n.widgetId === OUR_WIDGET_ID).useSyncedState("card", ...)to map widget node → issue reference (project path + iid).Link resolution
GET /projects/:id/issues/:iid/links.Connector creation
figma.createConnector().connectorStart= source widget node via magnet"AUTO",connectorEnd= target widget node via magnet"AUTO".blocks→ arrow from blocker to blockedis_blocked_by→ same arrow invertedrelates_to→ double-ended or neutralStale connector cleanup
{ gitjam: true, fromIid, toIid }).Trigger
Open questions / feasibility risks
figma.createConnector()is documented for FigJam plugins. Need to verify it's callable from a widget event handler.magnetpositioning:"AUTO"should pick sensible edges. Verify with two cards side by side vs stacked.Prior art
widgetApi.1.0.0surface does include node-creation APIs in FigJam – to be verified in a quick spike before full implementation.Dependencies
Builds on #19 (linked issues data is the same endpoint). Ship #19 first as the data/UX fallback, then this as the visual stretch.
Acceptance criteria