Allow custom _id on new documents created in the studio

[heggemsnes]

Is your feature request related to a problem? Please describe.

In a couple projects I want some part of the content to be private (behind a login wall), but still be able to use the CDN etc for the rest of the content.

Since you can only get data from the root path with public dataset, using a path for specific documents to make them private seems like a great solution: https://www.sanity.io/docs/ids

You can specify the UUID when creating new documents via the API, but not through the studio.

Describe the solution you'd like

A way to add a path to newly created documents in the studio. This can be solved a couple ways but an example would be through the initial value system i.e:

import {uuid} from '@sanity/uuid'
export default {
  // ...
  initialValue: () => ({
    _id : 'movie.' + uuid()
  })
}

Describe alternatives you've considered

• Making a custom component that is just a form that creates the document through the "manual" api
• By URL some way: https://www.youtube.com/watch?v=Tn2lhSYtRrc
• Just through the front end

All of these are possible but feel like a lot of hassle for something that the Studio should be able to do anyways.

[fabien]

I'm running to this issue as well. Even though the initialValue function is actually called, and the _id has been assigned, any edits (even non-published) will remove the prefix of the the _id immediately. I guess it's because the url path doesn't include it in the first place, and in addition, it does not recognize and handle any non-draft prefix values.

In my case, I could have gotten away with setting liveEdit: true in order to not handle any draft versions at all, but unfortunately this does not have any effect either.

[fabien]

I've been looking into a solution. If you add the following in your Structure Builder, it works nicely:

import S from '@sanity/desk-tool/structure-builder';

import ComposeIcon from 'part:@sanity/base/compose-icon';

import { uuid } from '@sanity/uuid';

export default S.documentTypeListItem('user')
  .title('Users')
  .child(() => {
    return S.documentTypeList('user').menuItems([
      S.menuItem()
        .title('Create')
        .icon(ComposeIcon)
        .intent({
          type: 'create',
          params: { type: 'user', id: `user.${uuid()}` },
        })
        .showAsAction(true),
      ...S.documentTypeList('user').getMenuItems(),
    ]);
  });

[alexandereneroth]

The new documentation calls for giving documents custom IDs to get around a performance issue.

https://www.sanity.io/docs/high-performance-groq#:~:text=Consider%20giving%20the%20related%20document%20a%20better%20ID

But is it even possible to do so from the studio in practice?

[fabien]

@alexandereneroth just finished reading that article in the docs. As far as I know, this is still not possible. Which is pretty unfortunate. Hoping that v3 will offer a solution.

[runeb]

Since 3.0.0 Sanity supports authenticated requests through the CDN, so I consider this issue resolved

[billinghamj]

@runeb I think you might have confused this with something else? The data lake supporting authenticated requests via the CDN has nothing to do with the Studio allowing custom _id fields

[theKashey]

Every time working with Stripe I am amazed how "type prefix" for every entity makes it simple - every ref self-explains what it is - payment method, intent, or charge element. GraphQL is also built on top of ARI pointing on their resolvers, and it's all about prefixing Ids with types.

We really need the same here and the problem is not yet solved.

[billinghamj]

@runeb could you please reopen this?