isTitle isn't documented
jamespohalloran opened this issue · comments
@jamespohalloran Any idea where we could put the doc? I don't know which part of the docs it would make sense for the document to go.
I know our reference docs aren't in the best state, but ideally, any configurable part of the API should, at minimum, live in our reference docs. Once it's happy-path, it could possibly live in the intro "content modeling" docs as well.
I know our reference docs aren't in the best state, but ideally, any configurable part of the API should, at minimum, live in our reference docs. Once it's happy-path, it could possibly live in the intro "content modeling" docs as well.
Which Section of the reference docs are you thinking? or should a new one be added? Content types seems like the closest one but it is not really a content type so it feels out of place there. Perhaps we need a new heading for schema related stuff?
I'd like to really lean on you guys to own the reference docs, but my 2 cents is that the hierarchy could be improved:
As is, it's
- [Reference](https://tina.io/docs/cli-overview/): which links to the CLI overview
- [Content Types](https://tina.io/docs/reference/types/)
- [string](https://tina.io/docs/reference/types/string/)
- // ...
- [".tina" folder](https://tina.io/docs/tina-folder/overview/)
- [@tinacms/cli](https://tina.io/docs/cli-overview/)
- [next-tinacms-cloudinary](https://tina.io/docs/media-cloudinary/)
- [@tinacms/toolkit](https://tina.io/docs/reference/toolkit/overview/)
- // ...
Jumping right into Content Types feels weird to me, without context.
What if it was:
- Reference
- [@tinacms/cli](https://tina.io/docs/cli-overview/)
- [".tina" folder](https://tina.io/docs/tina-folder/overview/)
- schema.tsx
- defineSchema
- collections
- fields
- required
- isTitle
- Content Types:
- [string](https://tina.io/docs/reference/types/string/)
- // ...
- Media
- Built-in, repo-based Media
- External providers:
- [next-tinacms-cloudinary](https://tina.io/docs/media-cloudinary/)
^ Each bullet point in that list doesn't need to be its own page necessarily (Some could be distinct headings within a shared doc)