Horizontal top navigation for document types: customization approaches

6 replies
Last updated: Oct 12, 2021
Hello! We’re looking into customizing the Sanity studio and want see if we can create a layout where there is a horizontal top navigation header with buttons that lead to editing different document types, i.e. a somewhat different layout than within the desk tool. We have some different ideas on how to solve this and would like to know how feasible each of these are:
1.
Create new tools for editing each kind of document type. This has the advantage that the Sanity studio layout already lists the tools horizontally on top, and that we can customize each tool completely with the help of e.g.
@sanity/react-hooks
. The downside is we have to reimplement a lot of functionality ourselves (unless there is a way to e.g. import the edit document panel part of the desk tool, with state handling etc?)2.
Customize the desk tool. Probably involving the structure builder. Perhaps the leftmost pane can be styled to look like a top navigation menu instead? This might require hiding the default horizontal studio header (containing search, tools etc). If possible this is probably the most straightforward way?3.
Have several customized desk tools. If option 2 is not feasible, perhaps we could have separate desk tools for each document type, and then include them in the studio with different names. Not sure if this is possible, i.e. having copies of the same tool targeted separately via the parts system?So the question is which of these you think is possible or most convenient, or if there are other ways!
AI Update

Looking at your question about customizing Sanity Studio with a horizontal top navigation, I can provide guidance on each of your proposed approaches based on the current Sanity Studio v3 architecture.

Option 1: Create New Tools for Each Document Type

This is definitely feasible and aligns well with Studio v3's architecture. According to the custom Studio tool documentation, you can create custom tools that appear in the horizontal top navigation by default.

Advantages:

  • Full control over the UI and layout
  • Tools naturally appear horizontally in the Studio header
  • Clean separation of concerns

Challenges:

  • You'll need to implement document editing functionality yourself
  • Unfortunately, there isn't a simple way to import just the document editing panel from the desk tool as a reusable component. The desk tool's DocumentPane isn't exported as a standalone component you can easily reuse with all its state handling

However, you can leverage Studio's hooks like useDocumentOperation, useEditState, and form-building components from the Form Components API to build your own editing interfaces without starting completely from scratch.

Option 2: Customize the Desk Tool

This is possible but limited. The Structure Builder allows you to customize the left sidebar extensively, but:

  • The desk tool's panes are designed to work vertically (sidebar → list → document)
  • Styling the leftmost pane to look like a top navigation would require significant CSS overrides and might break responsive behavior
  • Hiding the default Studio header would remove important functionality (search, user menu, tool switcher)

This approach would likely be fighting against the framework's intended design patterns.

Option 3: Multiple Structure Tool Instances

This is absolutely possible and is likely your best solution! According to the Studio Tools documentation and the configuration API, you can include multiple instances of the structure tool with different configurations.

Here's how:

import {defineConfig} from 'sanity'
import {structureTool} from 'sanity/structure'
import {DocumentIcon, DocumentsIcon} from '@sanity/icons'

export default defineConfig({
  // ... other config
  plugins: [
    structureTool({
      name: 'posts-tool',
      title: 'Posts',
      icon: DocumentIcon,
      structure: (S) =>
        S.list()
          .title('Posts')
          .items([
            S.documentTypeListItem('post')
          ])
    }),
    structureTool({
      name: 'pages-tool',
      title: 'Pages',
      icon: DocumentsIcon,
      structure: (S) =>
        S.list()
          .title('Pages')
          .items([
            S.documentTypeListItem('page')
          ])
    }),
    // Add more as needed
  ],
})

Each tool instance will appear as a separate button in the horizontal top navigation, and you can customize what each one displays using the Structure Builder API.

Recommendation

Option 3 (Multiple Structure Tool Instances) is your best bet because:

  1. ✅ Achieves horizontal top navigation naturally
  2. ✅ Reuses all the desk tool's document editing functionality
  3. ✅ Requires minimal custom code
  4. ✅ Maintains Studio's responsive behavior and built-in features
  5. ✅ Each tool can have its own icon, title, and structure

You can combine this with custom Studio Components if you need to customize the navbar further, or hide specific UI elements using the studio configuration's components property.

If you need even more customization beyond what multiple structure tools provide, then Option 1 (custom tools) would be the next step, but you'd need to build more of the editing UI yourself using Studio's form components and hooks from the hooks API.

Show original thread
6 replies
Hey there! Before making a recommendation for how to proceed, I'm curious about your use case. What's the driving factor in wanting to have separate desks/tools for editing different document types?
Hello! 🙂 The point was mostly exploration of the possibilities for customizing layout in the studio. Since then, however, we’ve pretty much landed on using the desk tool with the structure builder.
We’re getting some inspiration from
sanity-super-pane , and in that context I have a couple of questions:
1. In order to use custom components in list-like panes they use what to my eyes looks like a
small (clever) hack . Do you think there is much chance of updates to the Sanity source that would render this method untenable?2. Is there a way of hiding panes completely, while still having them as a part of the structure builder under the hood?
Sorry it took me a bit to get back to you here! It's really unlikely that there would be any breaking changes made that make that method not work. As to hiding the panes, it's probably going to be quite a pain as there aren't any convenience methods for it. You would probably have to hack together some CSS global overrides .
No problem, thanks for the answer! I wonder if the global CSS override link is not right; is this the section you were thinking of or is there something else more appropriate?
Yep, looks like the wrong link was in my clipboard! Apologies! That is the correct link!
No worries, thank you!

Sanity – Build the way you think, not the way your CMS thinks

Sanity is the developer-first content operating system that gives you complete control. Schema-as-code, GROQ queries, and real-time APIs mean no more workarounds or waiting for deployments. Free to start, scale as you grow.

Was this answer helpful?