There are plenty of Sanity projects in production already, but we still think there's work to be done. This is our short-term and long-term roadmap.
These features are in progress. Some nearly ready for testing.
Sometimes you don't want more than one object of a specific kind (Web Property Settings) - or you want to define exactly what objects a user can create (New York Office, London Office). Everyone runs across the need to do this sooner or later so we need to support it.
Part 2 of this feature is what we're internally calling Structure. At some point you will need to not just list documents by type, but rather make up a query for a listing. This way you could hook Sanity up to images submitted by users from an app and dump new ones in a Pending Review queue for editors. It's super effective!
You can persist your API queries and have changes in documents streamed to your clients. This is pretty great for editing, but we need to make some infrastructural changes so that this can scale to hundreds and thousands of open sockets.
Everything in Sanity has been made real-time from the bottom up. From the patch-based mutation stream that we store as document revisions in the database to the front-end components. There was however one last feature we had to chop off in order to make our deadline for release: real-time collaborative text editing. Everything is in place for this and it is something that we're pushing really hard on.
There’s so much great tooling and integrations available for GraphQL that we definitely need to support it. Sanity already has GROQ, a general purpose graph oriented query API, but we’re also adding a GraphQL API in addition to it. In fact, we’re building a translator going from GraphQL to GROQ. Watch this presentation to learn how we’re going about it.
All documents in Sanity have revision histories with attribution as to who made the change. Every patch that goes in gets stored. This is already in place. What's missing however is the APIs to get at the revision history of documents and display this history to the user.
It's annoying to have to create objects you want to reference beforehand. It demands planning and breaks your workflow. So you should be able to do this in-place, from the reference field itself.
As Sanity is real-time you should be able to see what other people are doing and deep link to the object inside an array that they are working on right now. The backend infrastructure for this is complete as is deep linking to nested fields within documents.
When designing Sanity Studio we made a system that allows build-time dependency injection,
Parts. This means you can compose the components we ship with or override them completely. The Studio has been built with parts from the ground up. What is still lacking though is documentation and API-stability. That said we already ship examples for adding custom display and editing for your own data types and tools that give you a canvas to design yourself.
Sometimes documents need to be ranked. And occasionally (though probably not as often as you might think) they need to be ordered in hierarchies. Now, you can already make lists by building an array of references to documents or embedding an order variable in a document. Hierarchies can be implemented with references between children and parent documents. But this isn't really good enough. We need a UI that makes this easy and intuitive for editors.
Sanity has rule-based document level access control in the data back-end. There's not a user interface for it yet though.
We allow you to store geographic points, but right now you need to use greater and less than operations to define bounding boxes. Unfortunately, the world is round and we should let you query box real bounding boxes and centroids.