Skip to content

feat: let efficiently not load default plugins and style builtins [POC] #754

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
tbouffard wants to merge 4 commits into from
Closed

feat: let efficiently not load default plugins and style builtins [POC] #754

tbouffard wants to merge 4 commits into from

Conversation

@tbouffard
Copy link
Member

@tbouffard tbouffard commented Apr 7, 2025 •
edited
Loading

⚠️ DISCLAIMER: This is a proof of concept (POC) to explore new ideas. It is not intended to be merged as-is. It is part of the initiatives described in #665 and #760.

💡 Motivation

Historically, the Graph class is the main entry point in maxGraph. It automatically loads some default built-ins like plugins and style elements.
This is great for evaluation and prototyping because it reduces the number of concepts needed to get started.
But for production use, it’s often suboptimal - unused features get bundled, which increases the application size.

🛠️ What this POC introduces

This PR explores a way to control what is loaded, through a new class:

  • BaseGraph: similar to Graph, but does not load any default configuration. This gives full control to the application over what features are included.
  • AbstractGraph: contains the shared logic between Graph and BaseGraph.
  • A new constructor style using a single object parameter, making optional parameters easier to manage (no more setting multiple null just to set the 4th one 🎉).

Most of the codebase has been updated to use AbstractGraph when appropriate - mostly type-related changes.

🧪 New examples

New examples (in JS and TS) demonstrate how to use BaseGraph with selected features.
They replicate the behavior of their Graph-based counterparts but explicitly opt into:

  • only needed plugins (e.g., fit, panning, rubberband, cell selections - note: CellEditorHandler alone adds ~12KB!)
  • minimal styling (e.g., perimeter and shape; for edges: only elbow connector)

There are also examples that load nothing by default, to show the absolute minimal footprint of using maxGraph.

These examples will help track future improvements. For example, today, importing just one static property from EdgeStyle or Perimeter still bundles the entire object. These examples will demonstrate the impact of migrating them to namespaces or other optimizable forms.

📦 Bundle size comparison

Baseline: commit used is from version 0.17.0
For TS examples: this is the size of the maxGraph chunk (rollup-based with Vite.js)
For JS examples: this is the size of the whole app (webpack-based)

ℹ️ Notice that the js-example-selected-features exactly miimics ts-example. In the final implementation, it should mimics js-example instead for a comparison with a different set of features

Example v0.17.0 This PR
js-example 475.71 kB 475.94 kB
js-example-selected-features N/A 395.39 kB
js-example-without-defaults 452.13 kB 349.74 kB
ts-example 439.15 kB 439.39 kB
ts-example-selected-features N/A 368.18 kB
ts-example-without-defaults 435.12 kB 330.26 kB

We notice a slight increase in the size of the original examples (those loading all defaults). This is likely due to the introduction of AbstractGraph and the bridging logic required to maintain compatibility with the existing Graph implementation.

ℹ️ Rollup (used in TS examples) seems to tree-shake maxGraph better than webpack. There’s room for improvement on the webpack side - maybe by adjusting how things are structured in maxGraph.

⚙️ webpack & side effects

When using webpack with a basic setup (as in our examples), tree-shaking is not fully effective.

During the development of this PR, Graph, BaseGraph, and AbstractGraph were initially located in the same file. Even when only BaseGraph was used in an example, webpack did not eliminate Graph from the final bundle.

This issue seems to stem from two main causes:

  • Side effects, particularly this line: 
    applyGraphMixins(AbstractGraph);
    This is required to apply mixins to both Graph and AbstractGraph, but it introduces a side effect that blocks effective tree-shaking.
  • File structure - having multiple classes in a single module makes it harder for webpack to determine what can be safely excluded.

To address this, each class has been moved to its own file. With this setup, webpack is now able to remove unused classes correctly.

⚠️ This is an important point to consider when structuring future code aimed at improving tree-shaking efficiency.

🔮 Potential follow-ups

There are a few things to refine:

  • Some TODOs are still pending, especially documentation updates, which would be required before making such a change viable for merging.
  • The new constructor style could be introduced in a separate PR - it’s not directly tied to the tree-shaking objective, although it’s useful to avoid a future breaking change in BaseGraph.
  • This POC also explores an alternative to Graph's factory methods by using constructor-injected values in AbstractGraph. This favors composition over inheritance, leading to better modularity and flexibility. This change could be introduced in a follow-up, to keep the current PR focused and avoid mixing concerns while still preparing for future improvements.
  • It might be worth introducing a DefaultGraph that mimics the current Graph behavior, but uses the new constructor format. This could help in future transitions.

Summary by CodeRabbit

  • New Features

    • Added new build steps for enhanced example builds and streamlined artifact management.
    • Introduced a new example project demonstrating feature selection and customization for improved user guidance.
    • Expanded the public API with additional graph abstraction classes.

  • Documentation

    • Updated the examples section to better illustrate feature selection and default style customizations.

These improvements provide a more flexible build process, enriched examples for customization, and expanded API capabilities for advanced integrations without altering existing functionalities.

@tbouffard tbouffard added the enhancement New feature or request label Apr 7, 2025
@coderabbitai
Copy link

coderabbitai bot commented Apr 7, 2025 •
edited
Loading

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Walkthrough

This pull request introduces new build steps and updates the artifact upload process in the GitHub Actions workflow while adding an additional example under README. Most of the changes, however, are refactorings that update numerous type declarations and method signatures across the codebase—from core utilities and view components to plugins and mixins—by replacing references to the concrete Graph type with a more abstract AbstractGraph. New exports for AbstractGraph and BaseGraph have also been added, and redundant code in some handlers has been removed.

Changes

Files / Groups Change Summary
.github/workflows/build.yml Added new build steps for “Build ts-example (selected features)” and “Build js-example (selected features)”; updated artifact upload paths to use wildcards.
README.md Appended a new example entry, [ts-example-selected-features](packages/js-example-without-defaults), illustrating specific feature selection.
Test & Editor Docs
(e.g. packages/core/__tests__/utils.ts, packages/core/src/editor/Editor.ts, packages/core/src/editor/EditorToolbar.ts, packages/core/src/i18n/Translations.ts)		 Minor documentation and comment updates; added a TODO note; adjusted parameter names and doc comments in editor components.
Core API & Utility Modules
(e.g. packages/core/src/index.ts, packages/core/src/types.ts, Clipboard.ts, gestureUtils.ts, printUtils.ts, treeTraversal.ts, xmlUtils.ts)		 Updated method signatures and type imports from Graph to AbstractGraph to standardize graph-related types across the utilities.
View Layer Updates
(e.g. AbstractGraph.ts, BaseGraph.ts, Graph.ts, GraphSelectionModel.ts, GraphView.ts, Effects.ts, Morphing.ts, etc.)		 Refactored core view classes: changed inheritance to extend AbstractGraph, removed obsolete edge handlers, and updated constructor and method signatures accordingly.
Mixins
(all files under packages/core/src/view/mixins/)		 Revised type definitions in all mixin files to pick properties from AbstractGraph instead of Graph, updating module declarations and interface names.
Plugins & Handlers
(e.g. CellEditorHandler.ts, ConnectionHandler.ts, FitPlugin.ts, PanningHandler.ts, PopupMenuHandler.ts, etc.)		 Modified constructor parameters, property types, and imports to use AbstractGraph, ensuring consistency in plugin and handler integrations.
Other Utilities
(e.g. AutoSaveManager.ts, DragSource.ts, Guide.ts, Multiplicity.ts, Outline.ts, PanningManager.ts, PrintPreview.ts)		 Replaced Graph with AbstractGraph in class properties, function parameters, and return types; refactored methods such as graph instantiation in Outline.

Sequence Diagram(s)

sequenceDiagram
    participant C as Commit/PR
    participant GH as GitHub Actions Workflow
    participant TS as "Build ts-example\n(selected features)"
    participant JS as "Build js-example\n(selected features)"
    participant A as "Artifact Upload\n(Wildcard Path)"
    
    C->>GH: Push commit with changes
    GH->>TS: Run TS build step
    GH->>JS: Run JS build step
    GH->>A: Upload artifacts using wildcard pattern
    A-->>GH: Complete upload
Loading

Possibly related PRs

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

  • Review comments: Directly reply to a review comment made by CodeRabbit. Example:
    • I pushed a fix in commit <commit_id>, please review it.
    • Generate unit testing code for this file.
    • Open a follow-up GitHub issue for this discussion.
  • Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
    • @coderabbitai generate unit testing code for this file.
    • @coderabbitai modularize this function.
  • PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
    • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
    • @coderabbitai read src/utils.ts and generate unit testing code.
    • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
    • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

  • @coderabbitai pause to pause the reviews on a PR.
  • @coderabbitai resume to resume the paused reviews.
  • @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
  • @coderabbitai full review to do a full review from scratch and review all the files again.
  • @coderabbitai summary to regenerate the summary of the PR.
  • @coderabbitai generate docstrings to generate docstrings for this PR.
  • @coderabbitai resolve resolve all the CodeRabbit review comments.
  • @coderabbitai plan to trigger planning for file edits and PR creation.
  • @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
  • @coderabbitai help to get help.

Other keywords and placeholders

  • Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
  • Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
  • Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

  • You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
  • Please see the configuration documentation for more information.
  • If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

  • Visit our Documentation for detailed information on how to use CodeRabbit.
  • Join our Discord Community to get help, request features, and share feedback.
  • Follow us on X/Twitter for updates and announcements.

coderabbitai[bot]
coderabbitai bot reviewed Apr 7, 2025
View reviewed changes
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 3

🧹 Nitpick comments (16)
README.md (1)

145-145: Documentation enhances usability of the new feature.

Adding the ts-example-selected-features example to the README is valuable as it demonstrates how to use the new capability to selectively load plugins and register specific style defaults. This directly supports the PR objective and helps users understand how to implement the feature.

Consider updating the example name in the path to match the text description - the link shows packages/js-example-without-defaults but the text mentions ts-example-selected-features.

packages/core/src/editor/Editor.ts (1)

1397-1397: Added useful TODO for future enhancement.

The TODO suggests a valuable future improvement that would give users more control over plugin selection, which aligns with the PR's objective of efficient plugin loading.

Consider prioritizing this TODO in a future PR, as letting users choose which plugins to load would directly support the main objective of this pull request for efficient plugin loading.

packages/core/src/view/mixins/ValidationMixin.ts (1)

107-107: Update the comment to reflect the AbstractGraph cast

The comment // needs to cast to Graph is now outdated since the cast has been updated to AbstractGraph.

-          <AbstractGraph>(<unknown>this), // needs to cast to Graph
+          <AbstractGraph>(<unknown>this), // needs to cast to AbstractGraph
packages/core/src/view/BaseGraph.ts (1)

23-31: New BaseGraph implementation extending AbstractGraph

The BaseGraph class provides a foundation for the AbstractGraph interface with proper initialization of collaborators. This implementation supports the PR's goal of enabling more efficient loading of plugins and style builtins.

The TODO comment on line 23 should be expanded to provide more context about what JSDoc needs to be added. Consider adding a detailed class description explaining the purpose and usage of BaseGraph.

-// TODO JSDoc of BaseGraph
+// TODO Add JSDoc explaining BaseGraph's purpose, usage scenarios, and how it relates to AbstractGraph and Graph implementations
packages/core/src/view/layout/EdgeLabelLayout.ts (1)

42-42: Constructor parameter type updated but unused parameter detected

While the constructor parameter type has been correctly updated from Graph to AbstractGraph, there's an unused radius parameter that doesn't appear to be utilized anywhere in the constructor or class.

Consider removing the unused parameter or documenting its purpose and implementing its usage:

-  constructor(graph: AbstractGraph, radius: number) {
+  constructor(graph: AbstractGraph) {
    super(graph);
  }

Or if the parameter is needed:

  constructor(graph: AbstractGraph, radius: number) {
    super(graph);
+   this.radius = radius; // Store radius for later use
  }
+
+  private radius: number;
packages/core/src/view/layout/ParallelEdgeLayout.ts (1)

66-68: Consider removing unnecessary constructor

The constructor doesn't add any functionality beyond calling the parent constructor. Since it doesn't modify or add behavior, it could be removed entirely, and TypeScript will automatically inherit the parent constructor.

-  constructor(graph: AbstractGraph) {
-    super(graph);
-  }
🧰 Tools
🪛 Biome (1.9.4)

[error] 66-68: This constructor is unnecessary.

Unsafe fix: Remove the unnecessary constructor.

(lint/complexity/noUselessConstructor)

packages/core/src/view/animate/Effects.ts (1)

59-59: Avoid using 'Function' as a type

The Function type is too generic and can lead to type safety issues. Consider defining a more specific function type signature.

-  static animateChanges(
-    graph: AbstractGraph,
-    changes: UndoableChange[],
-    done?: Function
-  ): void {
+  static animateChanges(
+    graph: AbstractGraph,
+    changes: UndoableChange[],
+    done?: () => void
+  ): void {
🧰 Tools
🪛 Biome (1.9.4)

[error] 59-59: Don't use 'Function' as a type.

Prefer explicitly define the function shape. This type accepts any function-like value, which can be a common source of bugs.

(lint/complexity/noBannedTypes)

packages/core/src/view/layout/LayoutManager.ts (1)

32-399: Overall architecture improvement to use abstraction.

These changes to use AbstractGraph instead of the concrete Graph type implement good software engineering practices by following the Dependency Inversion Principle (part of SOLID). By depending on abstractions rather than concrete implementations, the code becomes more maintainable, testable, and flexible. This aligns perfectly with the PR objective to "let efficiently not load default plugins and style builtins" as it provides the necessary abstraction layer to achieve this.

packages/core/src/view/layout/FastOrganicLayout.ts (1)

38-40: Remove unnecessary constructor

The constructor only calls the parent constructor without adding any additional initialization logic.

-  constructor(graph: AbstractGraph) {
-    super(graph);
-  }

This constructor can be safely removed as the parent constructor would be automatically called with the same parameters.

🧰 Tools
🪛 Biome (1.9.4)

[error] 38-40: This constructor is unnecessary.

Unsafe fix: Remove the unnecessary constructor.

(lint/complexity/noUselessConstructor)

packages/core/src/view/Graph.ts (1)

28-28: TODO comment identified.
Please ensure the class’s JSDoc is revisited and updated before merging.

Would you like help drafting updated documentation?

packages/core/src/view/AbstractGraph.ts (2)

25-26: Remove outdated TODOs or provide actionable plan
There are multiple inline TODO comments around lines 61–76 (e.g., "move types to /types.ts" and "review the name"), which can be confusing if left unresolved. Either remove them if no longer relevant or turn them into issues or actionable tasks with clear owners and timelines.

487-514: Check lazy initialization for plugins
You're initializing plugins immediately after the constructor sets up collaborators. If plugin registration relies on certain async or late-bound references, consider deferring the plugin setup and revalidation calls until after the container is fully ready.

packages/core/src/view/other/DragSource.ts (2)

48-53: Update docstrings to reflect the new AbstractGraph type
The DropHandler signature now uses AbstractGraph as the graph parameter, but some references in the comments still mention generic or previous types. Align the JSDoc to remove any ambiguity.

131-132: Revise JSDoc to match the new property type
The doc comment on line 131 refers to enabling or disabling the graph, but the next line defines currentGraph: AbstractGraph | null. Consider adding or rewriting the comment block so it accurately explains currentGraph.

packages/core/src/view/other/Multiplicity.ts (2)

21-21: Confirm consistent referencing of AbstractGraph
This import aligns with the broader refactor away from Graph. Verify that no references to the old type remain in doc comments or code assumptions (e.g., "Graph" in error messages).

208-212: Match doc parameters with method signature
The docstring references (graph, edge, terminal) in a specific order, but the method signature is (graph: AbstractGraph, edge: Cell, terminal: Cell). Verify all references are consistent, especially if future changes or extended parameters are introduced.

📜 Review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between e22b2e1 and f73adef.

⛔ Files ignored due to path filters (2)
  • packages/js-example-selected-features/favicon.svg is excluded by !**/*.svg
  • packages/ts-example-selected-features/favicon.svg is excluded by !**/*.svg
📒 Files selected for processing (107)
  • .github/workflows/build.yml (2 hunks)
  • README.md (1 hunks)
  • packages/core/__tests__/utils.ts (1 hunks)
  • packages/core/src/editor/Editor.ts (1 hunks)
  • packages/core/src/editor/EditorToolbar.ts (2 hunks)
  • packages/core/src/i18n/Translations.ts (1 hunks)
  • packages/core/src/index.ts (1 hunks)
  • packages/core/src/types.ts (2 hunks)
  • packages/core/src/util/Clipboard.ts (5 hunks)
  • packages/core/src/util/gestureUtils.ts (3 hunks)
  • packages/core/src/util/printUtils.ts (4 hunks)
  • packages/core/src/util/treeTraversal.ts (3 hunks)
  • packages/core/src/util/xmlUtils.ts (2 hunks)
  • packages/core/src/view/AbstractGraph.ts (1 hunks)
  • packages/core/src/view/BaseGraph.ts (1 hunks)
  • packages/core/src/view/Graph.ts (3 hunks)
  • packages/core/src/view/GraphSelectionModel.ts (2 hunks)
  • packages/core/src/view/GraphView.ts (3 hunks)
  • packages/core/src/view/animate/Effects.ts (3 hunks)
  • packages/core/src/view/animate/Morphing.ts (2 hunks)
  • packages/core/src/view/cell/CellHighlight.ts (3 hunks)
  • packages/core/src/view/cell/CellMarker.ts (3 hunks)
  • packages/core/src/view/cell/CellStatePreview.ts (1 hunks)
  • packages/core/src/view/cell/CellTracker.ts (2 hunks)
  • packages/core/src/view/cell/VertexHandle.ts (2 hunks)
  • packages/core/src/view/event/InternalEvent.ts (2 hunks)
  • packages/core/src/view/handler/ConstraintHandler.ts (3 hunks)
  • packages/core/src/view/handler/EdgeHandler.ts (3 hunks)
  • packages/core/src/view/handler/KeyHandler.ts (3 hunks)
  • packages/core/src/view/handler/VertexHandler.ts (2 hunks)
  • packages/core/src/view/layout/CircleLayout.ts (2 hunks)
  • packages/core/src/view/layout/CompactTreeLayout.ts (2 hunks)
  • packages/core/src/view/layout/CompositeLayout.ts (2 hunks)
  • packages/core/src/view/layout/EdgeLabelLayout.ts (2 hunks)
  • packages/core/src/view/layout/FastOrganicLayout.ts (2 hunks)
  • packages/core/src/view/layout/GraphLayout.ts (3 hunks)
  • packages/core/src/view/layout/HierarchicalLayout.ts (2 hunks)
  • packages/core/src/view/layout/LayoutManager.ts (4 hunks)
  • packages/core/src/view/layout/ParallelEdgeLayout.ts (2 hunks)
  • packages/core/src/view/layout/PartitionLayout.ts (2 hunks)
  • packages/core/src/view/layout/RadialTreeLayout.ts (2 hunks)
  • packages/core/src/view/layout/StackLayout.ts (2 hunks)
  • packages/core/src/view/layout/SwimlaneLayout.ts (2 hunks)
  • packages/core/src/view/layout/SwimlaneManager.ts (4 hunks)
  • packages/core/src/view/layout/hierarchical/CoordinateAssignment.ts (6 hunks)
  • packages/core/src/view/mixins/CellsMixin.ts (2 hunks)
  • packages/core/src/view/mixins/CellsMixin.type.ts (1 hunks)
  • packages/core/src/view/mixins/ConnectionsMixin.ts (1 hunks)
  • packages/core/src/view/mixins/ConnectionsMixin.type.ts (1 hunks)
  • packages/core/src/view/mixins/DragDropMixin.ts (1 hunks)
  • packages/core/src/view/mixins/DragDropMixin.type.ts (1 hunks)
  • packages/core/src/view/mixins/EdgeMixin.ts (2 hunks)
  • packages/core/src/view/mixins/EdgeMixin.type.ts (1 hunks)
  • packages/core/src/view/mixins/EditingMixin.ts (2 hunks)
  • packages/core/src/view/mixins/EditingMixin.type.ts (1 hunks)
  • packages/core/src/view/mixins/EventsMixin.ts (3 hunks)
  • packages/core/src/view/mixins/EventsMixin.type.ts (1 hunks)
  • packages/core/src/view/mixins/FoldingMixin.ts (2 hunks)
  • packages/core/src/view/mixins/FoldingMixin.type.ts (1 hunks)
  • packages/core/src/view/mixins/GroupingMixin.ts (2 hunks)
  • packages/core/src/view/mixins/GroupingMixin.type.ts (1 hunks)
  • packages/core/src/view/mixins/ImageMixin.ts (1 hunks)
  • packages/core/src/view/mixins/ImageMixin.type.ts (1 hunks)
  • packages/core/src/view/mixins/LabelMixin.ts (1 hunks)
  • packages/core/src/view/mixins/LabelMixin.type.ts (1 hunks)
  • packages/core/src/view/mixins/OrderMixin.ts (1 hunks)
  • packages/core/src/view/mixins/OrderMixin.type.ts (1 hunks)
  • packages/core/src/view/mixins/OverlaysMixin.ts (2 hunks)
  • packages/core/src/view/mixins/OverlaysMixin.type.ts (1 hunks)
  • packages/core/src/view/mixins/PageBreaksMixin.ts (2 hunks)
  • packages/core/src/view/mixins/PageBreaksMixin.type.ts (1 hunks)
  • packages/core/src/view/mixins/PanningMixin.ts (1 hunks)
  • packages/core/src/view/mixins/PanningMixin.type.ts (1 hunks)
  • packages/core/src/view/mixins/PortsMixin.ts (1 hunks)
  • packages/core/src/view/mixins/PortsMixin.type.ts (1 hunks)
  • packages/core/src/view/mixins/SelectionMixin.ts (2 hunks)
  • packages/core/src/view/mixins/SelectionMixin.type.ts (1 hunks)
  • packages/core/src/view/mixins/SnapMixin.ts (1 hunks)
  • packages/core/src/view/mixins/SnapMixin.type.ts (1 hunks)
  • packages/core/src/view/mixins/SwimlaneMixin.ts (2 hunks)
  • packages/core/src/view/mixins/SwimlaneMixin.type.ts (1 hunks)
  • packages/core/src/view/mixins/TerminalMixin.ts (1 hunks)
  • packages/core/src/view/mixins/TerminalMixin.type.ts (1 hunks)
  • packages/core/src/view/mixins/TooltipMixin.ts (1 hunks)
  • packages/core/src/view/mixins/TooltipMixin.type.ts (1 hunks)
  • packages/core/src/view/mixins/ValidationMixin.ts (3 hunks)
  • packages/core/src/view/mixins/ValidationMixin.type.ts (1 hunks)
  • packages/core/src/view/mixins/VertexMixin.ts (1 hunks)
  • packages/core/src/view/mixins/VertexMixin.type.ts (1 hunks)
  • packages/core/src/view/mixins/ZoomMixin.ts (1 hunks)
  • packages/core/src/view/mixins/ZoomMixin.type.ts (1 hunks)
  • packages/core/src/view/mixins/_graph-mixins-apply.ts (2 hunks)
  • packages/core/src/view/other/AutoSaveManager.ts (4 hunks)
  • packages/core/src/view/other/DragSource.ts (11 hunks)
  • packages/core/src/view/other/Guide.ts (2 hunks)
  • packages/core/src/view/other/Multiplicity.ts (5 hunks)
  • packages/core/src/view/other/Outline.ts (4 hunks)
  • packages/core/src/view/other/PanningManager.ts (1 hunks)
  • packages/core/src/view/other/PrintPreview.ts (4 hunks)
  • packages/core/src/view/plugins/CellEditorHandler.ts (3 hunks)
  • packages/core/src/view/plugins/ConnectionHandler.ts (4 hunks)
  • packages/core/src/view/plugins/FitPlugin.ts (2 hunks)
  • packages/core/src/view/plugins/PanningHandler.ts (3 hunks)
  • packages/core/src/view/plugins/PopupMenuHandler.ts (3 hunks)
  • packages/core/src/view/plugins/RubberBandHandler.ts (3 hunks)
  • packages/core/src/view/plugins/SelectionCellsHandler.ts (3 hunks)
  • packages/core/src/view/plugins/SelectionHandler.ts (6 hunks)
⛔ Files not processed due to max files limit (21)
  • packages/core/src/view/plugins/TooltipHandler.ts
  • packages/core/src/view/undoable_changes/SelectionChange.ts
  • packages/js-example-selected-features/.gitignore
  • packages/js-example-selected-features/README.md
  • packages/js-example-selected-features/index.html
  • packages/js-example-selected-features/package.json
  • packages/js-example-selected-features/src/index.js
  • packages/js-example-selected-features/src/style.css
  • packages/js-example-selected-features/webpack.config.js
  • packages/js-example-without-defaults/src/index.js
  • packages/ts-example-selected-features/README.md
  • packages/ts-example-selected-features/index.html
  • packages/ts-example-selected-features/package.json
  • packages/ts-example-selected-features/src/main.ts
  • packages/ts-example-selected-features/src/style.css
  • packages/ts-example-selected-features/src/vite-env.d.ts
  • packages/ts-example-selected-features/tsconfig.json
  • packages/ts-example-selected-features/vite.config.js
  • packages/ts-example-without-defaults/src/main.ts
  • packages/ts-example-without-defaults/vite.config.js
  • packages/website/docs/demo-and-examples.md
🧰 Additional context used
🧬 Code Definitions (63)
packages/core/src/view/mixins/VertexMixin.type.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/mixins/OverlaysMixin.type.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/mixins/OrderMixin.type.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/mixins/TerminalMixin.type.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/mixins/SelectionMixin.type.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/mixins/EdgeMixin.type.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/mixins/FoldingMixin.type.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/mixins/EventsMixin.type.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/mixins/ImageMixin.type.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/mixins/ConnectionsMixin.type.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/layout/CircleLayout.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/mixins/DragDropMixin.type.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/other/PanningManager.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/mixins/PortsMixin.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/mixins/ValidationMixin.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/mixins/GroupingMixin.type.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/mixins/LabelMixin.type.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/editor/Editor.ts (1)
packages/core/src/view/Graph.ts (1)
  • Graph (34-84)
packages/core/src/view/mixins/SwimlaneMixin.type.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/mixins/_graph-mixins-apply.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/mixins/LabelMixin.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/mixins/ImageMixin.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/BaseGraph.ts (2)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/AbstractGraph.ts (1)
  • CollaboratorsGraphOptions (69-76)
packages/core/src/view/animate/Morphing.ts (4)
packages/html/stories/HtmlLabel.stories.js (1)
  • graph (162-170)
packages/html/stories/Scrollbars.stories.js (1)
  • graph (488-501)
packages/html/stories/Wires.stories.js (1)
  • graph (704-712)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/mixins/ZoomMixin.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/handler/ConstraintHandler.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/plugins/CellEditorHandler.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/mixins/ValidationMixin.type.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/handler/KeyHandler.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/mixins/EditingMixin.type.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/plugins/SelectionCellsHandler.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/mixins/TooltipMixin.type.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/mixins/SnapMixin.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/mixins/SnapMixin.type.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/plugins/PanningHandler.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/mixins/DragDropMixin.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/mixins/CellsMixin.type.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/mixins/EditingMixin.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/util/gestureUtils.ts (2)
packages/html/stories/DragSource.stories.js (1)
  • graphF (135-146)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/mixins/PanningMixin.type.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/mixins/VertexMixin.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/layout/FastOrganicLayout.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/mixins/ConnectionsMixin.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/layout/CompositeLayout.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/layout/LayoutManager.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/mixins/PageBreaksMixin.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/cell/CellStatePreview.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/AbstractGraph.ts (6)
packages/core/src/types.ts (4)
  • GraphPluginConstructor (1103-1106)
  • GraphPlugin (1109-1111)
  • GraphFoldingOptions (1349-1370)
  • EdgeStyleFunction (1220-1226)
packages/core/src/util/Constants.ts (1)
  • PAGE_FORMAT_A4_PORTRAIT (407-407)
packages/core/src/internal/i18n-utils.ts (1)
  • isI18nEnabled (22-24)
packages/core/src/util/styleUtils.ts (1)
  • getCurrentStyle (62-66)
packages/core/src/internal/utils.ts (1)
  • isNullish (39-40)
packages/core/src/util/domUtils.ts (1)
  • isNode (223-238)
packages/core/src/view/mixins/PortsMixin.type.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/plugins/SelectionHandler.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/handler/VertexHandler.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/mixins/TooltipMixin.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/mixins/TerminalMixin.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/handler/EdgeHandler.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/plugins/ConnectionHandler.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/mixins/SwimlaneMixin.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/layout/CompactTreeLayout.ts (2)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/layout/datatypes/GraphHierarchyEdge.ts (1)
  • invert (75-80)
packages/core/src/view/mixins/ZoomMixin.type.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/mixins/PageBreaksMixin.type.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/mixins/PanningMixin.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/other/DragSource.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
packages/core/src/view/Graph.ts (4)
packages/core/src/view/AbstractGraph.ts (1)
  • CollaboratorsGraphOptions (69-76)
packages/core/src/view/GraphDataModel.ts (1)
  • GraphDataModel (218-1182)
packages/core/src/types.ts (1)
  • GraphPluginConstructor (1103-1106)
packages/core/src/view/style/Stylesheet.ts (1)
  • Stylesheet (49-202)
packages/core/src/view/layout/EdgeLabelLayout.ts (1)
packages/core/src/index.ts (1)
  • AbstractGraph (20-20)
🪛 Biome (1.9.4)
packages/core/src/view/animate/Effects.ts

[error] 59-59: Don't use 'Function' as a type.

Prefer explicitly define the function shape. This type accepts any function-like value, which can be a common source of bugs.

(lint/complexity/noBannedTypes)

packages/core/src/util/gestureUtils.ts

[error] 89-89: Don't use 'Function' as a type.

Prefer explicitly define the function shape. This type accepts any function-like value, which can be a common source of bugs.

(lint/complexity/noBannedTypes)

packages/core/src/view/layout/ParallelEdgeLayout.ts

[error] 66-68: This constructor is unnecessary.

Unsafe fix: Remove the unnecessary constructor.

(lint/complexity/noUselessConstructor)

packages/core/src/view/layout/FastOrganicLayout.ts

[error] 38-40: This constructor is unnecessary.

Unsafe fix: Remove the unnecessary constructor.

(lint/complexity/noUselessConstructor)

packages/core/src/view/AbstractGraph.ts

[error] 101-101: Don't use 'Function' as a type.

Prefer explicitly define the function shape. This type accepts any function-like value, which can be a common source of bugs.

(lint/complexity/noBannedTypes)

[error] 102-102: Don't use 'Function' as a type.

Prefer explicitly define the function shape. This type accepts any function-like value, which can be a common source of bugs.

(lint/complexity/noBannedTypes)

🔇 Additional comments (242)
packages/core/src/i18n/Translations.ts (1)

76-76: Documentation updated to reference AbstractGraph instead of Graph.

The documentation has been updated to reference AbstractGraph instead of Graph, which aligns with the broader refactoring effort across the codebase that's transitioning to a more abstract graph representation.

packages/core/src/view/mixins/PageBreaksMixin.type.ts (1)

21-22: Module declaration updated to reference AbstractGraph.

The module declaration and interface have been updated from Graph to AbstractGraph, reflecting the codebase's transition to a more abstract graph representation. This change maintains consistency with the architectural updates across the project.

packages/core/src/view/mixins/EventsMixin.type.ts (1)

24-25: Module declaration updated to reference AbstractGraph.

The module declaration and interface have been updated from Graph to AbstractGraph, reflecting the codebase's transition to a more abstract graph representation. This change is consistent with the architectural updates across the project.

packages/core/src/view/mixins/ImageMixin.type.ts (1)

19-20: Module declaration updated to reference AbstractGraph.

The module declaration and interface have been updated from Graph to AbstractGraph, reflecting the codebase's transition to a more abstract graph representation. This change is consistent with the architectural updates across the project.

packages/core/src/view/mixins/SwimlaneMixin.type.ts (1)

21-22: Type reference update looks good.

This change from Graph to AbstractGraph is consistent with the broader refactoring effort in this PR, which appears to be moving from concrete implementation types to more abstract interfaces. This approach improves the codebase's flexibility by allowing different graph implementations to share the same interface.

packages/core/src/view/mixins/VertexMixin.type.ts (1)

21-22: Type reference update is appropriate.

This change from Graph to AbstractGraph is consistent with the broader refactoring effort in this PR. The interface content remains the same, maintaining functionality while making the type hierarchy more flexible.

packages/core/src/view/mixins/OverlaysMixin.type.ts (1)

21-22: Type reference update looks good.

This change from Graph to AbstractGraph is consistent with the broader refactoring effort in this PR. This systematic approach to updating type references throughout the codebase will help ensure a cohesive abstraction layer for graph functionality.

packages/core/src/view/mixins/TerminalMixin.type.ts (1)

19-20: Type reference updated to use AbstractGraph

The module declaration and interface name have been changed from Graph to AbstractGraph. This change is part of a broader refactoring pattern across the codebase to use a more abstract representation of graph functionality.

packages/core/src/view/other/PanningManager.ts (2)

25-25: Import statement updated to use AbstractGraph

The import has been updated to use the more abstract AbstractGraph type instead of the concrete Graph implementation, which aligns with the refactoring pattern across the codebase.

31-31: Constructor parameter type updated

The constructor parameter type has been changed from Graph to AbstractGraph, allowing the PanningManager to work with any implementation that adheres to the AbstractGraph interface rather than requiring a specific implementation.

packages/core/src/view/mixins/PortsMixin.ts (2)

17-17: Import statement updated to use AbstractGraph

The import has been updated to use the more abstract AbstractGraph type instead of the concrete Graph implementation, aligning with the refactoring pattern across the codebase.

20-20: Type reference updated in Pick utility

The Pick utility type now selects properties from AbstractGraph instead of Graph, maintaining the same interface while making the code more flexible by working with a more abstract type.

packages/core/src/view/mixins/DragDropMixin.type.ts (1)

19-20: Module declaration and interface name updated

The module declaration and interface name have been changed from Graph to AbstractGraph. This change is consistent with the broader refactoring pattern to use a more abstract representation of graph functionality throughout the codebase.

packages/core/src/view/mixins/SelectionMixin.type.ts (1)

21-22: Interface abstraction improves extensibility.

The change from Graph to AbstractGraph enhances modularity by providing a more generic interface that can be implemented by different graph types. This change aligns with the PR objective of efficiently loading plugins by allowing more selective feature implementation.

packages/core/src/view/mixins/CellsMixin.type.ts (1)

23-24: Interface abstraction enables flexibility in plugin loading.

Updating the module declaration to use AbstractGraph instead of Graph is consistent with the changes in other files and supports the goal of allowing selective feature loading. This abstraction will enable more granular control over what plugins and style builtins are loaded.

packages/core/src/index.ts (1)

20-21: New exports support the feature-selective loading mechanism.

Adding exports for AbstractGraph and BaseGraph is essential for the PR objective. These exports allow consumers to:

  1. Use AbstractGraph for type-checking against the minimal required interface
  2. Use BaseGraph as a foundation for custom graph implementations that don't load all default plugins

This change is a key enabler for the "efficiently not load default plugins and style builtins" feature.

packages/core/src/view/mixins/EdgeMixin.type.ts (1)

20-21: Type change from Graph to AbstractGraph enhances flexibility

This change is part of a broader refactoring to use the more abstract AbstractGraph type instead of the concrete Graph implementation, which aligns with the PR's goal of making plugin loading more efficient.

packages/core/src/types.ts (2)

28-28: Replacing Graph with AbstractGraph import

Good addition - importing the more abstract type to replace concrete implementations throughout the codebase.

1105-1105:

Details

❓ Verification inconclusive

GraphPluginConstructor now accepts AbstractGraph

This change is significant as it modifies the plugin system's interface to work with the abstract type rather than the concrete implementation, enabling more flexible plugin design.

🏁 Script executed:

#!/bin/bash
# Verify if there are any plugins that might break with this change
echo "Checking for plugins that might depend on Graph-specific methods not in AbstractGraph..."
rg -l "import.*Graph.*from" --glob "**/*Plugin*.ts"

Length of output: 284

Action Required: Verify Plugin Compatibility with the New AbstractGraph Interface

The interface update to use AbstractGraph is on track. However, our verification script flagged one potential risk:

  • File: packages/core/src/view/plugins/FitPlugin.ts
    It appears this plugin imports or may depend on a concrete Graph implementation. Please verify that it either no longer relies on any Graph-specific methods or has been updated to fully support the new AbstractGraph interface.
packages/core/src/view/mixins/OrderMixin.type.ts (1)

19-20: Module declaration updated to use AbstractGraph

This change is consistent with the overall pattern of replacing concrete Graph types with the more abstract AbstractGraph interface.

packages/core/src/view/mixins/PanningMixin.type.ts (1)

20-21: Module declaration updated to use AbstractGraph

This is part of the consistent pattern of abstraction throughout the codebase, which will enable more flexible plugin loading as described in the PR objectives.

packages/core/src/view/mixins/LabelMixin.type.ts (1)

19-20: Appropriate switch from concrete implementation to abstract interface.

The change from Graph to AbstractGraph aligns with good software design principles by depending on abstractions rather than concrete implementations. This supports the PR's objective of more efficient plugin loading by enabling more flexible architectural patterns.

packages/core/src/view/mixins/EdgeMixin.ts (3)

21-21: Good addition of the required import.

Adding the import for AbstractGraph is a necessary part of the type refactoring across the codebase.

28-30: Appropriate type replacement for PartialGraph.

Changing from Graph to AbstractGraph in the type definition reflects the PR's effort to make the codebase work with a more abstract graph representation.

42-44: Consistent type replacement for PartialEdge.

This change maintains consistency with the other modifications, ensuring the EdgeMixin properly references the abstract interface rather than the concrete implementation.

packages/core/src/view/layout/CircleLayout.ts (3)

20-20: Updated import to use AbstractGraph.

This change is consistent with the abstract interface pattern being applied throughout the codebase.

41-42: Updated JSDoc parameter type documentation.

Good practice to keep documentation in sync with code changes, ensuring that JSDoc properly reflects the AbstractGraph type.

44-44: Updated constructor parameter type.

The parameter type change from Graph to AbstractGraph allows the CircleLayout to work with any implementation that satisfies the AbstractGraph interface, increasing flexibility.

packages/core/src/editor/Editor.ts (1)

1390-1395: Improved method documentation for createGraph.

The updated documentation clarifies that the graph is created without a container and is initialized later via setGraphContainer. This provides better guidance to developers about the method's behavior.

packages/core/src/view/mixins/ValidationMixin.ts (3)

19-19: Good job updating the import to use AbstractGraph

The change from importing Graph to AbstractGraph aligns with the PR's objective to create a more abstract implementation, which would facilitate not loading default plugins when unnecessary.

22-24: LGTM - Type update from Graph to AbstractGraph

This update to the PartialGraph type definition is in line with the refactoring effort to use the more abstract AbstractGraph type throughout the codebase.

35-37: LGTM - Type update for PartialValidation

Changing from Graph to AbstractGraph in the PartialValidation type definition is consistent with the overall refactoring approach.

packages/core/src/view/mixins/FoldingMixin.type.ts (1)

22-23: LGTM - Module declaration updated to use AbstractGraph

The update from '../Graph' to '../AbstractGraph' in the module declaration and from Graph to AbstractGraph in the interface name is part of the broader refactoring effort to use a more abstract graph type. This change allows the folding functionality to be applied to any implementation of the abstract graph interface, which aligns with the goal of more efficient plugin loading.

packages/core/src/view/mixins/EditingMixin.type.ts (1)

21-22: LGTM - Module declaration updated to use AbstractGraph

The change from '../Graph' to '../AbstractGraph' in the module declaration and from Graph to AbstractGraph in the interface name is consistent with the refactoring approach. This allows editing capabilities to be applied to any implementation of the abstract graph interface.

packages/core/src/view/mixins/TooltipMixin.type.ts (1)

20-21: LGTM - Module declaration updated to use AbstractGraph

The update from '../Graph' to '../AbstractGraph' in the module declaration and from Graph to AbstractGraph in the interface name follows the consistent pattern of refactoring across the codebase. This change ensures tooltip functionality can work with any implementation of the abstract graph interface.

packages/core/src/view/mixins/FoldingMixin.ts (3)

23-23: Type import updated to use AbstractGraph instead of Graph

The import has been changed to use AbstractGraph instead of Graph, which aligns with the broader refactoring effort in this PR to use more abstract interfaces for graph-related functionality.

26-39: Type reference updated from Graph to AbstractGraph

The PartialGraph type now picks properties from AbstractGraph instead of Graph. This change is consistent with the architectural shift towards using abstract interfaces and maintains all the existing property selections.

40-52: Type reference updated from Graph to AbstractGraph

The PartialFolding type now picks properties from AbstractGraph instead of Graph. This is part of the consistent refactoring to use the abstract interface across the codebase.

packages/core/src/view/mixins/CellsMixin.ts (3)

46-46: Type import updated to use AbstractGraph instead of Graph

The import has been changed to use AbstractGraph instead of Graph, which aligns with the broader refactoring effort to use more abstract interfaces.

49-90: Type reference updated from Graph to AbstractGraph

The PartialGraph type now picks properties from AbstractGraph instead of Graph. This is a consistent change as part of the refactoring effort while maintaining all the existing property selections.

92-194: Type reference updated from Graph to AbstractGraph

The PartialCells type now picks properties from AbstractGraph instead of Graph. This is part of the consistent architectural change across the codebase, and maintains all the original functionality.

packages/core/src/view/mixins/GroupingMixin.type.ts (1)

20-21: Module declaration and interface updated to use AbstractGraph

The module declaration has been changed from '../Graph' to '../AbstractGraph' and the interface has been updated from Graph to AbstractGraph. This change is significant as it moves the augmentation of graph functionality to the abstract interface level, which is consistent with the architectural refactoring in this PR.

packages/core/src/view/mixins/ImageMixin.ts (2)

17-17: Type import updated to use AbstractGraph instead of Graph

The import has been changed to use AbstractGraph instead of Graph, which aligns with the broader refactoring effort in this PR to use more abstract interfaces.

20-23: Type reference updated from Graph to AbstractGraph

The PartialImage type now picks properties from AbstractGraph instead of Graph. This maintains the existing functionality while being consistent with the architectural changes across the codebase.

packages/core/src/view/cell/CellTracker.ts (2)

21-21: Updated import to use AbstractGraph

The import has been updated to use the abstract interface type AbstractGraph instead of the concrete Graph implementation. This is part of the overall refactoring to reduce coupling with concrete implementations.

82-82: Constructor parameter updated to use AbstractGraph

The constructor parameter type has been changed from Graph to AbstractGraph, making the class more flexible by depending on the abstract interface rather than the concrete implementation. This aligns with the PR's goal of making plugin loading more efficient.

packages/core/src/view/mixins/SelectionMixin.ts (3)

21-21: Updated import to use AbstractGraph

The import has been updated to use the abstract interface type AbstractGraph instead of the concrete Graph implementation. This is consistent with the changes in other files.

24-25: Type reference updated to use AbstractGraph

The PartialGraph type now picks its properties from AbstractGraph instead of Graph, making it more abstract and flexible. This change maintains the same picked properties but from the abstract interface.

35-36: Type reference updated to use AbstractGraph

Similarly, the PartialCells type now picks its properties from AbstractGraph instead of Graph. This is consistent with the overall pattern of making the codebase depend on abstractions rather than concrete implementations.

packages/core/src/view/cell/VertexHandle.ts (2)

31-31: Updated import to use AbstractGraph

The import has been updated to use the abstract interface type AbstractGraph instead of the concrete Graph implementation, consistent with other changes in the PR.

43-43: Class property updated to use AbstractGraph

The type of the graph property has been changed from Graph to AbstractGraph, reducing coupling with the concrete implementation and allowing for more flexibility in how graph functionality is provided.

packages/core/src/util/treeTraversal.ts (3)

19-19: Updated import to use AbstractGraph

The import has been updated to use the abstract interface type AbstractGraph instead of the concrete Graph implementation, consistent with the pattern in other files.

30-31: Added JSDoc comment for graph parameter

A JSDoc comment has been added to describe the graph parameter, improving documentation clarity. The comment accurately describes the parameter's purpose.

40-41: Function parameter updated to use AbstractGraph

The type of the graph parameter in findTreeRoots has been changed from Graph to AbstractGraph, making the function more flexible by depending on the abstract interface rather than the concrete implementation.

packages/core/src/view/mixins/ValidationMixin.type.ts (1)

21-22: Consistent interface naming - updating from Graph to AbstractGraph

This change updates the module declaration and interface name from Graph to AbstractGraph, aligning with the abstraction approach being implemented across the codebase. This refactoring will provide better flexibility by allowing different graph implementations to share the same validation interface.

packages/core/src/view/mixins/PortsMixin.type.ts (1)

19-20: Consistent abstraction - changing module declaration from Graph to AbstractGraph

Good refactoring to use AbstractGraph instead of the concrete Graph implementation. This change maintains consistency with the broader architectural changes being made across the codebase and supports the goal of not loading default plugins and style builtins unless necessary.

packages/core/src/view/mixins/ZoomMixin.type.ts (1)

19-20: Updated module declaration to use AbstractGraph

This change correctly updates the module declaration to use AbstractGraph instead of Graph, maintaining consistency with the architectural changes being implemented. The zoom functionality will now extend the AbstractGraph interface, allowing for more flexible graph implementations.

packages/core/src/view/BaseGraph.ts (1)

25-30: Well-structured collaborator initialization with sensible defaults

The implementation correctly provides fallback options for each collaborator with a clean null coalescing syntax. This allows consumers to override specific collaborators while accepting defaults for others.

packages/core/src/view/mixins/PageBreaksMixin.ts (3)

20-20: Appropriate type import update.

Importing AbstractGraph instead of likely Graph aligns with the PR's objective of enhancing modularity. This change facilitates more flexible plugin loading patterns.

22-24: Good refactoring to use AbstractGraph.

Updating PartialGraph to pick properties from AbstractGraph instead of concrete Graph improves abstraction and flexibility. This change is part of a consistent pattern across the codebase to make components depend on abstractions rather than implementations.

33-35: Consistent type abstraction.

Updating PartialPageBreaks to use AbstractGraph maintains consistency with the other changes. This refactoring enhances flexibility without changing functionality.

packages/core/src/view/mixins/ConnectionsMixin.type.ts (1)

23-24: Appropriate module declaration update.

Changing the module declaration from '../Graph' to '../AbstractGraph' and updating the interface name maintains consistency with the broader refactoring to use abstract types. This change supports the PR goal of making plugin loading more efficient.

packages/core/src/view/mixins/_graph-mixins-apply.ts (2)

18-18: Consistent import update.

Importing AbstractGraph instead of Graph aligns with the rest of the refactoring changes and maintains consistency across the codebase.

43-43: Good function signature update.

Changing the parameter type to typeof AbstractGraph improves flexibility by making the applyGraphMixins function work with the abstract type instead of a concrete implementation. This enables more modular loading of graph functionality.

packages/core/src/editor/EditorToolbar.ts (2)

28-28: Appropriate import update.

Importing AbstractGraph instead of Graph maintains consistency with the other changes in the PR.

303-306: Good parameter type update and naming convention.

Changing the parameter type from graph: Graph to _graph: AbstractGraph serves two purposes:

  1. Uses the abstract type for better flexibility
  2. The underscore prefix properly indicates the parameter is unused in the function body

This change enhances code clarity while maintaining the same functionality.

packages/core/src/view/layout/PartitionLayout.ts (2)

21-21: Good addition of AbstractGraph import.

This change adds the import for the AbstractGraph type to support the constructor parameter type change, which is part of the broader refactoring to use abstract interfaces instead of concrete implementations.

42-42: Good refactoring to use AbstractGraph instead of Graph.

Changing the constructor parameter type from Graph to AbstractGraph follows the Dependency Inversion Principle. This makes the PartitionLayout class more flexible as it can now work with any implementation that satisfies the AbstractGraph interface rather than requiring a specific concrete class.

packages/core/src/view/mixins/LabelMixin.ts (3)

17-17: Good change to import AbstractGraph.

Replacing the Graph import with AbstractGraph aligns with the broader refactoring to use abstract interfaces throughout the codebase.

19-26: Good refactoring in PartialGraph type.

The change to use AbstractGraph instead of Graph in the Pick utility makes the type definition more flexible and consistent with the rest of the codebase refactoring.

27-39: Good refactoring in PartialLabel type.

The change to use AbstractGraph instead of Graph in the Pick utility follows the same pattern as the PartialGraph type, ensuring consistency throughout the mixin interfaces.

packages/core/src/view/mixins/ZoomMixin.ts (3)

19-19: Good change to import AbstractGraph.

Replacing the Graph import with AbstractGraph aligns with the broader refactoring to use abstract interfaces throughout the codebase.

21-24: Good refactoring in PartialGraph type.

The change to use AbstractGraph instead of Graph in the Pick utility makes the type definition more flexible and consistent with the rest of the codebase refactoring.

25-36: Good refactoring in PartialZoom type.

The change to use AbstractGraph instead of Graph in the Pick utility follows the same pattern as the PartialGraph type, ensuring consistency throughout the mixin interfaces.

packages/core/src/view/mixins/EventsMixin.ts (4)

44-44: Good change to import AbstractGraph.

Replacing the Graph import with AbstractGraph aligns with the broader refactoring to use abstract interfaces throughout the codebase.

47-89: Good refactoring in PartialGraph type.

The change to use AbstractGraph instead of Graph in the Pick utility makes the type definition more flexible and consistent with the rest of the codebase refactoring. This is particularly important for this type as it includes many methods and properties.

90-156: Good refactoring in PartialEvents type.

The change to use AbstractGraph instead of Graph in the Pick utility follows the same pattern as the PartialGraph type, ensuring consistency throughout the mixin interfaces. The extensive list of methods and properties picked from AbstractGraph indicates good attention to detail in the refactoring.

576-576: Good update to use AbstractGraph type.

The change to cast this as AbstractGraph instead of Graph in the fireMouseEvent method ensures type consistency throughout the codebase and aligns with the dependency inversion principle.

packages/core/src/view/layout/SwimlaneLayout.ts (3)

29-29: Good addition of the AbstractGraph type import.

This change correctly imports the AbstractGraph type that will be used to replace the concrete Graph type in the constructor, aligning with the PR's goal to make the code more modular.

43-44: Documentation properly updated to reflect type change.

The documentation has been correctly updated to reference AbstractGraph instead of Graph. The orientation parameter documentation now correctly references DIRECTION.NORTH instead of DIRECTION_NORTH, which is more consistent with the actual code.

47-47: Appropriate type signature change to use AbstractGraph.

Changing the constructor parameter from Graph to AbstractGraph is a good refactoring that improves abstraction. This change allows the layout to work with any implementation of the AbstractGraph interface, making the code more flexible and modular.

packages/core/src/view/cell/CellHighlight.ts (3)

28-28: Good addition of the AbstractGraph type import.

This change correctly imports the AbstractGraph type that will be used to replace the concrete Graph type in both the constructor parameter and class property.

65-65: Property type properly updated to AbstractGraph.

The graph property type has been correctly changed from Graph to AbstractGraph, maintaining type consistency with the constructor parameter.

86-86: Appropriate constructor parameter type change to AbstractGraph.

Changing the constructor parameter from Graph to AbstractGraph improves abstraction. This change allows CellHighlight to work with any implementation of the AbstractGraph interface, making the code more flexible and modular.

packages/core/src/view/mixins/VertexMixin.ts (3)

19-19: Good import change from Graph to AbstractGraph.

This change correctly updates the import to use AbstractGraph instead of Graph, aligning with the broader refactoring effort across the codebase.

22-22: Type definition updated to use AbstractGraph.

The PartialGraph type has been correctly updated to pick properties from AbstractGraph instead of Graph, maintaining consistency with the import changes.

24-24: PartialVertex type correctly updated to use AbstractGraph.

Updating the PartialVertex type to reference AbstractGraph instead of Graph ensures type consistency throughout the mixin implementation.

packages/core/src/view/other/Guide.ts (3)

25-25: Good addition of the AbstractGraph type import.

This change correctly imports the AbstractGraph type that will be used to replace the concrete Graph type in both the constructor parameter and class property.

35-35: Appropriate constructor parameter type change to AbstractGraph.

Changing the constructor parameter from Graph to AbstractGraph improves abstraction. This change allows Guide to work with any implementation of the AbstractGraph interface, making the code more flexible and modular.

43-43: Property type properly updated to AbstractGraph.

The graph property type has been correctly changed from Graph to AbstractGraph, maintaining type consistency with the constructor parameter.

packages/core/src/view/mixins/SwimlaneMixin.ts (3)

22-22: Good change to import AbstractGraph instead of Graph.

This change aligns with the overall refactoring to use more abstract interfaces throughout the codebase. Using abstractions rather than concrete implementations improves flexibility and maintainability.

25-27: Appropriate type update from Graph to AbstractGraph.

The PartialGraph type now picks its properties from AbstractGraph instead of Graph, which is consistent with the abstraction approach. This change maintains the same functionality while improving the architecture.

39-41: Correct update of PartialSwimlane type.

Similar to the PartialGraph change, this properly updates the source type for the property picking while maintaining the same properties and functionality.

packages/core/src/view/handler/KeyHandler.ts (4)

19-19: Good change to import AbstractGraph instead of Graph.

This import change is consistent with the overall refactoring approach of using AbstractGraph throughout the codebase.

77-77: Well-maintained documentation with updated type reference.

The JSDoc comment has been properly updated to reference AbstractGraph instead of Graph, maintaining consistency between code and documentation.

81-81: Appropriate constructor parameter type update.

Changing the constructor parameter type from Graph to AbstractGraph allows for more flexible usage of this handler with different graph implementations.

98-100: Consistent property type and documentation update.

Both the JSDoc comment and the actual property type have been updated to use AbstractGraph, maintaining internal consistency.

packages/core/src/view/plugins/RubberBandHandler.ts (3)

33-33: Good change to import AbstractGraph instead of Graph.

This import change is consistent with the broader refactoring effort across the codebase.

63-63: Appropriate constructor parameter type update.

Updating the constructor parameter type from Graph to AbstractGraph makes this handler more flexible and aligns with the dependency inversion principle.

104-104: Consistent property type update.

The graph property type has been correctly updated to AbstractGraph to match the constructor parameter.

packages/core/src/view/plugins/CellEditorHandler.ts (3)

51-51: Good change to import AbstractGraph instead of Graph.

This import change is consistent with the overall refactoring approach of using AbstractGraph throughout the codebase.

156-156: Appropriate constructor parameter type update.

Changing the constructor parameter type from Graph to AbstractGraph allows this handler to work with different graph implementations.

194-194: Consistent property type update.

The graph property type has been correctly updated to AbstractGraph to match the constructor parameter.

packages/core/src/view/animate/Morphing.ts (4)

24-24: Type import correctly updated to AbstractGraph.

The import change from Graph to AbstractGraph is consistent with the PR's objective of making the codebase more flexible by using abstractions.

53-53: Documentation updated correctly.

The JSDoc parameter description now properly references AbstractGraph instead of Graph, maintaining documentation consistency with the code changes.

59-64: Constructor signature correctly updated to use AbstractGraph.

The constructor parameter type has been properly changed to use the more abstract type, which aligns with the PR goal of implementing more flexible architecture.

66-66: Class property type correctly updated.

The internal property type is properly updated to match the constructor parameter, maintaining type consistency throughout the class.

packages/core/src/view/GraphView.ts (3)

44-44: Type import correctly updated to AbstractGraph.

The import is properly updated to use the abstract type for greater flexibility.

95-99: Constructor signature correctly updated to use AbstractGraph.

The GraphView constructor now properly uses the abstract type, allowing for more flexible implementations.

161-161: Class property type correctly updated.

The graph property type is correctly updated to AbstractGraph to match the constructor parameter.

packages/core/src/view/plugins/SelectionCellsHandler.ts (3)

24-24: Type import correctly updated to AbstractGraph.

The import statement is properly changed to use the abstract type, consistent with other files in this PR.

54-76: Constructor signature correctly updated to use AbstractGraph.

The SelectionCellsHandler constructor now properly accepts the abstract type.

81-81: Class property type correctly updated.

The graph property type is appropriately updated to AbstractGraph, maintaining type consistency across the class.

packages/core/src/view/plugins/FitPlugin.ts (3)

18-18: Type import correctly updated to AbstractGraph.

The import statement is properly updated to use the abstract type, consistent with the overall refactoring approach in this PR.

57-57: Constructor parameter type correctly updated.

The FitPlugin constructor now properly uses the AbstractGraph type, which aligns with the PR's objective of implementing more flexible architecture.

1-110: Code looks good with proper abstraction implementation.

The changes to use AbstractGraph instead of concrete Graph implementation are well-implemented throughout this file. This refactoring follows good software engineering practices by promoting loose coupling and allowing for more flexible implementations.

packages/core/src/view/event/InternalEvent.ts (2)

30-30: Import updated to use AbstractGraph

The import has been changed from using the concrete Graph type to the more abstract AbstractGraph type. This is part of a broader refactoring to make the codebase more flexible.

241-241: Method signature updated to accept AbstractGraph

The redirectMouseEvents method now accepts AbstractGraph instead of Graph. This change makes the method more flexible, enabling it to work with any implementation that conforms to the AbstractGraph interface.

packages/core/src/view/mixins/PanningMixin.ts (3)

21-21: Import changed to AbstractGraph

The import has been updated to use AbstractGraph instead of Graph, consistent with the architectural changes in the codebase.

26-29: PartialGraph type now picks from AbstractGraph

The PartialGraph type definition has been updated to pick properties from AbstractGraph instead of Graph. This ensures the mixin works with any implementation of the abstract interface.

30-31: PartialPanning type now picks from AbstractGraph

Similarly, the PartialPanning type has been updated to use AbstractGraph as its base type, maintaining consistency with the rest of the refactoring.

packages/core/src/view/mixins/SnapMixin.ts (3)

17-17: Import changed to use AbstractGraph

The import statement has been updated to import AbstractGraph instead of Graph, consistent with the architectural refactoring across the codebase.

19-19: PartialGraph type updated to pick from AbstractGraph

The PartialGraph type now picks the getView property from AbstractGraph rather than Graph, in line with the ongoing refactoring.

21-21: PartialSnap type now uses AbstractGraph

The PartialSnap type has been updated to pick properties from AbstractGraph instead of Graph, maintaining consistency with the architectural changes.

packages/core/src/view/mixins/DragDropMixin.ts (3)

17-17: Import updated to use AbstractGraph

The import statement has been modified to import AbstractGraph instead of Graph, consistent with the architectural refactoring throughout the codebase.

19-19: PartialGraph type now picks from AbstractGraph

The PartialGraph type definition has been updated to pick the getEdgeValidationError property from AbstractGraph instead of Graph, aligning with the ongoing architectural changes.

21-21: PartialDragDrop type now based on AbstractGraph

The PartialDragDrop type now picks its properties from AbstractGraph rather than Graph, maintaining consistency with the rest of the codebase's refactoring.

packages/core/src/util/xmlUtils.ts (2)

22-22: Type import updated correctly to AbstractGraph.

The import has been properly updated from Graph to AbstractGraph, which aligns with the broader refactoring effort evident across the codebase.

42-42: Parameter type updated to match import change.

The function parameter type has been correctly updated from Graph to AbstractGraph, maintaining consistency with the import change. This change allows the function to work with any implementation that satisfies the AbstractGraph interface rather than requiring the concrete Graph class.

packages/core/src/view/mixins/ConnectionsMixin.ts (3)

25-25: Import statement updated to use AbstractGraph.

The import has been correctly changed from Graph to AbstractGraph, consistent with the broader refactoring pattern across the codebase.

28-28: PartialGraph type properly updated to use AbstractGraph.

The PartialGraph type has been updated to reference AbstractGraph instead of Graph, maintaining the same picked properties. This change aligns with the dependency inversion principle by depending on abstractions rather than concrete implementations.

29-31: PartialConnections type updated to reference AbstractGraph.

The PartialConnections type definition has been updated to pick properties from AbstractGraph instead of Graph. This change is consistent with the refactoring pattern and maintains the same picked properties.

packages/core/src/view/mixins/TerminalMixin.ts (2)

19-19: Import statement updated from Graph to AbstractGraph.

The import has been correctly changed from Graph to AbstractGraph, consistent with the broader refactoring pattern across the codebase.

21-22: PartialGraph and PartialTerminal types updated to use AbstractGraph.

Both type definitions have been updated to pick properties from AbstractGraph instead of Graph. This change follows the dependency inversion principle and maintains the same interface expectations.

packages/core/src/view/handler/EdgeHandler.ts (3)

56-56: Import statement updated to use AbstractGraph.

The import has been correctly changed from Graph to AbstractGraph, consistent with the broader refactoring pattern across the codebase.

81-81: Graph property type updated to AbstractGraph in EdgeHandler class.

The type of the graph property in the EdgeHandler class has been updated from Graph to AbstractGraph. This change allows the handler to work with any implementation that conforms to the AbstractGraph interface.

2251-2251: Constructor parameter type updated in EdgeHandlerCellMarker class.

The constructor parameter type has been changed from Graph to AbstractGraph in the EdgeHandlerCellMarker class, maintaining consistency with the rest of the changes in this file and across the codebase.

packages/core/src/view/handler/ConstraintHandler.ts (3)

34-34: LGTM: Import updated from Graph to AbstractGraph

The import change looks good, correctly shifting from the concrete Graph type to the more abstract AbstractGraph type, which aligns with the PR's objective of making plugin loading more flexible.

54-56: LGTM: Documentation and type declaration updated correctly

The documentation and type declaration have been properly updated to reference AbstractGraph instead of the previous references to mxGraph and Graph.

88-88: LGTM: Constructor parameter type updated

The constructor parameter type has been correctly updated from Graph to AbstractGraph, maintaining consistency with the property type change.

packages/core/src/view/layout/HierarchicalLayout.ts (3)

28-28: LGTM: Import updated from Graph to AbstractGraph

The import statement has been correctly updated to use AbstractGraph type.

41-42: LGTM: Documentation updated correctly

The constructor documentation has been properly updated to reference AbstractGraph.

46-46: LGTM: Constructor parameter type updated

The constructor parameter type has been correctly updated from Graph to AbstractGraph.

packages/core/src/view/mixins/GroupingMixin.ts (2)

24-24: LGTM: Import updated from Graph to AbstractGraph

The import statement has been correctly updated to use AbstractGraph type.

27-27: LGTM: Type parameters updated correctly

Both PartialGraph and PartialGrouping type parameters have been properly updated from Graph to AbstractGraph, maintaining type consistency throughout the mixin.

Also applies to: 52-52

packages/core/src/view/layout/EdgeLabelLayout.ts (1)

23-23: LGTM: Import updated from Graph to AbstractGraph

The import statement has been correctly updated to use AbstractGraph type.

packages/core/src/view/layout/CompositeLayout.ts (3)

20-20: LGTM: Changed import from Graph to AbstractGraph

This change correctly updates the import to use the more abstract AbstractGraph type. This aligns with the broader refactoring effort to use a more generalized graph interface.

45-45: LGTM: Updated JSDoc parameter type

The JSDoc comment is properly updated to reflect the new AbstractGraph type, maintaining documentation consistency.

49-49: LGTM: Changed constructor parameter type

Constructor signature updated to accept the more abstract AbstractGraph type instead of Graph. This change enhances flexibility by allowing different implementations that conform to the AbstractGraph interface.

packages/core/src/view/layout/ParallelEdgeLayout.ts (1)

22-22: LGTM: Changed import from Graph to AbstractGraph

Import statement correctly updated to use the AbstractGraph type instead of Graph. This is consistent with the project-wide refactoring.

packages/core/src/view/mixins/OverlaysMixin.ts (3)

21-21: LGTM: Changed import from Graph to AbstractGraph

Import statement correctly updated to use the AbstractGraph type instead of Graph, consistent with the project-wide type refactoring.

23-25: LGTM: Updated PartialGraph type definition

The PartialGraph type definition is correctly updated to reference AbstractGraph instead of Graph. The set of picked properties remains the same, ensuring consistent behavior.

33-35: LGTM: Updated PartialOverlays type definition

The PartialOverlays type definition is correctly updated to reference AbstractGraph instead of Graph. The set of picked properties remains the same, ensuring consistent behavior.

packages/core/src/view/mixins/TooltipMixin.ts (3)

20-20: LGTM: Changed import from Graph to AbstractGraph

Import statement correctly updated to use the AbstractGraph type instead of Graph, consistent with the project-wide type refactoring.

25-28: LGTM: Updated PartialGraph type definition

The PartialGraph type definition is correctly updated to reference AbstractGraph instead of Graph, while maintaining the same set of picked properties.

29-32: LGTM: Updated PartialTooltip type definition

The PartialTooltip type definition is correctly updated to reference AbstractGraph instead of Graph, while maintaining the same set of picked properties.

packages/core/src/view/mixins/SnapMixin.type.ts (1)

20-21: Type references updated to AbstractGraph

The references have been correctly updated from Graph to AbstractGraph, which aligns with the broader refactoring in this PR to make the code more abstract and enable efficient loading of plugins.

packages/core/src/view/mixins/EditingMixin.ts (3)

20-20: Import updated to use AbstractGraph

The import statement has been properly updated to reference the AbstractGraph type instead of Graph.

24-25: Type reference updated in PartialGraph

The PartialGraph type now correctly refers to AbstractGraph instead of Graph, maintaining consistency with the rest of the refactoring.

37-38: Type reference updated in PartialEditing

The PartialEditing type now correctly refers to AbstractGraph instead of Graph, completing the refactoring in this file.

packages/core/src/view/GraphSelectionModel.ts (3)

20-20: Import updated to use AbstractGraph

The import statement has been correctly updated to reference the AbstractGraph type.

66-66: Constructor parameter type updated

The constructor parameter type has been updated from Graph to AbstractGraph, which is consistent with the PR's objective of abstracting graph implementations.

72-72: Class property type updated

The graph property type has been updated from Graph to AbstractGraph, maintaining type consistency with the constructor parameter.

packages/core/src/view/layout/CompactTreeLayout.ts (2)

27-27: Import updated to use AbstractGraph

The import statement has been correctly updated to reference the AbstractGraph type.

78-78: Constructor parameter type updated

The constructor parameter type has been updated from Graph to AbstractGraph, which is consistent with the broader refactoring effort.

packages/core/src/view/mixins/OrderMixin.ts (1)

20-20: Good architectural refactoring - switching to AbstractGraph

The changes to use AbstractGraph instead of Graph are part of a good architectural refactoring that follows the Dependency Inversion Principle. By depending on abstractions rather than concrete implementations, the code becomes more flexible and easier to maintain.

Also applies to: 24-25, 27-27

packages/core/src/view/layout/RadialTreeLayout.ts (1)

25-25: Good abstraction with AbstractGraph

The changes to use AbstractGraph instead of Graph in the constructor parameter improve the flexibility of the RadialTreeLayout class, allowing it to work with any implementation that satisfies the AbstractGraph interface.

Also applies to: 40-40

packages/core/src/view/cell/CellStatePreview.ts (1)

23-23: Consistent refactoring to AbstractGraph

The changes to use AbstractGraph are consistent with the broader refactoring effort. Good job updating both the type declarations and documentation comments to maintain consistency.

Also applies to: 30-30, 36-38

packages/core/src/view/animate/Effects.ts (1)

25-25: Consistent refactoring to AbstractGraph with improved formatting

The changes to use AbstractGraph are consistent with the broader refactoring effort. The improved formatting with parameters on separate lines enhances readability.

Also applies to: 51-51, 56-60, 136-136

packages/core/src/view/plugins/PanningHandler.ts (3)

35-35: Updated import to use AbstractGraph type.

The import has been changed to use the AbstractGraph type instead of the concrete Graph type. This aligns with the PR's objective of creating a more flexible architecture that can efficiently handle plugins.

65-65: Updated constructor parameter to use AbstractGraph.

The constructor now accepts the more abstract AbstractGraph type instead of the concrete Graph type. This change enables the PanningHandler to work with any implementation that conforms to the AbstractGraph interface.

126-126: Updated graph property type to AbstractGraph.

The graph property type has been changed to AbstractGraph, maintaining consistency with the constructor parameter change. This is a good practice to ensure type consistency throughout the class.

packages/core/src/view/layout/StackLayout.ts (2)

21-21: Updated import to use AbstractGraph type.

The import statement has been changed to use the AbstractGraph type, replacing the previous Graph type. This matches the refactoring pattern seen in other files and supports the PR's goal of creating a more flexible architecture.

40-40: Updated constructor parameter to use AbstractGraph.

The constructor's graph parameter now uses the AbstractGraph type instead of the concrete Graph type. This change allows StackLayout to work with any implementation that conforms to the AbstractGraph interface, increasing flexibility.

packages/core/src/view/handler/VertexHandler.ts (2)

29-29: Updated import to use AbstractGraph type.

The import has been changed to use the AbstractGraph type instead of the concrete Graph type. This is consistent with the changes in other files and aligns with the more abstract approach to graph handling.

58-58: Updated graph property type to AbstractGraph.

The graph property type has been changed to AbstractGraph, which makes the VertexHandler compatible with any implementation that conforms to the AbstractGraph interface rather than requiring a specific Graph implementation.

packages/core/src/view/layout/LayoutManager.ts (4)

32-32: Updated import to use AbstractGraph type.

The import statement has been changed to use the AbstractGraph type, replacing the previous Graph type import. This is consistent with the changes in other files and supports the more flexible architecture being implemented.

60-62: Updated graph property comment and type to AbstractGraph.

The property comment and type for the graph property have been updated to reference AbstractGraph instead of Graph. This change ensures proper documentation and type checking with the new abstract type.

92-92: Updated constructor parameter to use AbstractGraph.

The constructor now accepts an AbstractGraph parameter instead of the concrete Graph type. This allows the LayoutManager to be more flexible and work with any implementation that conforms to the AbstractGraph interface.

167-167: Updated setGraph method parameter type to AbstractGraph.

The setGraph method parameter type has been changed to AbstractGraph | null from Graph | null. This maintains consistency with the constructor and property type changes, ensuring type safety throughout the class.

packages/core/src/view/other/AutoSaveManager.ts (4)

21-21: LGTM: Updated import to use AbstractGraph type

The change to import the AbstractGraph type aligns with the PR's objective to improve abstraction in the codebase.

36-36: Updated constructor parameter type correctly

Changed from concrete Graph type to more abstract AbstractGraph type, maintaining the same functionality while allowing more flexible implementations.

50-52: Documentation and property type update

The reference and type for the graph property have been properly updated to AbstractGraph.

118-118: Method parameter type updated consistently

The setGraph method parameter type has been updated to match the new AbstractGraph type, maintaining consistency throughout the class.

packages/core/src/view/cell/CellMarker.ts (3)

32-32: LGTM: Updated import to use AbstractGraph type

The import has been correctly changed to reference the AbstractGraph type, consistent with the code refactoring strategy.

64-64: Property type updated correctly

The graph property type has been properly updated to AbstractGraph, aligning with the PR objectives.

122-122: Constructor parameter type updated

Changed from concrete Graph type to more abstract AbstractGraph type, consistent with other changes in the codebase.

.github/workflows/build.yml (3)

60-61: Added new build step for TypeScript example with selected features

This new build step supports the PR objective of allowing efficient loading without default plugins.

68-69: Added new build step for JavaScript example with selected features

This build step complements the TypeScript example build, providing comprehensive testing of the new feature.

78-79: Improved artifact upload paths with wildcards

Using wildcards for js-example* and ts-example* paths simplifies the configuration and makes it more maintainable as new example directories are added.

packages/core/src/view/layout/FastOrganicLayout.ts (1)

20-20: LGTM: Updated import to use AbstractGraph type

The import has been correctly changed to reference the AbstractGraph type, consistent with the code refactoring strategy.

packages/core/src/util/gestureUtils.ts (2)

20-20: Import looks good.
No concerns here; switching from Graph to AbstractGraph improves consistency with the ongoing refactor.

97-99: Updated drop target type is consistent with the AbstractGraph refactor.
Ensuring it receives an AbstractGraph instead of Graph aligns with the broader usage shift.

packages/core/src/util/printUtils.ts (6)

23-23: Import statements align with the transition to AbstractGraph.
No issues here; this import is consistent with the broader refactoring.

33-33: JSDoc annotation matches the parameter change to AbstractGraph.
This accurately reflects the method's updated expectation.

40-40: Function signature updated to use AbstractGraph.
This enhances consistency across the codebase.

166-166: JSDoc param updated to AbstractGraph.
This documentation update ensures alignment with the actual function parameter type.

173-173: show function now accepts AbstractGraph.
This refactoring is in line with the move to a more generic graph interface.

282-284: printScreen function updated to accept AbstractGraph.
Promises improved flexibility and compatibility with different graph implementations.

packages/core/src/view/Graph.ts (7)

2-2: Year updated to 2025.
No functional impact.

17-20: Refined imports for newly introduced types.
Importing GraphPluginConstructor, GraphView, and AbstractGraph aligns with the refactor.

Also applies to: 26-26

30-32: Updated class description clarifies usage.
Recommending “prototype-only” usage is clear for new consumers.

34-34: Class now extends AbstractGraph.
This is a key step in simplifying the code and providing more generic capabilities.

63-63: Override method aligns with new base class design.
Refactoring logic into registerDefaults keeps configuration consistent.

69-74: Collaborators initialization ensures consistent setup.
These lines consolidate and clarify instantiation logic, maintaining the correct default object creation.

82-82: Constructor refactored to rely on superclass parameters.
Leverages the new constructor signature in AbstractGraph.

packages/core/src/view/layout/SwimlaneManager.ts (4)

22-22: Types updated to use AbstractGraph instead of Graph.

The import statement is updated to use the AbstractGraph type, which is part of a larger refactoring to make the codebase more modular by using abstract types rather than concrete implementations.

36-37: Constructor parameter type updated to AbstractGraph.

The constructor parameter type has been changed from Graph to AbstractGraph, making the component more flexible by allowing it to work with any implementation that satisfies the AbstractGraph interface.

63-65: JSDoc and property type updated to AbstractGraph.

Documentation and property type declaration are updated to reflect the change to the AbstractGraph type, maintaining consistency throughout the class.

172-172: Method parameter type updated to AbstractGraph.

The setGraph method parameter type has been updated to AbstractGraph | null to align with the other type changes in this class.

packages/core/src/view/layout/GraphLayout.ts (4)

23-23: Import statement updated to use AbstractGraph.

The import has been updated to use the AbstractGraph type, consistent with the pattern seen across other files in this PR.

36-36: Constructor parameter type updated to AbstractGraph.

The constructor parameter type has been changed from Graph to AbstractGraph, continuing the consistent pattern of using more abstract types.

41-43: JSDoc and property type updated to AbstractGraph.

The documentation comment and property type declaration have been updated to reflect the change to AbstractGraph.

99-99: Method return type updated to AbstractGraph.

The return type of the getGraph method has been updated to AbstractGraph to maintain type consistency throughout the class.

packages/core/src/view/other/PrintPreview.ts (4)

27-27: Import statement updated to use AbstractGraph.

The import statement has been updated to use the AbstractGraph type instead of Graph, following the same pattern as other files in this PR.

150-150: Constructor parameter type updated to AbstractGraph.

The constructor parameter type has been updated from Graph to AbstractGraph, maintaining consistency with the architectural changes.

174-176: JSDoc and property type updated to AbstractGraph.

The documentation and property type have been consistently updated to use AbstractGraph instead of Graph.

313-314: Method parameter type updated to AbstractGraph.

The appendGraph method's parameter type has been updated to AbstractGraph, completing the type transition in this class.

packages/core/src/view/plugins/SelectionHandler.ts (6)

24-24: Import statement updated to use Guide directly.

The import has been changed from mxGuide to Guide, likely as part of a broader effort to standardize class naming by removing the "mx" prefix.

43-43: Import AbstractGraph type.

Added import for the AbstractGraph type, consistent with changes in other files.

58-61: Improved JSDoc documentation.

The documentation has been enhanced to provide clearer explanation about how individual cells are handled within the selection process and the relationship with SelectionCellsHandler.

75-75: Constructor parameter type updated to AbstractGraph.

The constructor parameter type has been updated from Graph to AbstractGraph, consistent with the pattern in other files.

172-172: Property type updated to AbstractGraph.

The graph property type has been updated to AbstractGraph to maintain type consistency throughout the class.

730-731: Updated Guide instantiation.

The createGuide method now instantiates Guide instead of mxGuide, reflecting the import change on line 24 and maintaining consistency with the naming changes.

packages/core/src/view/plugins/PopupMenuHandler.ts (2)

23-23: LGTM: Updated import to use AbstractGraph.

This change is part of the refactoring to use the more abstract graph interface, which aligns with the goal of allowing efficient loading of components.

40-40: Good update to use AbstractGraph interface.

Changing the graph parameter and property types from concrete Graph to AbstractGraph increases flexibility and modularity. This allows PopupMenuHandler to work with any graph implementation that adheres to the AbstractGraph interface.

Also applies to: 64-64

packages/core/src/view/plugins/ConnectionHandler.ts (4)

57-57: LGTM: Updated import to use AbstractGraph.

This import change is consistent with the overall refactoring to use the AbstractGraph interface.

220-220: Appropriate type change to use AbstractGraph.

Updating the graph property type to AbstractGraph allows for better abstraction and modularity in the codebase.

388-388: Good update to the constructor parameter type.

Using AbstractGraph instead of Graph for the constructor parameter aligns with the property type and follows the pattern of interface-based programming.

1991-1991: Consistent type update in ConnectionHandlerCellMarker.

The type change for the graph parameter in the nested class maintains consistency with the parent class changes.

packages/core/src/util/Clipboard.ts (2)

20-20: LGTM: Updated import to use AbstractGraph.

This import change aligns with the refactoring pattern seen across the codebase.

126-126: Good update to static method signatures.

All static methods now accept AbstractGraph instead of Graph, making the Clipboard utility more flexible and able to work with different graph implementations. This is consistent with the goal of allowing more efficient component loading.

Also applies to: 140-140, 152-152, 167-167

packages/core/src/view/other/Outline.ts (4)

30-31: LGTM: Updated imports for AbstractGraph and BaseGraph.

These imports support the refactoring to use more abstract interfaces and provide the concrete implementation needed in this file.

82-82: Good update to use AbstractGraph for class properties and parameters.

Changing the types of source, outline properties, and constructor parameter to AbstractGraph allows for more flexibility in the graph implementations that can be used with Outline.

Also applies to: 236-236, 241-241

320-325: Good refactoring of createGraph method.

The method now returns AbstractGraph and delegates the actual creation to createGraphInstance, which allows for better extensibility.

327-338: Well-structured implementation of createGraphInstance.

This new protected method enables customization of the graph instance creation without requiring plugins, aligning with the PR objective to efficiently not load default plugins. The comments provide good explanation of the rationale and potential extension points.

The BaseGraph instantiation with minimal configuration is appropriate for an outline view that doesn't need all the features of a full graph.

packages/core/src/view/AbstractGraph.ts (2)

476-481: Confirm necessity of registerDefaults
This method is currently empty and only shows a TODO comment. If the intention is to prevent auto-loading of defaults, consider removing it altogether or adding relevant logic with an explanatory comment.

247-264: Verify boundary conditions in fit method
When the container is very small or has unusual scroll behaviors, the logic in fit could lead to unexpected scaling. Verify that extreme cases (e.g., zero-size container, forcibly large scale) are handled gracefully.

packages/core/src/view/other/DragSource.ts (1)

583-649: Validate runtime checks when transferring events to graph
The dragOver method attempts to compute a valid drop coordinate and highlight targets, but concurrency with rapidly changing container layouts or scroll offsets can cause off-by-few-pixels mismatches. Ensure edge cases (like container resizing while dragging) are handled.

🧰 Tools
🪛 Biome (1.9.4)

[error] 616-616: Change to an optional chain.

Unsafe fix: Change to an optional chain.

(lint/complexity/useOptionalChain)

packages/core/src/view/other/Multiplicity.ts (1)

135-178: Ensure error messages are localized
You're using translate(...) for the errors in countError and typeError. Confirm that all relevant user-facing strings are similarly translated and that fallback strings do not conflict with the new workflow.

packages/core/src/view/layout/hierarchical/CoordinateAssignment.ts (2)

31-31: Good addition of the AbstractGraph type import.

The import statement correctly uses TypeScript's type import, which ensures this is only used for type checking and will not affect runtime behavior.

667-667: LGTM: Parameter type refactoring from Graph to AbstractGraph

This change is part of a broader refactoring effort to use the more abstract AbstractGraph type instead of the concrete Graph implementation. This follows the Dependency Inversion Principle (part of SOLID), making the code more flexible and enhancing extensibility.

Also applies to: 694-694, 762-762, 863-863, 1033-1033

packages/core/__tests__/utils.ts
Comment on lines +20 to +21
// TODO add tests that use BaseGraph to ensure everything works fine

Copy link

@coderabbitai coderabbitai bot Apr 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

TODO comment is appropriate, but existing utility functions need updating.

The TODO comment correctly identifies the need for tests with BaseGraph. However, I notice that the utility functions below (lines 23-25) still return the concrete Graph type rather than AbstractGraph or BaseGraph. Consider updating these functions as part of this refactoring effort.

- export const createGraphWithoutContainer = (): Graph => new Graph(null!);
+ export const createGraphWithoutContainer = (): AbstractGraph => new Graph(null!);

- export const createGraphWithoutPlugins = (): Graph => new Graph(null!, null!, []);
+ export const createGraphWithoutPlugins = (): AbstractGraph => new Graph(null!, null!, []);

Additionally, consider adding new utility functions specifically for BaseGraph:

export const createBaseGraphWithoutContainer = (): AbstractGraph => new BaseGraph(null!);
export const createBaseGraphWithoutPlugins = (): AbstractGraph => new BaseGraph(null!, null!, []);

packages/core/src/util/gestureUtils.ts
export const makeDraggable = (
element: Element,
graphF: Graph | Function,
graphF: AbstractGraph | Function,
Copy link

@coderabbitai coderabbitai bot Apr 7, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🛠️ Refactor suggestion

Replace the generic Function type with a properly defined signature.
Using Function can hide potential type issues. A more specific signature clarifies the expected parameters/return value.

A possible fix could be:

-  graphF: AbstractGraph | Function,
+  graphF: AbstractGraph | ((evt: MouseEvent) => AbstractGraph | null),

Adjust the return type as needed to match the logic of graphF.

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
graphF: AbstractGraph | Function,
graphF: AbstractGraph | ((evt: MouseEvent) => AbstractGraph | null),
🧰 Tools
🪛 Biome (1.9.4)

[error] 89-89: Don't use 'Function' as a type.

Prefer explicitly define the function shape. This type accepts any function-like value, which can be a common source of bugs.

(lint/complexity/noBannedTypes)

Copy link
Member Author

@tbouffard tbouffard Apr 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I am aware of this. This should be fixed in #616

Copy link

@coderabbitai coderabbitai bot Apr 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tbouffard Got it! Thanks for letting me know that this issue will be addressed in PR #616. I appreciate the clarification.

@tbouffard tbouffard marked this pull request as draft April 7, 2025 18:03
@sonarqubecloud
Copy link

sonarqubecloud bot commented Apr 8, 2025

Quality Gate Failed Quality Gate failed

Failed conditions
7.5% Duplication on New Code (required ≤ 3%)

See analysis details on SonarQube Cloud

@tbouffard tbouffard mentioned this pull request Apr 11, 2025
Closed
14 tasks
@tbouffard
Copy link
Member Author

tbouffard commented Apr 22, 2025

POC completed, so I am closing this PR

@tbouffard tbouffard closed this Apr 22, 2025
@tbouffard tbouffard deleted the poc/introduce_BaseGraph branch April 22, 2025 15:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@coderabbitai coderabbitai[bot] coderabbitai[bot] left review comments

Assignees

No one assigned

Labels

enhancement New feature or request

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@tbouffard