General feedback

[kmelve]

Any piece of feedback for the Developer Preview of Sanity Studio v3 that doesn't fit in the other threads? Put it here!

[fabien]

There's a use case I have been thinking about for a while, which seems to be far closer within reach now:

Having some Sanity-powered forms embedded into a sidebar of a site, shown only when an admin is logged in. Sure, it would go a bit against the pure headless nature of Sanity, but it would make some things much easier when content is shown in its context.

While Studio offers preview integration and side-by-side panes for this, I would be interested in showing individual documents without the full Studio UI and Structure navigation. Perhaps there can be some config options to the announced renderStudio call that would allow such an isolated view (documentId and hideStructure ?)

I have seen https://github.com/sanity-io/sanity/blob/next/packages/%40sanity/form-builder/docs/quickstart.md which is deprecated/legacy documentation that shows exactly what I would like to have available. This would be the lowest level approach. A bit more high level to deal with changes (and document creation for example) would certainly be welcome.

[AmmarGillani95]

Does something like this work?

https://www.youtube.com/watch?v=298mlqa1-Hk

Check it out at the 6 min mark.

[fabien]

It might, but right now the UI that is embedded is the full Studio setup (navbars, sidebar, panes, etc.). I would prefer the ability to create a single document form as a React component (or better yet, like renderStudio a function to call).

[ghost]

Great work on this release. I had trouble finding much information about integrating into an existing Next.js app. Are there any docs that cover this?

[AmmarGillani95]

This might help as well:

https://www.youtube.com/watch?v=298mlqa1-Hk

[kmelve]

We'll write a tutorial for it real soon!

[ghost]

@kmelve overall this works great. How do you all recommend handling the Studio routing in a Next.js app. Hard refreshes and deep links will 404 so you must make the request to the basePath. Also, Vercel unique preview deploy URLs are blocked by CORS settings and I haven't yet found a way to best handle.

[kmelve]

Make sure that you use an optional catch all route, so that all requests go to the Studio component.

For the CORS settings, you can add one with a wildcard. I believe Vercel gives you a scoped preview URL so you can add something like https://*-jason.vercel.app with credentials allowed. Or if you have a custom domain for the preview URLs, you can do https://*.your.tld.

[ghost]

Thx, made some updates and now works great 🙌🏻

[OllieJT]

Typescript suggestion

I'm migrating some schemas over to V3 and love the type safety, but am having issues correctly migrating document previews.

Here is what I have to do to avoid typescript errors:

import { formatRelative } from "date-fns";
import { SchemaTypeDefinition } from "sanity";

function selectTopic(topics: unknown[]) {
	const currentTopic = topics[topics.length - 1];

	if (currentTopic && typeof currentTopic === "object") {
		const title = "title" in currentTopic ? (currentTopic["title"] as string) : undefined;
		const category = "category" in currentTopic ? (currentTopic["category"] as string) : undefined;
		const twitchCategory = "twitchCategory" in currentTopic ? (currentTopic["twitchCategory"] as string) : undefined;
		return [title, category, twitchCategory].filter((x) => !!x).join(" · ");
	}

	return "No topic";
}

export const LivestreamDocumentSchema: SchemaTypeDefinition = {
	title: "Livestream",
	name: "livestream",
	type: "document",
	fields: [
		{
			title: "Started At",
			name: "timeStart",
			type: "datetime",
			initialValue: () => new Date().toISOString(),
			validation: (Rule) => Rule.required(),
		},
		{
			title: "Topics",
			name: "topics",
			type: "array",
			of: [{ type: "streamTopic" }],
			initialValue: [],

			validation: (Rule) => Rule.min(1),
		},
	],
	preview: {
		select: {
			topics: "topics",
			timeStart: "timeStart",
		},
		prepare({ topics, timeStart: rawTimeStart }) {
			const title = selectTopic(topics as []);

			const timeStart = typeof rawTimeStart === "string" || typeof rawTimeStart === "number" ? rawTimeStart || "" : "";
			const startAt = formatRelative(new Date(timeStart || ""), new Date());
			const subtitle = startAt.toLocaleUpperCase();

			return { title, subtitle };
		},
	},
};

What would make more sense to me is if I could pass a Generic to the prepare function like so:

export const LivestreamDocumentSchema: SchemaTypeDefinition = {
	
	// removed for brevity
	
	preview: {
		select: {
			topics: "topics",
			timeStart: "timeStart",
		},
		prepare<{ topics: [], timeStart:string }>({ topics, timeStart }) {
			const currentTopic = topics[topics.length - 1];
			const title = [title, category, twitchCategory].filter((x) => !!x).join(" · ");

			const startAt = formatRelative(new Date(timeStart || ""), new Date());
			const subtitle = startAt.toLocaleUpperCase();

			return { title, subtitle };
		},
	},
};

[mariuslundgard]

That's a great suggestion! Maybe we can use this generic to also get a better type definition for the preview component 🤔 Thanks!

[hdoro]

Tiny, tiny Typescript issue: field's type definition don't support validation returning multiple rules:

interface BaseDefinitionOptions {
   // ...
    validation?: (rule: Rule) => Rule

validation?: (rule: Rule) => (Rule | Rule[]) should do the trick :)

PS: should I report these somewhere else?

[dorelljames]

I don't know where to post this but I thought I'd let you guys know that with the latest dev build, we get TypeError: generateHelpUrl is not a function. This doesn't seem to happen on old version 2 or specifically version ^2.30.1-dev-preview.1013.'

[dorelljames]

Fixed in latest dev release v3.0.0-dev-preview.9

[dorelljames]

What could I be missing here? This is in a Next.js app setup and I can't see the Desk in studio running development mode next dev but it works when you start the same app in production mode: next build && next start. This is basically me trying to follow the setup at https://github.com/sanity-io/v3-embeddable-showcase

[legowhales]

Hey,

Nice work on the v3. Il really love the fact that you used Vite, it is going to make the dev experience so much faster!
I have a quick feedback on design choices around inputs.

First of all, I do not get why you added an other level of information for slugs: "Current slug". And at least, I hope this is going to be editable :-). French editors do not understand the word "slug", so this might not help their editing experience. Oh and we lost the "generate" button, or I missed it somewhere?

Secondly, why is there a level indentation (fieldset line) for single inputs like a block or array (or even the slug input)? I get it when we need to group multiple fields together, for readability. But for single elements, it might be overkill, don't you think?

Thank's again for all the work you are doing!

[dwkns]

100% this on on the indentation.
I'd like to control whether a single element, object or even group of fields has indentation line. And whether the group has a title or not.

[fabien]

The indentation and always visible title has been bugging me for quite a while. I created a workaround using a custom Field wrapper and some css trickery, but it would be great to have more options for display purposes.

[ghost]

So, because there are so many hours in a day, let me outsource some thoughts for expanding Sanity's capabilities. Hopefully, a kind-hearted developer who shares these visions will pick up these breadcrumbs and bring these features into existence. 🙏🤞

v3 Studio ideas:

1. An updated utility plugin for triggering Cloudflare Pages deployments
2. A single plugin that hooks into popular social media APIs for programmatic posting of content stored within Sanity (with post preview functionality)
3. A Cloudflare Analytics plugin for charting Cloudflare-collected metrics within the Studio
4. Expanding the Content Graph View plugin so that clicking on any item in the list of documents in the upper left opens a UI rendering, maybe a popup card, of the underlying schema for that document type. (Ideally, with optional functionality to see all schemas, including objects, rendered in maybe a card gallery view.)
5. PWA configuration of the Studio for editing as if in a mobile app

General Sanity platform ideas:

1. API CDN support for automatic conversion of images to AVIF if supported by browser

Those are the main things I can think of for now. If I come up with more, I'll let everyone know. Thanks!

[Rubeanie]

Not me trying to implement idea 5 into my v2 studio 🥲, I really hope that feature gets added. Preferably along with a way to add to the studio’s header for studio specific icons, webmanifest and ect.

[hdoro]

I've been working with V3 for 2.5 weeks now, I'm beyond excited for it! Tons of new architectural patterns and editorial improvements that were impossible before - thank you for the work on this 😄

Here's what I've gathered so far:

Feature requests

• Expose ReferenceInput
• Expose DocumentPreview card or similar
• Expose IntentLink or similar for linking to internal parts of the studio from components & descriptions

Bugs & oddities

I imagine you know about most of these and hence why it's a dev preview and not a production-ready version 🙃

• Doesn't yet work with React 18 (tested with dev-preview.9 and [email protected]) fixed
• Regression with PortableText Editor (PTE): showing dropdown even when styles array is empty (should assume normal and not expose that to users)
  • 
• PTE annotations aren't opening their forms/dialogs when added
• PTE annotations have conflicting popovers: the validation box hides the editing buttons
  • 
• PTE annotations - duplicated in the validation dropdown (see image above)
• Rules inside validation objects sometimes work, sometimes don't - I couldn't pinpoint the pattern
• Document validation seems to be cached. When you change the schema in dev you may find leftover validations from the previous version, even when refreshing the page. Opening the studio in a new tab fixes it.
• renderItem isn't working in ArrayInput, it's ignored (used in a custom component)
• Items w/ invalid types in arrays can't be deleted (see image below)
  • 
• Arrays of multiple types aren't picking up the icon of their types unless you manually add it
• Collapsible fields aren't a thing anymore, is this intentional?
• The "replace" flow in the reference input is broken: when I click it, the field gets emptied, but as soon as I try to select a new document the old value comes back into place, negating my action
• The array of references has no padding and you can't re-order or delete the items (or add before/after, the usual array affordances)
  • 
• On Safari, I'm getting Error: unable to find translog entry to align to whenever I open the document editor in dev environment. Works fine in production builds, though 🤔
• Field groups don't include their icons

Let me know if I should consolidate this elsewhere - glad to help however I can!

[selbekk]

Hi! Testing out the new v3 for the first time, and I'm loving it so far.

Here's a few things I'd love for you to consider moving forward:

Remove prettier config

The files generated with Sanity's CLI includes a customized Prettier setup. I suggest you skip that, and instead opt in to the default settings of Prettier. There is no reason for why you want to add these hightly subjective preferences to the boilerplate – just let people override them if they want.

Stop using yarn

NPM is the default tool for handling packages. Why not default to using that? Especially when I run the CLI bootstrapping script in a context of existing package-lock.json files etc – shouldn't it just use what's already there?

Make TypeScript the default

Right now, you have to opt-in of using TypeScript instead of opting out. This is contrary to what i.e. Remix does in their bootstrapping tool.

TypeScript has become the defacto standard for developing these days, and changing the default to "yes" would be a step in the right direction

Use React 18 by default

Is there any reason whatsoever to not use React 18 out of the box when things are bootstrapped?

––

Otherwise, I'd love a 1-to-1 migration guide for the most common packages.

[kmelve]

Thanks for the feedback!

Prettier config: Yeah, I agree. I'll forward this to the team.

Stop using yarn: I believe the CLI should give a prompt on what package manager you prefer (npm, yarn, pnpm, manual), with npm being the first choice.

Make TypeScript the default: Yes, TypeScript has become more popular, and it might be getting to the point it's more “de facto,” but I'm not sure we're there quite yet? We have a lot of new learners coming to the platform as well, so that would be something we would need to think more deeply about. E.g. Next.js and Svelte have not gone TypeScript default (yet).

Use React 18 by default: Yes, we're working on it!

1-to-1 migration guide What package are you thinking about?

[rexxars]

Stop using yarn

NPM is the default tool for handling packages. Why not default to using that? Especially when I run the CLI bootstrapping script in a context of existing package-lock.json files etc – shouldn't it just use what's already there?

Package manager preferences are not only highly subjective, but is often a team-based decision. Many people use yarn for its workspaces feature, pnpm has gained a lot of traction lately, and yes, many still prefer/use npm.

The CLI should already detect whether or not you are inside of a yarn or pnpm workspace, and also looks for lockfiles to determine the preferred one if not. It also checks whether or not the preferred package manager (based on the mentioned algorithm) is installed before suggesting to use it. In non-interactive environments, it will automatically pick the preferred choice.

[selbekk]

Make TypeScript the default: Yes, TypeScript has become more popular, and it might be getting to the point it's more “de facto,” but I'm not sure we're there quite yet? We have a lot of new learners coming to the platform as well, so that would be something we would need to think more deeply about. E.g. Next.js and Svelte have not gone TypeScript default (yet).

I think part of the responsibility we have as a community is to promote good choices. And defaulting to using TypeScript is one of those choices. If you're new, that's fine, you can still choose to omit types, but most people using your platform won't be novices - they'll be seasoned vets. My 2 cents, at least :)

1-to-1 migration guide What package are you thinking about?
Well, perhaps the most used packages, like code input, the preview pane etc. I don't know how many parts you had, and how much people used them, but I'd love to have a reference that basically answers "oh, you were using this? This is what you should do now."

Stop using yarn: I believe the CLI should give a prompt on what package manager you prefer (npm, yarn, pnpm, manual), with npm being the first choice.

I don't think I got that prompt :/

Package manager preferences are not only highly subjective, but is often a team-based decision. Many people use yarn for its workspaces feature, pnpm has gained a lot of traction lately, and yes, many still prefer/use npm.

Oh I totally agree. Yarn has its merits for sure. But since this choice is so subjective, it should default to the simplest choice - the one that ships with Node. IMHO.

The CLI should already detect whether or not you are inside of a yarn or pnpm workspace, and also looks for lockfiles to determine the preferred one if not. It also checks whether or not the preferred package manager (based on the mentioned algorithm) is installed before suggesting to use it. In non-interactive environments, it will automatically pick the preferred choice.

Oh, then I have a feature request - let the script check for a lock file a few levels up. We work in a monorepo, and ran the cli in the apps subfolder. Since it didn't find a lock-file in the apps folder, it just defaulted to running yarn, if I remember correctly.

---

Also, let me apologize for my somewhat aggressive tone in my previous message. I love Sanity and the work you do too much for choosing those kinds of words. 🤗

[Svish]

I guess this doesn't apply specifically to the v3 Studio, but not sure where else to add this feedback, so giving it a shot...

1. Third-Party Authentication

Was using the CLI to create a new project, and logged in via GitHub, which I often do in other services. Turned out I accidentally created a new Sanity account, because my my actual account uses email+password.

Would be great if you, like so many others, allowed me to add the alternative authentication methods to my existing account, so I can use either one.

2. 2FA

I've started using 1Password, and it makes it much easier for me to set up 2FA authentication on services via their built-in OTA-feature. So I've been going through important accounts and enabling it everywhere.

Came to Sanity, and seems you don't support any 2FA at all? Can't find anything about it under my Account Settings at least. An account with access to do so much, leak data, potential damage, and so on, it feels like Sanity should definitely have the option of enabling 2FA?

[kmelve]

1. That's good feedback. I'll forward that to the team

2. We don't support 2FA on the email/password account, so you'll need to use Google or GitHub to get that.

You can add your users to an organization and transfer the projects that way. I agree that it's a bit cumbersome, but it's doable if you need to.