Create new document directly in reference selector

[evenwestvang]

Users need to be able to create the new document being referenced from within the document that is doing the referencing.

[iacopolea]

This would be a very nice feature to have, globally! In the meantime is it possible to achieve this with a custom plugin maybe?

[Yago]

Something I saw, which is not far from your request, is when you create an array of the type of your reference, it opens a modal with all the reference's fields, but will create the “reference” inside your current instance and not outside like wanted...

Standard reference

{
  title: 'Director',
  name: 'director',
  type: 'reference',
  to: [{ type: 'person' }],
},

result :

"director": {
    "_ref": "f09378e2-7622-48a6-9951-b28b763727b3",
    "_type": "person"
}

---

Hacky-dirty “create in place” reference

{
  title: 'Director',
  name: 'director',
  type: 'array',
  of: [{ type: 'person' }],
  validation: Rule => Rule.max(1),
},

result :

"director": [
    {
        "_key": "b38c402cad16",
        "_type": "person",
        "name": "Steven"
    }
]

Can we not have something close to the array's behaviour, but for an external reference creation ?

[kmcaloon]

Hey guys any updates on this? This would be SUPER helpful.

[muhajirdev]

Yeah. Any update on this?

[camjc]

It'd vastly improve content creator UX in my opinion. Is there a preliminary PR for this? I'd be happy to help out a little to get this prioritised and across the line.

[raveling]

+1 for this. Would really help differentiate Sanity from others.

[hlz]

+1 for this as well. It would be super helpful when building documents consisting of blocks/parts which are partially reused and partially new.

Right now it is a burden to create a nested document in such a way since you have to navigate in and out the document to create it's parts first. Imo Contentful has done a great job here in terms of content creating UX.

[AndreasJacobsen]

This thread is old but I would like to give my +1 for this.

When sites have many sub-pages it can be tiersome to have to go out of your document, create a new document, then go back and reference it in the original document. I asked an editor about this and the editor replied that this would make Sanity a no go for that person.

[fvieira]

I'm going to add another use case for this.

I'm building the CMS for a website where there's a page with articles on it. The client wants to be able to create articles for this page and decide on their order. I need the articles to be documents (so they can be referenced), and because the client wants to decide on the order, I need to have a document for the articles page with a field called articles which is an array of articles.

As things are now, whenever my client wants to add an article they will have to create the article document first, and then go to the article page and add it there, so two steps to do one action, and it's easy to forget to go to the article page after creating the article. If this feature was implemented he could just go to the article page and create the article from there and add it at the same time, so it would be quicker and more intuitive.

[fvieira]

If someone could give some pointers on how this could be implemented, maybe I or someone else could try to make a PR to add this.

[steinarhovland]

I have the same need for a project. Would love to see this supported in Sanity. Exactly the same situation as @fvieira. Need to be able to sort documents. I am using a one-of document containing an array of references to solve this. I would then like to hide the documentslist, and only expose the singleton to the user so that all the interaction happens there. If array of references acted the same as array of objects that would solve my need.

Can also see this coming in handy for adding new and reusing tags from inside an editor.

[fvieira]

Found a workaround while this isn't implemented. While we can't let the editor create documents from the array selector, what we can do is let him know he has to do that and give him a link to where he can do that. Like this:

// In imports
import { Link } from 'part:@sanity/base/router';

// In fields
{
  name: 'resourceFiles',
  title: 'Files',
  description: (
    <span>
      Files to be added here must be created first in the{' '}
      <Link href={'/desk/resources;resourceFile'}>Resource File list</Link>
    </span>
  ),
  type: 'array',
  of: [
    {
      name: 'resourceFile',
      type: 'reference',
      to: {
        type: 'resourceFile',
      }
    },
  ],
}

[fvieira]

UPDATE: there was an update that makes this comment obsolete, it is now possible to use React elements in the description without breaking the GraphQL schema generation.

---

I've found a problem with my suggestion above to use a React element in the description.

Apparently, the GraphQL schema generation uses these descriptions and requires them to be strings, so my solution breaks it. For lack of a better solution, the workaround I came up with was to use a environment variable during GraphlQL generation so that I can replace the description for strings, like this:

// In a constants.js file:
export const GRAPHQL_GENERATION = process.env.SANITY_STUDIO_GRAPHQL_GENERATION === 'true';

// In my schema file:
import { GRAPHQL_GENERATION } from '../constants';

{
  name: 'resourceFiles',
  title: 'Files',
  description: GRAPHQL_GENERATION ? (
    ''
  ) : (
    <span>
      Files to be added here must be created first in the{' '}
      <Link href={'/desk/resources;resourceFile'}>Resource File list</Link>
    </span>
  ),
  type: 'array',
  of: [
    {
      name: 'resourceFileReference',
      type: 'resourceFileReference',
    },
  ],
}

// When running graphql deploy
env SANITY_STUDIO_GRAPHQL_GENERATION=true npx sanity graphql deploy

[sepowitz]

I'm also a +1 on this. Seems like it would be a huge UX win, and something that other leading headless CMS's support out of the box (e.g. Contentful).

Sanity has a lot going for it (i.e. customization, schema based architecture, and "structured content", pricing model) but this is an absolute must, especially for some of the bigger publishers out there, as it becomes really difficult to manage large swaths of content as things grow within the current editing experience.

Are there any updates on this? Would love to help in any way!

[DhillonN]

Any Updates on this?

[peterlaxalt]

+1

[olegtsaplin]

+1

[kkarkos]

+1

[hlz]

I would love to help to improve the UX for this issue within Sanity wherever I can. Since everybody's time is limited I would like to ask someone from the core team to briefly chime in on this and provide some sort of guidance on how to approach this new feature. Maybe there has been already done some work on this internally?

[Grsmto]

I don't know if something changed but @fvieira solution worked for me without having to define the env variable.

[fvieira]

Yes, there was an update that made it possible to use React elements in the description without breaking the GraphQL schema generation, so the environment variable workaround is no longer needed.

[dylanjha]

@fvieira @Grsmto I'm a little lost -- how does the React / description / GraphQL schema generation relate to this issue "Create new document directly in reference selector"

I'm sure there is a connection, but just wondering what I'm missing there!

[hlz]

@fvieira posted a workaround that displays a link "Files to be added here must be created first in the Resource File list" so that it is clear to a user that there must be taken another action first.

While we can't let the editor create documents from the array selector, what we can do is let him know he has to do that and give him a link to where he can do that.

In this workaround there was an issue which required some sort of hack which has now been made obsolete by an update to Sanity.

Indeed this has not much to do with the core problem being not being able to create a document directly in the reference selector. But it could be a valid workaround for some.

[tlloydukdev]

+1 for this please, although I will try the workaround

[bradley]

Yes, there was an update that made it possible to use React elements in the description without breaking the GraphQL schema generation, so the environment variable workaround is no longer needed.

@fvieira Can you point the documentation of this? Im on the most recent sanity and using a React component for my descriptions like shown above causes (at least) errors in my console telling me:

Warning: Failed prop type: Invalid prop description of type object supplied to DefaultFormField, expected string.

[RonaldDijks]

The workaround makes for a not-so-nice UX. Referencing to a single document from another document seems like an elemental use-case. Would love to jump in on this issue if this is still something that is to be added to the studio! 👍

[Taelkir]

I found another issue entering this as a feature request that I noticed hadn't been linked from here: https://github.com/sanity-io/sanity/issues/1346.

[antitoxic]

If there's a way to create embedded objects in array what's the exact difficulty with doing the same for documents?

I guess it is the publishing process?

Is the opposite easier? Aka enable documents to reference objects in non-reference arrays from another singleton document

const projectCollection = {
  name: "projectCollection",
  title: "Project collection",
  type: "document",
  fields: [
    {
       name: "projects_embedded_list",
       title: "Projects which user can sort and create from right here",
       type: "array",
       of: [
          {
             name: "embedded_project",
             title: "Project embedded",
             type: "document",
             ...
]

And then another document referencing items from projects_embedded_list. Smth like:

{
  name: "highlighted_projects",
  title: "Highlighted",
  type: "array",
  validation: (Rule) => Rule.unique(),
  of: [
    {
        type: "reference",
         to: [{type: "projectCollection.projects_embedded_list"}],
     },
  ],
},

[dwainetrain]

Just ran into this wall today. Are there any updates on this? Would love to see this feature implemented, or see a successful workaround. 🖖

[hlz]

@evenwestvang Do you know if this enhancement is on the roadmap or that it is being worked on at the moment?

[RemusDutulescu]

Also interested in this.

[pawelngei]

Migrated from Contentful, interested in this feature as well :)

[olafghanizadeh]

This would be useful in my project as well.

[Ojay]

Yeah same here - +1

[dumle11]

Also would love to see this feature. Right now using the hacky way provded by Yago and it does the job:

[robschwitzer]

+1 here as well. TBH I just assumed it was already possible and spent the evening going in circles trying to implement it 🤪

[LeoArr]

+1

[dui-sellpy]

+1

[connordowson]

+1

[andreasbergqvist]

Sad to see that this feature isn't available. A must have I would say when picking a CMS. Any updates?

[econic]

Totally joining in on that: CRUD must be possible inline. (I know this from the Typo3 CMS back in 2008, didn't expect to miss that here 😬)

Additionally, we should be able to hide a document from the document list pane completely (i'd suggest hidden: true like with fields)

[pawelngei]

@econic the latter is doable when you define your own Desk Tool structure - https://www.sanity.io/guides/getting-started-with-structure-builder

[tkdave]

This is still the biggest missing feature in Sanity. Long overdue and very hard to justify/explain to clients. Let's please prioritize this.

[hlz]

Totally agree! Still not using Sanity for clients because of this.

[hlz]

It’s so frustrating. Please add this "simple" feature soon! I know that it is not that complicated. You can just open a new modal which contains the documents schema fields, save it and then select it via the reference field. Just do it! PLEASE! I’m in the middle of a project and I have to seriously think about switching to an other CMS … !!!

Sorry, but there is no justification for a reply like this. You cannot go shouting around what other people should do just because your project's deadline depends on it. If it's so simple why don't you try to implement this feature yourself. That's what open source is all about.

[pawelngei]

@hlz I agree with your stance on the tone, but I don't think we can "just implement it". I spoke with the Sanity devs on Slack asking directly if they would accept my PR on this (there are some functional PRs over 2 years old in this project), and their answer was that they're planning a major UI overhaul and will probably not accept anything before.

I think some more clarity on the roadmap and prioritized features would help us all.

[bichan17]

+1!

[leighgibbo]

+1 🙏

[surjithctly]

Surprised to see this issue is opened in 2018.

Is there any official reply / roadmap for this feature yet?

[Rhym]

+1