Further possible improvements to Desk tool and Structure configuration

[alejandrovrojas]

A broader look at the new config API (according to the current docs) looks something like this:

export default createConfig({
  plugins: [
    deskTool({
      structure,
      defaultDocumentNode
    })
  ],

  schema: {
    templates,
    types,
  },

  document: {
    actions,
    productionUrl,
    newDocumentOptions
  },

  auth,
  tools,
  form,

  /*etc*/
});

The fact that the Desk Tool still has to be imported as a plugin, with the structure builder configuration being an optional parameter stands out to me for a number of reasons:

1. It is my understanding that the new config API attempts to move on from the "everything is a plugin" mantra that Sanity has held for a while. While plugins are still very useful for alternate ways of presenting data, plugins have never actually been a viable (alternate) way for editing content. In the same way that implementing custom input components had long been a hard task that sometimes depended on internal APIs (until now), any kind of document editing action/view/component implemented outside of the desk tool becomes a nightmare of many moving parts prone to being broken with each subsequent studio update. This has made the desk tool not just the best tool for editing content in Sanity, but really the only logical choice. If the Sanity Studio is the default way of accessing your content, the Desk tool is the default way of editing it.
2. Likewise, there is an argument to be made that the Sanity studio is the desk tool. I'm sure there's Sanity users out there using the studio exclusively through custom views/workflows, but the vast majority of users will use, and completely depend on the desk tool for all tasks related to content editing for the same reason explained above.
3. The desk tool being a separate plugin is a technical leftover from the parts system days that long time Sanity users might understand on a technical level, but is otherwise strange and inconsistent for newcomers: what's the point of the desk tool being an external plugin if I will have to import it every time for every project?
4. Document actions, badges, production url, etc. are just as "tied" to the desk tool as the structure builder is – in the sense that they're all different APIs that provide UI affordances related to content editing and should therefore be part of the same configuration scheme. Meaning that the structure and defaultDocumentNode parameters should at least be properties of the main configuration file, the way document properties are (even if the sanity team insists on keeping the desk tool as a separate plugin):

export default createConfig({
  plugins: [
    deskTool()
  ],

  desk: {
    structure,
    defaultDocumentNode
  },

  document: {
    actions,
    productionUrl,
    newDocumentOptions
  }
});

What we have right now is a messy combination of some configuration going in the main config object under one property, some going as parameter to a "plugin" that has to be imported to another property of the same object – all for setting up separate pieces of the "same" UI structure. The fact that these different pieces have a branding of their own is (arguably) also an obstacle for users to understand the Sanity Studio as a whole: New users might have an easier time "installing the Sanity Studio and configuring the pane settings", whereas "configuring the Desk Tool plugin of the Sanity Studio using the Structure Builder API" is a different heuristic altogether.

5. There is potential to simplify the structure API even further, much like the Form API has done for input components. For example, using a new imaginary desk property, while keeping the same structure API nomenclature for the sake of argument:

export default createConfig({
  desk: [
    {
      title: 'Desk 1',
      structure: {
        type: 'list',
        title: 'Content',
        showIcons: false,
        items: [
        {
          type: 'listItem',
          title: 'Settings',
          child: {
            type: 'document',
            title: 'Settings',
            schemaType: 'settings_singleton'
          }
        },
        {
          type: 'divider'
        },
        {
          type: 'documentTypeListItem',
          documentType: 'orders'
        },
        {
          type: 'documentTypeListItem',
          documentType: 'orders'
        }
        ]
      }
    }
  ]

  schema: {
    templates,
    types,
  },

  document: {
    actions,
    productionUrl,
    newDocumentOptions
  }
});

Such a configuration is arguably more readable and composable than the current API.

[kmelve]

Thanks for the comprehensive feedback @alevroub! We want to address it properly, but we need to wait for the minds behind this to come back from (a well-deserved) vacay. Stay tuned!