fix: expose calculated path coordinates for the relations component

[MinCrohn]

This change focuses on improving the Relations component's architecture for better performance and clarity. Users can now directly access the calculated link coordinates from the Relations instance.

• linkPoints Property: The Relations component now exposes a public linkPoints array containing the start (sourcePoint) and end (targetPoint) coordinates for each rendered link. This data can be used to implement various features, such as hit testing and custom visual effects.

• Test Coverage: A new test suite, Relations.test.js, has been added to verify these changes and prevent future regressions.

[gemini-code-assist]

Summary of Changes

Hello @MinCrohn, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly improves the Relations component's architecture by making its calculated link path coordinates accessible to external consumers. This change enhances the component's extensibility and clarity, supported by a refactored rendering process and robust new tests to guarantee its reliability.

Highlights

• Exposed Link Coordinates: The Relations component now publicly exposes a linkPoints array, providing direct access to the calculated start (sourcePoint) and end (targetPoint) coordinates for each rendered link. This enables easier implementation of features like hit testing and custom visual effects.
• Refactored Link Rendering: The internal logic for rendering links has been refactored. The calculation of link points is now separated into a new private method _calculateLinkPoints, which populates the linkPoints array, while renderLink focuses solely on drawing based on these pre-calculated points.
• Enhanced Test Coverage: A new comprehensive test suite, Relations.test.js, has been added. These tests verify the correct exposure and dynamic updates of the linkPoints property, ensuring stability when link properties change or linked items move.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request is a solid improvement, refactoring the Relations component to expose calculated link coordinates via the linkPoints property. This enhances both performance and the component's API. The separation of concerns between calculating points and rendering them is well-executed, and the new tests provide good coverage for the changes. I've identified a couple of potential issues: one is a possible null reference that could lead to a runtime error, and the other is a more subtle bug related to how link updates are handled, which is highlighted by one of the new tests. My detailed comments are below.

[gemini-code-assist]

Adding the call to _calculateLinkPoints() here is correct, but it reveals a subtle bug in the _applyLinks method. _applyLinks uses relevantChanges.links to update this.linkedObjects, but _calculateLinkPoints uses the full this.props.links.

If an update operation merges arrays by concatenation (as the new test case should recalculate points and redraw when "links" property changes implies), this.linkedObjects will only contain objects from the newly added links, not the complete set. This will cause _calculateLinkPoints to fail to find the objects for the older links, resulting in an incomplete linkPoints array.

To resolve this, _applyLinks should use the full this.props.links to rebuild this.linkedObjects, ensuring it stays synchronized with the component's state.