Layoutstore Minimap calculation #5547
Conversation
…on and viewport calculations
…d enhance type definitions
dosubot
bot
added
the
size:XL
🎭 Playwright Test Results⏰ Completed at: 09/19/2025, 07:40:42 PM UTC 📈 Summary
📊 Test Reports by Browser
🎉 Click on the links above to view detailed test results for each browser configuration. |
| } | ||
|
|
||
| // TODO: update when Layoutstore tracks links | ||
| const currentLinks = JSON.stringify(g.links || {}) |
There was a problem hiding this comment.
I feel like this could probably be devolved into a chain of computed()s, since a lot of these are check/mutate on refs (or mutable state that isn't reactive)
There was a problem hiding this comment.
This is my main concern too. stringify is very expensive if we are repeatedly calling it.
Can we safely do this without stringifying?
There was a problem hiding this comment.
I think we can handle it in a followup since this came from existing implementation that is just being refactored here.
src/renderer/extensions/minimap/composables/useMinimapViewport.ts
Outdated
Show resolved
Hide resolved
| * Abstract base class for minimap data sources | ||
| * Provides common functionality and shared implementation | ||
| */ | ||
| export abstract class AbstractMinimapDataSource implements IMinimapDataSource { |
There was a problem hiding this comment.
This feels really heavy for what it is doing
There was a problem hiding this comment.
I think it's good considering we will have graph data from different sources. It should be nice as we make changes to data model and providers
| } | ||
|
|
||
| // TODO: update when Layoutstore tracks links | ||
| const currentLinks = JSON.stringify(g.links || {}) |
There was a problem hiding this comment.
This is my main concern too. stringify is very expensive if we are repeatedly calling it.
Can we safely do this without stringifying?
I just copy pasted the existing implementation and tried to separate a layout store implementation |
This pull request refactors the minimap rendering system to use a unified, extensible data source abstraction for all minimap operations. By introducing a data source interface and factory, the minimap can now seamlessly support multiple sources of node layout (such as the
LayoutStoreor the underlyingLiteGraph), improving maintainability and future extensibility. Rendering logic and change detection throughout the minimap have been updated to use this new abstraction, resulting in cleaner code and easier support for new data models.Core architecture improvements:
IMinimapDataSourceinterface and related data types (MinimapNodeData,MinimapLinkData,MinimapGroupData) to standardize node, link, and group data for minimap rendering.AbstractMinimapDataSourcethat provides shared logic for bounds and group/link extraction, and implemented two concrete data sources:LiteGraphDataSource(for classic graph data) andLayoutStoreDataSource(for layout store data). [1] [2] [3]MinimapDataSourceFactorythat selects the appropriate data source based on the presence of layout store data, enabling seamless switching between data models.Minimap rendering and logic refactoring:
renderGroups,renderNodes,renderConnections) and the mainrenderMinimapToCanvasentry point to use the unified data source interface, significantly simplifying the rendering code and decoupling it from the underlying graph structure. [1] [2] [3] [4] [5] [6] [7] [8]These changes make the minimap codebase more modular and robust, and lay the groundwork for supporting additional node layout strategies in the future.
┆Issue is synchronized with this Notion page by Unito