Content as Data v2 #1286

thescientist13 · 2024-10-17T22:16:06Z

thescientist13
Oct 17, 2024
Maintainer

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.

<title>${globalThis.page.title}</title>

I suppose something more "traditional" might be something like handlebars, etc

<!-- handlebars / mustache -->
<title>{{globalThis.page.title}}</title>

<!-- I think SvelteKit does this -->
<title><% globalThis.page.title %></title>


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.
```js
import { getContentByRoute } from '@greenwood/cli/src/data/client.js';

export default class BlogPostsList extends HTMLElement {
  async connectedCallback() {
    const posts = (await getContentByRoute('/blog')).filter(
      (page) => page.label !== 'Index' && page.label !== 'Blog'
    );

    // ...
  }
}

customElements.define('x-posts-list', BlogPostsList);

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 fetch is 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 a fetch if the data was desired on the client side as well even with a production build.

<script type="application/json" id="__gwd-content-key-route-/blog/">
  /* JSON goes here */
</script>

<script type="application/json" id="__gwd-content-key-collection-nav">
  /* JSON goes here */
</script>

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

<!-- input -->
<html>
  <body>
    <span>${globalThis.collection.nav}</span>
  </body>
</html>

<!-- output -->
<html>
  <body>
    <span>[{"id":"blog-index","label":"Blog","title":"Blog","route":"/blog/","data":{"collection":"nav","order":2,"tocHeading":0,"tableOfContents":[]}},{"id":"index","label":"Home","title":"Home","route":"/","data":{"collection":"nav","order":1,"tocHeading":0,"tableOfContents":[]}},{"id":"toc","label":"Table of Contents","title":"Table of Contents","route":"/toc/","data":{"collection":"nav","order":3,"tocHeading":0,"tableOfContents":[]}}]</span>
  </body>
</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 graph to pages instead? 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.context directories have their names changed too,

outputDir -> outputDirUrl
scratchDir -> scratchDirUrl
bundled resources - e.g. optimizedFileName
etc

Standalone 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 activeContent flag and write their own plugin / resolvers / etc.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Content as Data v2 #1286

{{title}}

{{editor}}'s edit

{{editor}}'s edit

Replies: 0 comments

Select a reply

Content as Data v2 #1286

thescientist13 Oct 17, 2024 Maintainer

Overview

Carryovers

Active Frontmatter

"Noisy" Active Frontmatter

Naming (Graph)

Standalone Plugin

Replies: 0 comments

thescientist13
Oct 17, 2024
Maintainer