Increase abstraction for content collections types

[rgov]

Content collections are currently limited to Markdown "content" files and YAML/JSON "data" files. I wonder if the restriction to these two types, and the distinction between them, is necessary. There may be benefits to a more generalized concept of content collections, enabling use cases such as:

• A collection of JPEG images whose data fields come from the EXIF metadata in the image file, and that render as <Image> tags.
• A collection of books whose entries are individual rows in a single CSV file.
• A collection of employee profiles that is generate on the fly from a directory service API response.

There already exists a way to configure a content collection using the defineCollection() function, which currently just accepts a type and a schema for validation. Extending this with a few additional configuration settings would grant more flexibility in creating the abovementioned kinds of content collections. These extensions might be something like:

1. A callback that enumerates the entries in the collection.

   The existing behavior looks at the filesystem hierarchy under src/content/<collection>/ and filters it based on file extension. This typical behavior could be provided as a helper function like findFilesInCollectionMatching("*.jpeg").

   This callback should return an array of { id: String, ... } objects corresponding to each entry. The objects can be opaque to Astro, they are just passed to the data loader:

2. A callback that generates the .data properties for a collection entry. The callback is invoked once per entry object generated by the enumeration function.

   For example, for filesystem-based enumeration like the default behavior, the passed entry object might be { ..., filePath: String }. The data loader would then open the file and parse its frontmatter.

   In the case of a collection of JPEG files, this could invoke an EXIF parser instead. For a single row in a CSV file, perhaps the passed object would be of the form { ..., filePath: String, line: Number }.

   (This could also return the slug, or the CollectionEntry.slug getter could just look for a .slug property within the entry's .data.)

3. A render() function that is copied to CollectionEntry instances. This would allow rendering files other than Markdown. For example, a collection of JPEG files could return <Image> components.

   Arguably though this is conflating the data model and presentation and there shouldn't be a render() function at all. You may want to have multiple ways of rendering the same collection entry. Why not explicitly write <MarkdownContent>{ collectionEntry.content }</MarkdownContent> rather than collectionEntry.render()?

[rgov]

The Content Layer is basically another approach to this. Posted two days prior!