Data collections #477
Closed
bholmesdev
started this conversation in
Proposal
Replies: 2 comments 2 replies
-
Love the direction here! Really like that it covers all of the use-cases. Couple of things:
|
Beta Was this translation helpful? Give feedback.
0 replies
-
Love this conceptually! A couple of comments:
|
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Update: this proposal has been moved to stage 2. Continue discussion here
Summary
This proposal adds support for "data collections," or content collections using simple data storage formats (namely JSON and YAML). This also introduces a pluggable API to support any data format in the future.
Background & Motivation
Content collections are restricted to supporting
.md
and.mdx
files. This is limiting for other forms of data you may need to store, namely raw data formats like JSON, YAML, and TOML. Common use cases include storing blog or documentation authors separate from the content of each post.The content collections API was built generically to support this future, choosing format-agnostic naming like
data
instead offrontmatter
andbody
instead ofrawContent
. Because of this, expanding support to new data formats without API changes is possible to achieve.Goals
src/data/
directory distinct fromsrc/content/
, or simply allow data collections withinsrc/content/
.Non-goals
Example
Using the built-in JSON format
Say you have a collection of blog post authors you would like to store as JSON. You can create a new collection under
src/content/
(orsrc/data/
, pending conversation) like so:This collection can be configured with a schema like any other content collection:
It can also be queried like any other collection, this example using
getCollection('authors')
:Each entry will have the same type signature as a content collection entry, with the
slug
property andrender()
function removed:Configuring and using a custom format
Say you want to store these authors as TOML instead. Assuming TOML were not built-in, you could configure the TOML collection type using the
addContentEntryType
integration hook:Now, you are free to use
.toml
files in your collections, even mixed alongside files of another type for smoother migration:Beta Was this translation helpful? Give feedback.
All reactions