search

ndimatteo / sanity-plugin-vercel-deploy

Custom plugin to trigger webhooks from your Sanity Studio.
MIT License
99 stars 20 forks source link

Question: Deployments/Publishing and should I enable Sanity `liveEdit` on all documents? #40

Closed ptimson closed 1 year ago

ptimson commented 1 year ago

This might be the wrong place for this but I would like to get your thoughts.

So I am setting up a Sanity-Vercel deployment for the first time and trying to work out the easiest way to interact with it.

Sanity obviously has the concept of draft and published documents. When we do a deploy NextJS in the getStaticProps will read the Published documents from Sanity API.

We can then create a webhook with Sanity to trigger the deploy on a publish. However, I feel like the current flow of the site I've built is do all your edits as draft and use Preview to see how the site is going to look. Then once happy publish your documents. The problem is this will kick off multiple builds.

Option 1: Don't use a Sanity webhook and use a plugin like this to do manually deploy once documents have been edited. However there is then a step of having to publish all the documents which seems pointless, so I feel like it would make more sense to disable the publish with liveEdit: true

Option 2: Create a Sanity webhook and point it to a function that checks if the current Vercel project is deploying and if it is cancel and start a fresh one. This means if you were to publish 5 documents you wouldn't get a queue of 5 builds.

Do you currently have to publish everything before deploying? Is there any benefit of publishing?

ndimatteo commented 1 year ago

Hey there @ptimson apologies for the delay! Great questions, happy to share some insights:

You are correct, that the typical workflow currently, is to (1) make edits without publishing (auto-saving as a draft as you go), then (2) preview those changes before publishing. And then finally, (3) deploying all published changes when ready.

I understand it feels like an extra step, but the main argument I can give for having drafts/publish states on documents is that your clients may have multiple content editors who may not know who is doing what at any given time. For example, you wouldn't want person A's changes to go live when person B triggers a deployment.

It creates a safeguard for content editors to work on stuff, without blocking others from deploying changes elsewhere in the dataset.

For that reason alone, I would not recommend ditching drafts and enabling liveEdit.

I hope that helps 🤘