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. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
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.
| normalizedAnchor: { x: 0.5, y: 0.5 }, | ||
| isPrecise: false, | ||
| isExact: false, | ||
| void createDefaultRelationBetweenNodes({ |
There was a problem hiding this comment.
This replaces the old inline drag-handle relation creation block with the same default-create path in a named helper. The drag flow still creates a fresh relation arrow with default geometry and center bindings; conversion does not use this helper because it has to preserve an existing arrow's geometry.
| return validTypes; | ||
| }; | ||
|
|
||
| export const createDefaultRelationBetweenNodes = async ({ |
There was a problem hiding this comment.
This is intentionally the default/fresh relation creation path. It keeps the drag-handle behavior centered and default-styled; existing-arrow conversion lives separately because that flow has a different lifecycle and rollback contract.
| "label" | "complement" | "source" | "destination" | ||
| >; | ||
|
|
||
| export const getDirectionalRelationLabel = ({ |
There was a problem hiding this comment.
The directional label/complement rule is shared because it is the same question in the dropdown, default creation, and arrow conversion paths. This keeps label selection single-source without merging the different shape-creation lifecycles.
| normalizedAnchor: { ...binding.props.normalizedAnchor }, | ||
| }); | ||
|
|
||
| const convertArrowToRelation = async ({ |
There was a problem hiding this comment.
Conversion is intentionally separate from default relation creation. Here we transform an existing user-drawn arrow, so we preserve layout/bindings and only delete the original after relation persistence succeeds.
| opacity: arrow.opacity, | ||
| isLocked: arrow.isLocked, | ||
| meta: { ...arrow.meta }, | ||
| props: { |
There was a problem hiding this comment.
Only geometry is inherited from the plain arrow (bend, terminals, label position). The DG relation visual contract is forced here so converted relations show the same direction/style as relations created through the drag-handle flow.
| return validTypes; | ||
| }, [editor, sourceId, targetId]); | ||
| const validRelationTypes = useMemo( | ||
| () => getValidRelationTypesBetween(editor, sourceId, targetId), |
There was a problem hiding this comment.
This keeps the dropdown's relation filtering behavior the same, but reuses the same valid-relation lookup that the new arrow context menu needs.
1 participant
https://www.loom.com/share/2f7d93f683d74868b0a0193c1d1e7dac
This PR adds arrow-to-relation conversion without changing the existing relation storage decision. Both default relation creation and arrow conversion delegate persistence to the existing canvas relation util, which already chooses stored/reified relations vs legacy triples based on
getStoredRelationsEnabled().The split here is deliberate:
That keeps the old drag-handle behavior default-centered while allowing conversion to preserve the user’s existing arrow geometry and only delete the original arrow after persistence succeeds.