ENG-1955 Full migration to discourse relation shape#1167
Conversation
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:
|
|
This pull request has been ignored for the connected project Preview Branches by Supabase. |
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
|
@codex review |
![graphite-app[bot]](https://avatars.githubusercontent.com/in/158384?s=60&v=4){kind=small}
| ) { | ||
| const arrowId = typeof relation === "string" ? relation : relation.id; | ||
| const targetId = typeof target === "string" ? target : target.id; | ||
| const bindingType = getDiscourseRelationBindingType({ shape: relation }); |
There was a problem hiding this comment.
Critical type error: relation can be a string (arrowId) according to the function signature on line 1644, but getDiscourseRelationBindingType() expects a shape object with a type property. When relation is a string, accessing relation.type will fail.
// Fix: Convert string to shape object before calling helper
const arrowId = typeof relation === "string" ? relation : relation.id;
const arrowShape = typeof relation === "string"
? editor.getShape(relation) as DiscourseRelationShape
: relation;
const bindingType = getDiscourseRelationBindingType({ shape: arrowShape });
const existingMany = editor
.getBindingsFromShape<RelationBinding>(arrowId, bindingType)
.filter((b) => b.props.terminal === props.terminal);| const bindingType = getDiscourseRelationBindingType({ shape: relation }); | |
| const arrowId = typeof relation === "string" ? relation : relation.id; | |
| const arrowShape = typeof relation === "string" | |
| ? editor.getShape(relation) as DiscourseRelationShape | |
| : relation; | |
| const bindingType = getDiscourseRelationBindingType({ shape: arrowShape }); | |
Spotted by Graphite
Is this helpful? React 👍 or 👎 to let us know.
![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: da09f94deb
ℹ️ 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".
| ? createLegacyDiscourseNodeShapeUtils(allNodes) | ||
| : []), | ||
| ...createAllRelationShapeUtils(allRelationIds), | ||
| ...createAllRelationShapeUtils(), |
There was a problem hiding this comment.
For Cloudflare sync rooms that already contain pre-migration relation arrows, the worker keeps serving records whose shape.type is the old relation id because its schema is built from customShapeTypes and it does not run this app's createMigrations. This helper now registers only discourse-relation while the Cloudflare path only preserves legacy node utils, so those old relation records are applied to the client store without a matching shape util and the canvas fails to hydrate. Keep the old relation shape utils/types for the Cloudflare adapter until rooms are migrated.
Useful? React with 👍 / 👎.
| const relationBindingTypes = new Set([ | ||
| DISCOURSE_RELATION_SHAPE_TYPE, | ||
| ...discourseContextRelationIds, | ||
| ]); | ||
| const currentShapeRelations = Array.from(relationBindingTypes).flatMap( |
There was a problem hiding this comment.
When auto canvas relations runs on a node that already has any discourse-relation arrow to another node, currentShapeRelations now includes all shared-type relation bindings, but the duplicate check below still compares only endpoints. If Roam has a second distinct relation type/label between the same two nodes, this code treats the first arrow as a duplicate and skips creating the second one. Store each arrow's relationTypeId and include it in the duplicate check.
Useful? React with 👍 / 👎.
1 participant
Canvas relation shapes previously used the relation block UID as the tldraw shape
type. That made relation records graph-specific and brittle: if the relation type was deleted, missing from another graph, or copied across platforms, tldraw could fail to recognize the shape and break the canvas.This migration moves all canvas relations to a single
discourse-relationshape type and stores the actual relation subtype inprops.relationTypeId. With one stable shape type, canvases can load gracefully even when the subtype is unknown, deleted, or from a different graph.This also makes cross-graph and cross-platform tldraw sharing easier because the canvas record format no longer depends on graph-local relation UIDs as shape types.