Kitchen Sink v3?

[dwkns]

Is there; or will there be a version of the Kitchen Sink repo for v3?
https://github.com/sanity-io/sanity-template-kitchen-sink

It would be incredibly useful reference for understanding how to use the new features/approaches/API's etc. Especially before all the documentation is finished.

[kmelve]

Thanks for letting us know! I think we'll make something that approximates the Kitchen Sink, but probably using Next.js. Is there anything, in particular, you'd like to see @dwkns?

[dwkns]

@kmelve
Over the last few days I've been going over a big client v2 project and asking the question: how would I implement x,y,z in v3?
I've main been focusing on features that have changed or there is some ambiguity about how you should achieve them; and seeing if there are any new opportunities that emerge.

Note, I run a web dev firm. But as a developer I'm just above a junior dev level and it is from that perspective I'm approaching this, not as someone super experienced with dev or Sanity.

I appreciate that everyone learns in a different way, but for me I find it far simpler to understand a concept or approach if there is some working code (with comments) that I can pull apart, tweak or adapt to my own use case. In most cases seeing two examples, a Hello World and something a little more involved, really helps my understanding.

Examples in TypeScript would also be welcome as I suspect that many are at the beginning of their TypeScript journey. It's much easier to go from TypeScript → JS example than the other way around. Also Vite throws a number of errors now, that Webpack allowed you to get away with. For example I think I'm right in say that anything that returns JSX has to be in a separate .jsx/.tsx file.

Currently in v3 you are likely battling: JavaScript → TypeScript, Webpack → Vite, v2 API's → v3 API's. It's a lot to get your head around in one go and anything to simplify that path would be welcome.

The features that I've been working on replicating:

• Getting references to the current User, current Document or current Schema type in various parts of the Studio (Schema, Desk Structure, Custom components etc).
• Creating/overriding Document Actions — which may work differently dependent on Document Type, or current User.
• Creating Document Badges
• Singletons including removing them from newDocumentOptions
• Reordering Custom Document Actions, Badges or newDocumentOptions
• Adding a Custom Component.
• Shared custom styles across Custom Components.
• Conditionally adding plugins based on environment.

In many cases the changes are minor, but the documentation is (understandably for a preview release) a little patchy and with multiple moving parts can be a little tricky to work out.

Having a good practice reference for how to organise your Studio files is also pretty valuable. And obviously there is a lot in the Kitchen Sink that hasn't changed — ideally this would be ported over too.

Whether the Kitchen Sink Studio is part of a NextJS project or not I don't think is important. How you use your content is somewhat removed from the how it is organised and managed.