feat(structure): add ability to override the tool's canHandleIntent logic

[marcusforsberg]

Description

What issue(s) does this solve?

For Studios with multiple Structure Tools, there's currently no convenient way to decide what "instance" of the Structure Tool should or should not handle a given intent.

In our projects we generally have one Structure tool called "Content" which is used to edit document types such as pages, posts, authors, and another Structure tool called "Settings" which contains things like global config, navigation menus and redirect rules.

As of now, if the user is currently working on a document in the "Settings" tool and uses the Create button or the global search to create or edit a document type that is not even available in that tool, it will still react to the intent, leaving the user in a confusing state where they're editing a document which isn't "available" in that tool (i.e not visible in the navigation pane):

In this screenshot, I'm on the Settings tool and used CMD + K to select a "page" document. Pages aren't available under Settings, since they're edited under Content. Ideally, I should have been redirected to the "Content" tool which can correctly handle this edit intent.

What changes are introduced?
This adds a new config option to the Structure Tool, canHandleIntent, which allows users to override the intent handling logic on a per-instance basis. The default callback for canHandleIntent is also exported, so that it can be used as a fallback within custom handlers.

Here's how it can be used:

// This Structure Tool only wants to handle intents for "author" documents
structureTool({
  title: 'Authors',
  name: 'authors',
  canHandleIntent: (intent, params) => {
    if (params.type !== 'author') return false

    // Imported from `sanity/structure`, allowing me to re-use the default logic as fallback
    return canHandleIntent(intent, params)
  },
}),

What to review

This is my first PR to Sanity core, so I'm not even sure if this is the best option here or if it's even something you wish to add support for. It's a small enough change that it shouldn't affect anything negatively, but I'm open to feedback on better ways to achieve the same end goal of having multiple Structure tools handle different intents.

Technically this is already possible to pull off by doing something like this in the project config:

tools: (prev) => {
  return prev.map((tool) => ({
    ...tool,
    canHandleIntent: (intent, params, payload) => {
      if (tool.name === 'authors' && params.type !== 'author') return false

      return tool.canHandleIntent ? tool.canHandleIntent(intent, params, payload) : false
    },
  }))
},

For all I know, this is the way it's designed, in which case this PR can be disgarded. 😊
Personally, I feel like being able to do this logic when actually defining each individual tool is in some ways easier to read. On the other hand, overriding it "globally" like this allows for more complex logic if you have many different Structure tools.

So all in all: this PR is a suggestion and if nothing else I'm hoping it can lead to some official recommendation on what is the best practice. 😊

Testing

I tested this manually in the Test Studio by adding a second Structure tool that only reacts to create and edit intents for the author type.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
page-building-studio	❌ Failed (Inspect)			Oct 11, 2024 10:55am
performance-studio	❌ Failed (Inspect)			Oct 11, 2024 10:55am

1 Skipped Deployment

Name	Status	Preview	Comments	Updated (UTC)
studio-workshop	⬜️ Ignored (Inspect)	Visit Preview		Oct 11, 2024 10:55am

[vercel]

@marcusforsberg is attempting to deploy a commit to the Sanity Sandbox Team on Vercel.

A member of the Team first needs to authorize it.