Skip to content

refactor: move plugins to a dedicated folder #735

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
Merged
tbouffard merged 3 commits into from
Mar 27, 2025
Merged

refactor: move plugins to a dedicated folder #735

tbouffard merged 3 commits into from
Mar 27, 2025

Conversation

@tbouffard
Copy link
Member

@tbouffard tbouffard commented Mar 27, 2025 •
edited by coderabbitai bot
Loading

This is an internal change only, designed to facilitate the organization of plugins. There is no impact for maxGraph users.

In addition:

  • use "type" imports for plugin when possible
  • remove duplication when calling plugins

Summary by CodeRabbit

  • Refactor

    • Improved internal module organization and type handling to streamline interaction components and enhance code clarity.
    • Centralized access to key functionality, reducing redundancy while maintaining existing behaviors.

  • Chore

    • Removed deprecated public API elements, simplifying the interface for advanced integrations without altering overall functionality.

@tbouffard
refactor: move plugins to a dedicated folder
584a880 
This is an internal change only, designed to facilitate the organization of plugins. There is no impact for maxGraph users.

In addition:
  - use "type" imports for plugin when possible
  - remove duplication when calling plugins
@tbouffard tbouffard added the refactor Code refactoring label Mar 27, 2025
@coderabbitai
Copy link

coderabbitai bot commented Mar 27, 2025 •
edited
Loading

Walkthrough

This pull request refactors the import paths across many files by moving handler modules from a "handler" directory to a "plugins" directory. Most imports are now marked as type-only, and several files have been updated to use helper methods for retrieving plugins. In addition, some public exports have been removed from the main index, and the exports in the plugins directory have been reorganized. These changes affect numerous files, primarily altering module resolution and type annotations without changing runtime behavior.

Changes

Affected Files Change Summary
packages/core/src/editor/Editor.ts, packages/core/src/view/Graph.ts, packages/core/src/view/GraphView.ts, packages/core/src/view/mixins/ConnectionsMixin.ts, packages/core/src/view/mixins/EditingMixin.ts, packages/core/src/view/mixins/EventsMixin.ts, packages/core/src/view/mixins/PanningMixin.ts, packages/core/src/view/mixins/TooltipMixin.ts, packages/core/src/view/other/DragSource.ts, packages/core/src/view/handler/EdgeHandler.ts, packages/core/src/view/handler/KeyHandler.ts Updated import paths from "handler" to "plugins" and converted several imports to type-only.
packages/core/src/view/handler/VertexHandler.ts, packages/core/src/view/cell/CellRenderer.ts, packages/core/src/view/plugins/SelectionCellsHandler.ts, packages/core/src/view/plugins/SelectionHandler.ts Refactored type imports, restructured variable declarations, and added private helper methods to encapsulate plugin retrieval.
packages/core/src/index.ts Removed exports for multiple handler components to reduce the public API.
packages/core/src/view/plugins/CellEditorHandler.ts, packages/core/src/view/plugins/ConnectionHandler.ts, packages/core/src/view/plugins/PopupMenuHandler.ts, packages/core/src/view/plugins/TooltipHandler.ts, packages/core/src/view/plugins/index.ts Modified specific import paths and type annotations, and added new export statements to update the plugins’ public interface.

Sequence Diagram(s)

sequenceDiagram
    participant VH as VertexHandler
    participant G as Graph
    VH->>VH: getSelectionHandler()
    VH->>G: getPlugin("SelectionHandler")
    G-->>VH: SelectionHandler instance
    VH->>VH: Process selection operations
Loading 
sequenceDiagram
    participant SH as SelectionHandler
    participant G as Graph
    SH->>SH: getSelectionCellsHandler()
    SH->>G: getPlugin("SelectionCellsHandler")
    G-->>SH: SelectionCellsHandler instance
    SH->>SH: Execute handler operations
Loading

Possibly related PRs

📜 Recent review details

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

📥 Commits

Reviewing files that changed from the base of the PR and between dc45405 and a20c70a.

📒 Files selected for processing (21)
  • packages/core/src/editor/Editor.ts (1 hunks)
  • packages/core/src/index.ts (0 hunks)
  • packages/core/src/view/Graph.ts (1 hunks)
  • packages/core/src/view/GraphView.ts (1 hunks)
  • packages/core/src/view/cell/CellRenderer.ts (2 hunks)
  • packages/core/src/view/handler/EdgeHandler.ts (1 hunks)
  • packages/core/src/view/handler/KeyHandler.ts (1 hunks)
  • packages/core/src/view/handler/VertexHandler.ts (3 hunks)
  • packages/core/src/view/mixins/ConnectionsMixin.ts (1 hunks)
  • packages/core/src/view/mixins/EditingMixin.ts (1 hunks)
  • packages/core/src/view/mixins/EventsMixin.ts (1 hunks)
  • packages/core/src/view/mixins/PanningMixin.ts (1 hunks)
  • packages/core/src/view/mixins/TooltipMixin.ts (1 hunks)
  • packages/core/src/view/other/DragSource.ts (1 hunks)
  • packages/core/src/view/plugins/CellEditorHandler.ts (1 hunks)
  • packages/core/src/view/plugins/ConnectionHandler.ts (1 hunks)
  • packages/core/src/view/plugins/PopupMenuHandler.ts (1 hunks)
  • packages/core/src/view/plugins/SelectionCellsHandler.ts (3 hunks)
  • packages/core/src/view/plugins/SelectionHandler.ts (8 hunks)
  • packages/core/src/view/plugins/TooltipHandler.ts (1 hunks)
  • packages/core/src/view/plugins/index.ts (1 hunks)
💤 Files with no reviewable changes (1)
  • packages/core/src/index.ts
⏰ Context from checks skipped due to timeout of 90000ms (1)
  • GitHub Check: build (windows-2022)
🔇 Additional comments (35)
packages/core/src/view/plugins/SelectionCellsHandler.ts (4)

28-29: Update is aligned with the plugin reorganization goal.

The import statements have been changed to use type imports and point to the new handler directory path, which is in line with the PR objective of moving plugins to a dedicated folder.

32-32: Good type alias introduction.

Creating a Handler type alias simplifies the code and reduces duplication of the union type throughout the file.

101-101: Clean type reference update.

Updated to use the newly created Handler type alias instead of the inline union type.

210-210: Consistent type usage.

Method parameter type updated to use the Handler type alias, maintaining consistency throughout the file.

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

53-53: Proper use of type import.

The import of TooltipHandler has been changed to a type-only import, which is appropriate since it's only used for type checking in the getPlugin<TooltipHandler>() calls and not directly instantiated in this file.

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

43-43: Import path updated correctly.

The import path for ConstraintHandler has been updated to reference the module from the handler directory rather than the current directory. Note that this is not a type import since ConstraintHandler is instantiated in the constructor.

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

26-26: Appropriate type import conversion.

The import of TooltipHandler has been changed to a type-only import, which is correct since it's only used for type checking in the getPlugin<TooltipHandler>() calls and not directly instantiated in this file.

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

25-25: Import path updated correctly.

The import path for PanningHandler has been updated from the handler directory to the plugins directory, aligning with the refactoring objective of moving plugins to a dedicated folder.

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

21-21: Import path updated correctly.

The import path for CellEditorHandler has been updated from the handler directory to the plugins directory, consistent with the plugin reorganization.

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

45-45: Import updated to type-only and path changed.

The import for SelectionHandler has been improved in two ways:

  1. Changed to a type-only import, which helps with tree-shaking
  2. Updated the path from ../handler/SelectionHandler to ../plugins/SelectionHandler

This aligns with both objectives of the refactoring: moving plugins to a dedicated folder and implementing type imports.

packages/core/src/view/plugins/TooltipHandler.ts (1)

27-27: Import updated to type-only.

The import for PopupMenuHandler has been changed to a type-only import, which optimizes the bundle size by ensuring this import is only used for TypeScript type checking and will be removed during compilation.

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

29-29: Import updated to type-only and path changed.

The import for CellEditorHandler has been improved in two ways:

  1. Changed to a type-only import, which is beneficial for tree-shaking
  2. Updated the path from ./CellEditorHandler to ../plugins/CellEditorHandler

This change correctly implements both objectives of the refactoring initiative.

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

26-26: Update import path for ConnectionHandler
The import statement has been updated to import the type from the new location under the plugins directory. This change is consistent with the overall reorganization and does not affect runtime behavior.

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

41-41: Update import path for PopupMenuHandler
The import for PopupMenuHandler has been changed from ./handler/PopupMenuHandler to ./plugins/PopupMenuHandler and is now imported as a type. This aligns with the expected refactor and improves module organization.

46-46: Update import path for TooltipHandler
The import for TooltipHandler has been updated to use the new path ./plugins/TooltipHandler. This update reflects the broader shift of handler types from the handler directory to the plugins directory, with no side effects on runtime behavior.

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

20-20: Update import path for PanningHandler
The import now references ../plugins/PanningHandler instead of the old path. This change is part of the project’s refactor to consolidate plugins, and it maintains proper type-only usage.

24-24: Update import path for SelectionCellsHandler
The import for SelectionCellsHandler now comes from ../plugins/SelectionCellsHandler. This modification is consistent with the restructuring initiative to reduce duplication and enhance modularity in the codebase.

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

22-23: Update import paths for SelectionCellsHandler and TooltipHandler
Both import statements have been updated to use the new path under ../plugins/. This change is fully aligned with the PR objectives to reorganize handlers and streamline type imports, with no impact on runtime functionality.

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

64-64: Update SelectionHandler Import Path

The import for SelectionHandler has been updated to a type-only import from the new plugins directory. This change ensures that only type information is brought in at compile time and reflects the new project structure.

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

37-38: Refactor Imports for PanningHandler and ConnectionHandler

The existing imports have been modified to type-only imports from the new plugins directory. This update aligns with the refactoring goals by moving handler modules into the plugins folder and ensures that runtime code isn’t unnecessarily imported.

43-45: Refactor Imports for CellEditorHandler and TooltipHandler

The import statements for CellEditorHandler and TooltipHandler have been updated to reference the new plugins directory using type-only imports. This reorganization improves maintainability and enforces clear separation between type and runtime dependencies.

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

50-50: Good use of type imports for plugins.

The change to import SelectionCellsHandler as a type aligns well with the PR objective to implement "type" imports for plugins wherever feasible. This approach provides type safety while avoiding unnecessary runtime dependencies.

1383-1385: Clean plugin retrieval implementation.

Using the plugin system with getPlugin<SelectionCellsHandler>('SelectionCellsHandler') is a good approach that enables better decoupling between components. This consistent pattern makes the code more maintainable and aligns with the refactoring goal of centralizing plugin management.

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

38-39: Good use of type imports for plugins.

Converting imports to type-only imports for SelectionHandler and SelectionCellsHandler helps reduce unnecessary runtime dependencies while maintaining type safety.

339-341: Good encapsulation with private helper method.

Creating a private helper method to retrieve the SelectionHandler plugin centralizes this logic, making the code more maintainable and reducing duplication. This is an example of good refactoring that improves code organization.

347-347: Consistent use of the helper method.

Using the new getSelectionHandler() method instead of directly accessing the plugin improves code consistency and readability.

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

17-25: Good module organization with local imports.

The updated import paths reflect the new project structure with plugins in a dedicated folder. This organization improves code maintainability by grouping related functionality together.

27-36: Well-structured barrel file exports.

Implementing a comprehensive barrel file that exports all plugins and types provides a clean public API for the plugins module. This approach simplifies imports throughout the codebase and provides a single point of access for all plugin functionality.

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

47-54: Good use of type-only imports for handler dependencies.

Converting these handler imports to type-only imports (type SelectionCellsHandler, etc.) is good practice since they're only needed for type checking and not at runtime, helping with potential circular dependencies and reducing bundle size.

130-131: Improved code organization by using encapsulated plugin retrieval.

Refactoring direct calls to this.graph.getPlugin<SelectionCellsHandler>('SelectionCellsHandler') into a dedicated helper method makes the code more maintainable and reduces duplication.

Also applies to: 1055-1056, 1470-1471

1354-1356: Improved function documentation.

Documentation comment has been updated to correctly indicate that the cells parameter is an array of Cell objects, which improves code clarity.

1658-1660: Good encapsulation with private helper method.

The addition of a private helper method getSelectionCellsHandler() is a good practice that centralizes plugin retrieval logic and makes the code more maintainable by reducing duplication.

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

50-57: Properly updated import paths to reflect new plugin directory structure.

Imports have been updated to reference the new plugin locations, with appropriate use of type-only imports for handlers that are only needed for type checking.

1421-1426: Code consistency maintained with updated plugin imports.

References to the imported handlers within the file maintain correct functionality while utilizing the new import structure, ensuring the refactoring doesn't break existing behavior.

🧰 Tools
🪛 Biome (1.9.4)

[error] 1424-1424: The function should not return a value because its return type is void.

The function is here:

'void' signals the absence of value. The returned value is likely to be ignored by the caller.

(lint/correctness/noVoidTypeReturn)

2392-2403: Consistent use of the updated plugin imports in method implementations.

The setMode method properly uses the new type-annotated PanningHandler import while maintaining the same functionality as before, demonstrating a clean refactoring approach.

✨ Finishing Touches
  • 📝 Generate Docstrings

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share
🪧 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.

@tbouffard tbouffard marked this pull request as ready for review March 27, 2025 10:18
@sonarqubecloud
Copy link

sonarqubecloud bot commented Mar 27, 2025

Quality Gate Passed Quality Gate passed

Issues
110 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.5% Duplication on New Code

See analysis details on SonarQube Cloud

@tbouffard tbouffard merged commit 6acaeff into main Mar 27, 2025
7 checks passed
@tbouffard tbouffard deleted the refactor/move_plugins_to_dedicated_folder branch March 27, 2025 12:15
@coderabbitai coderabbitai bot mentioned this pull request Jul 29, 2025
Merged
This was referenced Dec 17, 2025
Merged
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

refactor Code refactoring

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@tbouffard