Content as Data v2 #1286
Replies: 1 comment 2 replies
-
|
As we've discussed in discord, I've been looking at migrating from Astro to Greenwood since Astro has deprecated support for Lit element based components. One of the features of Astro that I currently use fairly heavily is its data type content collections. I use these to read in collections of yaml and json files, with each directly of files being instances of the same data structure. In Astro, the resulting data content collection thus ends up being a convenient hash/map from which I can access one or more instances in a variety of different elements. The collection is thus not mapping to a route/page, as each data collection is used in at at least two different lit elements, each of which occurs (sometimes more than once) on at least two different pages. One of these I use to draw an element that contains a variety of details about a fictional character's biography. It uses a child component that displays a formatted name 3 or 4 times. A different page in the same project uses the same content collection to display information about the family (as opposed to the individual). In a different project, I have a content collection that is used by components in one route to display details of individual generals, matching on the [id] parameter in the route. In another place, a static page has a table component in it that pulls in details from the same content collection of generals to allow for side by side comparison within the table. As you can see the data content collections are, as you aptly summarized in discord, generics that allow me to avoid writing custom importers similar to that for each individual data collection. Such a custom importer would have several downsides:
Of these the second and third are obviously more important. |
Beta Was this translation helpful? Give feedback.
-
|
even with in dev mode. I was hoping to use that as a temporary work around for this feature. I was envisioning the globSync working because as I understand it, data-gwd-opt="static" should cause it to run once at build time, so being synchronous should slow the build down, but otherwise be acceptable. In other words, I don't think changing to fs.glob would effect the inability to import files with a known schema (I validate each file against a zod schema for data safety) but unknown filenames from a known/trusted location for use as input towards pages. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for capturing this convo. It does seem like a nice compliment to the existing content as data capabilities and might not be too hard to implement if it's just a matter of reading a bunch of arbitrary files in a directory and just extracting their frontmatter and returning that. So let me make a note of this and see where it could make sense on the 1.0 Roadmap. As far an interim workaround, it would probably have to be done purely through an SSR page I imagine. I think API routes might also be available at build time, so perhaps a component can call an API route and then combined with For example something like this, where in an SSR page we just pass the data as attributes to a component, that it can "pick up" in the browser. import fs from 'node:fs/promisis';
export default class Home extends HTMLElement {
async connectedCallback() {
const generals = await fs.glob('./path/to/content/*.yaml)
.map((general) => /* extract frontmatter, etc */ );
this.innerHTML = `
<generals-viewer
generals="${JSON.stringify(generals).replace(/"/g, '"')}"
></generals-viewer>
`;
}
}Or you could maybe it do it from a layout, e.g. src/layouts/app.js and just dump a bunch of JSON data on to the page that any client side components can read. (either using a component or export default class AppLayout extends HTMLElement {
async connectedCallback() {
const generals = await fs.glob('./path/to/content/*.yaml)
.map((general) => /* extract frontmatter, etc */ );
this.innerHTML = `
<head>
<script type="application/json" id="generals-data">
${JSON.stringify(generals)}
</script>
</head>
`;
}
} |
Beta Was this translation helpful? Give feedback.
-
Overview
Coming out of #1167 / #1266, wanted to track a few thoughts / questions / outstanding items that I didn't have a good answer for at the time, and so wanted to carryover into a discussion for further refining / iteration.
Carryovers
Active Frontmatter
The current API for templating out frontmatter at build time is to use this convention of combining template literal syntax and
globalThis.I suppose something more "traditional" might be something like handlebars, etc
Maybe it doesn't matter since it's all implementation details, but the convention could literally be anything really, but it just has to be super unique. Not sure how others feel about this technical design or maybe it's just fine? 🤷♂️
Content ("Server") APIs
To support our content APIs, e.g.
Wondering if there is a better way to execute / expose this API? The main issue is that it has to rely on isomorphic APIs, and
fetchis just that kind of API, in particular for prerendering scenarios at build time, where we spin up an instance of the dev server with just the content as data plugin configured.One thought was that at least for production builds, we could each inline query into a
<script>tag into the HTML? This would avoid having to do afetchif the data was desired on the client side as well even with a production build.We would have to be able to trace queries to pages, so as not to bloat the HTML for every page with every query. (which I think is what prevents us from completing #349)
"Noisy" Active Frontmatter
In cases where you would say want to serialize a collection into HTML is a little "noisy" due to all the properties of the graph being part of the out, with a lot items in your collection could potentially add a lot of extra content to the HTML
We are already pruning a lot of it, but maybe we could strip out the attribute? That would be bad though if someone was trying to hydrate off of it on the client side.
Naming (Graph)
I wonder if there is a case to rename
graphtopagesinstead? A graph implies nodes, some sort of linking structure, etc which it is definitely not in its current state.While we're on naming, should our
compilation.contextdirectories have their names changed too,outputDir->outputDirUrlscratchDir->scratchDirUrloptimizedFileNameStandalone Plugin
Since I know we plan on moving Markdown to its own plugin, should this be standalone too? One consideration is that if user's don't like the "native" implementation, they could basically just never enable the
activeContentflag and write their own plugin / resolvers / etc.Beta Was this translation helpful? Give feedback.
All reactions