Skip to content

Separate resource-related editor actions for external widgets#3099

Draft
nighca wants to merge 1 commit intogoplus:devfrom
nighca:issue-3086
Draft

Separate resource-related editor actions for external widgets#3099
nighca wants to merge 1 commit intogoplus:devfrom
nighca:issue-3086

Conversation

@nighca
Copy link
Copy Markdown
Collaborator

@nighca nighca commented Apr 30, 2026

Summary

Separate resource-related editor actions from the generic XGo code editor UI and route spx-specific resource behavior through the resource provider boundary.

Changes

  • Add optional resource-provider hooks for resource rename and go-to actions.
  • Move spx-specific resource rename/go-to behavior into SpxResourceProvider.
  • Extract shared spx resource rename helpers reused by asset UI actions and code-editor resource actions.
  • Add useModalInvoker so modal invocation can be passed as a dependency to shared helpers.
  • Keep the generic XGo code editor UI focused on built-in editor behavior instead of spx-specific resource handling.

Closes #3086

Copy link
Copy Markdown

@gemini-code-assist gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

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

Code Review

This pull request refactors the resource renaming and navigation logic by moving these responsibilities from UI components to the ResourceProvider. It extends the IResourceProvider interface with optional renameResource and goToResource methods and introduces a useModalInvoker hook for dynamic modal management. The review feedback suggests calling provider methods directly rather than using .call() for more idiomatic and readable code.

Comment on lines +128 to +136
const { goToResource } = provider
if (goToResource != null) {
this.registerCommand(builtInCommandGoToResource, {
icon: 'goto',
title: { en: 'View detail', zh: '查看详情' },
handler: async (resource) => {
await goToResource.call(provider, resource)
}
})
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

medium

Instead of destructuring the goToResource method and using .call(), it is cleaner and more idiomatic to call the method directly on the provider instance. This avoids the need for explicit context binding and improves readability.

    if (provider.goToResource != null) {
      this.registerCommand(builtInCommandGoToResource, {
        icon: 'goto',
        title: { en: 'View detail', zh: '查看详情' },
        handler: async (resource) => {
          await provider.goToResource!(resource)
        }
      })
    }

Comment on lines +140 to +148
const { renameResource } = provider
if (renameResource != null) {
this.registerCommand(builtInCommandRenameResource, {
icon: 'rename',
title: { en: 'Rename', zh: '重命名' },
handler: async (resource) => {
await renameResource.call(provider, resource, this.codeEditor)
}
})
Copy link
Copy Markdown

Choose a reason for hiding this comment

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

medium

Similar to goToResource, calling renameResource directly on the provider instance is preferred over destructuring and using .call(). This follows standard TypeScript practices for method invocation when the object context is available.

    if (provider.renameResource != null) {
      this.registerCommand(builtInCommandRenameResource, {
        icon: 'rename',
        title: { en: 'Rename', zh: '重命名' },
        handler: async (resource) => {
          await provider.renameResource!(resource, this.codeEditor)
        }
      })
    }

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Separate resource-related editor actions for the external widget scenario

1 participant