Feature request: Include document language (or field values) in edit intent params for canHandleIntent routing

[stianmartinsen]

Is your feature request related to a problem? Please describe.
We have a lot of content and languages, so we organize the Studio content structure by language at the top level:

• Norwegian
  • Pages
  • Products
• English
  • Pages
  • Products

When we search for a document in the studio using the global search and click to edit an English page, the Norwegian structure is expanded.

Describe the solution you'd like
When Studio resolves an edit intent, canHandleIntent should receive enough information to match language-filtered structure panes. Ideally a filtered documentList should only handle edit intents matching documents with the same filters by default.

If that's not possible, it would be nice to be able to select which document attributes are passed to the params in the canHandleIntent callback so we could do this:

documentList()
  .filter('_type == $type && language == $language')
  .params({ type: 'destination', language: 'en' })
  .canHandleIntent((intentName, params) => {
    return (
      intentName === 'edit' &&
      params.type === 'destination' &&
      params.language === 'en'
    )
  })

Describe alternatives you've considered
I've tried other ways of structuring the studio, but because of the amount of content it makes sense for us to group content by language in the structure.

[jordanl17]

Thanks Stian, the writeup is really clear which helps a lot.

Quick context on where we are today: canHandleIntent only sees what got encoded into the intent params, and the built-in global search dispatches only {id, type}. The resolver never loads the document itself, so language isn't reachable from inside the callback - which is why your filtered pane loses to the default one.

A couple of things that might already get you closer today:

1. If you're using @sanity/document-internationalization configured to prefix IDs (e.g. en.about), you can match on params.id inside canHandleIntent without any framework change. One thing to watch: the resolver picks the shallowest matching pane, so this only works if no default documentTypeListItem('destination') sits higher up in your structure - otherwise that one wins before your filtered pane is ever asked.
2. Custom dispatchers can already pass arbitrary params into the intent (Presentation does this, for example). So if the navigation that's hurting you is something you own rather than the global search, you can pass language through yourself today.

For the global-search path though, this is a genuine gap. Closing it properly would mean either having the dispatcher echo selected fields into the intent, or making canHandleIntent async so the resolver can fetch the doc first. Both are doable, neither is small.

Two things that would help us scope it:

1. Is language the only field you need to disambiguate on, or are there others?
2. Is the language derivable from the _id in your setup, or only from a field?

[stianmartinsen]

Thanks for your reply!

1. Is language the only field you need to disambiguate on, or are there others?

There are others as well.

2. Is the language derivable from the _id in your setup, or only from a field?

Only from a field.

I was also thinking about other places where we search for content, like in the Content Agent. It would be nice if this also worked when clicking a document there.