ENG-1477: Convert a tldraw arrow to a DG relation#1082
Conversation
Right-click a plain tldraw arrow connecting two discourse-graph nodes to get a "Relation" submenu listing the relation types valid between those node types. Selecting one creates the discourse relation (persisted to Roam) and replaces the plain arrow with the relation arrow. Extract the relation-creation logic shared with the node drag-handle flow into overlays/relationCreation.ts (createRelationBetweenNodes, getValidRelationTypesBetween); DragHandleOverlay and RelationTypeDropdown now delegate to it.
|
This pull request has been ignored for the connected project Preview Branches by Supabase. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 08c8fb265e
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
Converting a plain arrow deleted the original immediately after the new relation shape was created, but persistence runs asynchronously and deletes the new arrow on failure (e.g. canvas page UID lookup fails), which could leave neither arrow. Await handleCreateRelationsInRoam and treat the new arrow surviving as success; the convert action now removes the original only when the relation persisted. The drag-handle caller voids the now-async helper (no original arrow to lose, behavior unchanged).
Drop the `sourceNode?.type ?? ""` lie that quietly proceeded past a deleted source/target shape and let the binding step fail silently, losing the original arrow with no toast. Return null early instead. Also drop the `?? newArrow` fallback when re-reading the shape before persistence; the read happens synchronously after createShape + bindings, so there is no scenario where it returns undefined that we should paper over.
PR size/scope checkThis PR is over our review-size guideline.
Please split this into smaller PRs unless there is a clear reason the changes need to land together. If keeping it as one PR, please add a brief justification covering:
|
…conversion Pull the directional-label rule and the Roam-persistence call into shared getDirectionalRelationLabel and persistRelationArrow helpers, used by both the drag-handle creator and the conversion path (the label rule previously lived in three places). Convert now sets the relation's visual contract explicitly instead of spreading the original arrow's props: it inherits only geometry (bend, start, end, labelPosition) and forces color, label, arrowheads, dash, size, font, scale, fill. Arrowheads encode relation direction, so a converted double- or reverse-headed arrow would otherwise render a misdirected relation; explicit props also stop future tldraw arrow props from leaking into converted relations.
No description provided.