-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Data collections and collection references #3233
Conversation
✅ Deploy Preview for astro-docs-2 ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @bholmesdev, amazing work on data collections! Added a few initial suggestions for you 🙌
Co-authored-by: Yan Thomas <[email protected]>
Co-authored-by: Yan Thomas <[email protected]>
Co-authored-by: Yan Thomas <[email protected]>
Co-authored-by: Yan Thomas <[email protected]>
Co-authored-by: Yan Thomas <[email protected]>
Co-authored-by: Sarah Rainsberger <[email protected]>
Co-authored-by: Sarah Rainsberger <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yay Ben! Left some more thoughts on the earlier part of this. Really liking it!
I'm tagging out for the night, and I've commented on the entire thing here, so some stuff for you to consider, and think about whether it's helpful!
|
||
A **content entry** is any piece of content stored inside of your content collection directory. Content entries are stored as either Markdown (`.md`) or MDX (`.mdx`) files. You can use any filename you want, but we recommend using a consistent naming scheme (lower-case, dashes instead of spaces) to make it easier to find and organize your content. | ||
A **collection entry** is any piece of content stored inside of your content collection directory. Entries can use content authoring formats including Markdown (`.md`) and MDX (`.mdx`) or as data formats including YAML (`.yaml`) and JSON (`.json`). You can use any filename you want, but we recommend using a consistent naming scheme (lower-case, dashes instead of spaces) to make it easier to find and organize your content. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A **collection entry** is any piece of content stored inside of your content collection directory. Entries can use content authoring formats including Markdown (`.md`) and MDX (`.mdx`) or as data formats including YAML (`.yaml`) and JSON (`.json`). You can use any filename you want, but we recommend using a consistent naming scheme (lower-case, dashes instead of spaces) to make it easier to find and organize your content. | |
A **collection entry** is any piece of content stored inside of your content collection directory. Entries can use content authoring formats including Markdown (`.md`) and MDX (`.mdx`) or as data formats including YAML (`.yaml`) and JSON (`.json`). You can use any filename you want, or begin your filename with an underscore to [exclude pages from the build](/en/core-concepts/routing/#excluding-pages). We recommend using a consistent naming scheme (lower-case, dashes instead of spaces) to make it easier to find and organize your content, but this is not required. |
Just had an issue with someone over the underscore thing this morning, so I think this is a good place to qualify "you can use any filename you want"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point! I agree documenting the underscore pattern is useful, but this isn't quite right. Underscore files will still be included in the build if you're using them for, say, relative image paths or MDX component imports. They're just excluded from collection queries. Wondering if this is the best place to explain that given it's the intro?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, so rather than get into more detail here, what about dropping that you can name them whatever you want entirely:
A collection entry is any piece of content stored inside of your content collection directory. Entries can use content authoring formats including Markdown (
.md
) and MDX (.mdx
) or as data formats including YAML (.yaml
) and JSON (.json
). We recommend using a consistent naming scheme (lower-case, dashes instead of spaces) for your files to make it easier to find and organize your content, but this is not required.
2. Define each collection that you'd like to validate with a schema. | ||
3. Export a single `collections` object to register your collections. | ||
1. **Import the proper utilities** from `astro:content`. | ||
2. **Define each collection that you'd like to validate.** This includes a `type` specifying whether the collection contains content authoring formats like Markdown (`type: 'content'`) or data formats like JSON or YAML (`type: 'data'`). It also includes a `schema` that defines the shape of your frontmatter or entry data. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nicely done here, Ben!
Co-authored-by: Sarah Rainsberger <[email protected]>
Co-authored-by: Sarah Rainsberger <[email protected]>
Co-authored-by: Sarah Rainsberger <[email protected]>
@sarah11918 Re "Resolving References" section: I just divided with a heading to split up the examples, not for SEO. Though I do expect people to wonder "ah crap, I just queried. Now how do I get the data for these references?" Resolving references was my stab at a short title to capture that need. Happy to either remove the title or find a better name if you prefer! We can also merge the examples into one large code block, but this would lead to code comment overload imo 🤷 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is it, Ben! 🎉
Very tiny thoughts left for you to look at, and one or two nits. Thank you, this page is even more amazing now!
|
||
A **content entry** is any piece of content stored inside of your content collection directory. Content entries are stored as either Markdown (`.md`) or MDX (`.mdx`) files. You can use any filename you want, but we recommend using a consistent naming scheme (lower-case, dashes instead of spaces) to make it easier to find and organize your content. | ||
A **collection entry** is any piece of content stored inside of your content collection directory. Entries can use content authoring formats including Markdown (`.md`) and MDX (`.mdx`) or as data formats including YAML (`.yaml`) and JSON (`.json`). You can use any filename you want, but we recommend using a consistent naming scheme (lower-case, dashes instead of spaces) to make it easier to find and organize your content. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, so rather than get into more detail here, what about dropping that you can name them whatever you want entirely:
A collection entry is any piece of content stored inside of your content collection directory. Entries can use content authoring formats including Markdown (
.md
) and MDX (.mdx
) or as data formats including YAML (.yaml
) and JSON (.json
). We recommend using a consistent naming scheme (lower-case, dashes instead of spaces) for your files to make it easier to find and organize your content, but this is not required.
Co-authored-by: Sarah Rainsberger <[email protected]>
Co-authored-by: Sarah Rainsberger <[email protected]>
…ro/docs into feat/data-collections-references
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is hereby my pleasure to approve this PR, @bholmesdev! 🥳
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is hereby my pleasure to find one more nit! But that's the last one, get my approval as well 🙌
What kind of changes does this PR include?
Description
Document the new "data collection" and "collection reference" features. See the RFC for the original feature proposal: withastro/roadmap#569
type
field to alldefineCollection()
examples. Yes,type
will default to'content'
to make this change non-breaking for existing content collections. Though to keep these docs future-proof (in casetype
becomes a required field),type
has been added for both content and data collections. Open to adding the line "type
defaults to'content'
but you can specify manually" if we prefer!getEntryBySlug()
recommendations to usegetEntry()
. This allows you to query content and data collections, without needing to explain howgetEntryBySlug()
is for content collections only.getEntryBySlug()
is still around in the API reference, with a note to use the newgetEntry()
function for ease-of-use.getEntry()
getEntries()
defineCollection() -> type
reference()