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. |
yanthomasdev
left a comment
There was a problem hiding this comment.
Thanks @bholmesdev, amazing work on data collections! Added a few initial suggestions for you 🙌
Co-authored-by: Yan Thomas <61414485+Yan-Thomas@users.noreply.github.com>
Co-authored-by: Yan Thomas <61414485+Yan-Thomas@users.noreply.github.com>
Co-authored-by: Yan Thomas <61414485+Yan-Thomas@users.noreply.github.com>
Co-authored-by: Yan Thomas <61414485+Yan-Thomas@users.noreply.github.com>
Co-authored-by: Yan Thomas <61414485+Yan-Thomas@users.noreply.github.com>
Co-authored-by: Sarah Rainsberger <sarah@rainsberger.ca>
Co-authored-by: Sarah Rainsberger <sarah@rainsberger.ca>
sarah11918
left a comment
There was a problem hiding this comment.
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 collection** is any directory inside the reserved `src/content` project directory, such as `src/content/newsletter` and `src/content/authors`. Only content collections are allowed inside the `src/content` directory. This directory cannot be used for anything else. | ||
|
|
||
| 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.
| 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.
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.
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. |
Co-authored-by: Sarah Rainsberger <sarah@rainsberger.ca>
Co-authored-by: Sarah Rainsberger <sarah@rainsberger.ca>
Co-authored-by: Sarah Rainsberger <sarah@rainsberger.ca>
|
@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 🤷 |
sarah11918
left a comment
There was a problem hiding this comment.
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 collection** is any directory inside the reserved `src/content` project directory, such as `src/content/newsletter` and `src/content/authors`. Only content collections are allowed inside the `src/content` directory. This directory cannot be used for anything else. | ||
|
|
||
| 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.
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 <sarah@rainsberger.ca>
Co-authored-by: Sarah Rainsberger <sarah@rainsberger.ca>
…ro/docs into feat/data-collections-references
sarah11918
left a comment
There was a problem hiding this comment.
It is hereby my pleasure to approve this PR, @bholmesdev! 🥳
yanthomasdev
left a comment
There was a problem hiding this comment.
It is hereby my pleasure to find one more nit! But that's the last one, get my approval as well 🙌
Co-authored-by: Yan Thomas <61414485+Yan-Thomas@users.noreply.github.com>
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
typefield to alldefineCollection()examples. Yes,typewill default to'content'to make this change non-breaking for existing content collections. Though to keep these docs future-proof (in casetypebecomes a required field),typehas been added for both content and data collections. Open to adding the line "typedefaults 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() -> typereference()