Generalize getStaticPaths() into setup() for every page

[FredKSchott]

My for-fun thinking project for the weekend: Revisiting frontmatter scoping. I ultimately didn't get anywhere better than what we currently have (it turns out that the current component-scoped frontmatter is pretty dang useful!). However, I do have one suggestion for an improvement that I think will solve a few smaller issues for us.

Summary

Introduce a setup() function that any component can use to run expensive, one-time setup work.

Example - A place for expensive, one-time work

---
export function setup({setData}) {
    const allItems = /* some expensive data fetching */
    setData({allItems});
}
const {allItems} = Astro.data;
const { class: className = '', href } = Astro.props;
---
<!-- Not shown: component template -->

Example - replaces getStaticPaths()

// src/pages/[...slug].astro
export function setup({setData, setPaths}) {
    const allItems = /* some expensive data fetching */
    setPaths(allItems.map(...));
}

Example - adds rss() support to every page (not just getStaticPaths)

// src/pages/index.astro
export function setup({rss, setData, setPaths}) {
    const allItems = /* some expensive data fetching */
    rss(allItems, ...);
    setPaths(allItems.map(...));
}

Alternative - data

Instead of an explicit setData() function for data-passing outside of the setup() function, you could also create an implicit system where you just set the data onto Astro.data directly:

---
export function setup({setData}) {
    const allItems = /* some expensive data fetching */
    Astro.data = {allItems};
}
const {allItems} = Astro.data;
---
<!-- Not shown: component template -->

Note on fetch()

I believe that there is already buy-in for fetch() to respect cache headers similar to the browser. I bring this up because that means that fetch() wouldn't need to go into setup() - it could get called on every render and just return the cached value. setup() would only be needed for other kinds of expensive or one-time work, like a DB call.

This doesn't prevent us from exploring more one-off caching/memoization around a single variable in the frontmatter.

[tony-sull]

Example - replaces getStaticPaths()

I really like this direction! I've been working on a few ideas related to building pages that are fully managed in a CMS, ending up looking a lot like the building every page from src/pages/[...path].astro. The main challenge I've run into is how I'd handle something like a blog index page that needs getStaticPaths(), this setPaths example may make it dead simple 👍

Example - adds rss() support to every page (not just getStaticPaths)

Thoughts on also exposing the pagination helper here as well? I'm not sure exactly what that'd look like at the moment, but being able to use pagination to have src/pages/[...slug].astro build pages for /blog, /blog/1, and /blog/my-awesome-post would be a huge help if all data is pulled from a CMS (git-based or headless)

Note on fetch()

I really like the idea of automatically caching network requests based on cache headers, but I'm a little torn on building that directly into fetch(). I could see that causing a bit of confusion since that isn't how fetch() works normally, and since it's a bit of magic sprinkled in to cache responses the caveat that it can't cache things like a DB call might actually feel like a bug at first

This might be more confusing than helpful, but could we somehow make an API that mimics a ServiceWorker since that's really what this would be doing? It would end up being opt-in, which might make it more clear why fetch calls were cached but local data processing wasn't

[tony-sull]

Some of these notes aren't as relevant, I was thinking Astro.data would be global (available to all routes). If it's available only to routes in the same scope (i.e. in the same src/pages file), that simplifies a few use cases

[tony-sull]

11ty has a newer (I think) API, eleventyConfig.addGlobalData can be used to add global data from a synchronous or async JS function

https://www.11ty.dev/docs/data-global-custom/

[ghost]

It goes further than that even! 11ty's greatest strength is easily its data cascade. For instance, you can define data fetchers to:

• supply data to every page globally, either by adding JS files to a _data directory or using addGlobalData
• supply data to a directory of pages (i.e. I need this data available to all posts inside /pages/blog)
• supply data to a particular route (the same way Astro works today)

See Ben Myers' post for a clearer picture 🚀

I'd love to see Astro adopt this model, especially throwing whatever global data you want inside a _data directory. I could see this data being exposed either on Astro.props or as a param inside setup()

[jonathantneal]

I can dig that, @Holben888. 👍 Nit: I’d love to see experiments that embrace import.meta a bit more.

[tony-sull]

I’d love to see experiments that embrace import.meta a bit more.

@jonathantneal I've been playing around with that a bit actually! View on StackBlitz

I repurposed a svelte-entity-store library I made for normalizing state in Svelte stores so it's a little more complicated than it may need to be, but it's basically

1. using import.meta to load the markdown posts
2. normalizing files into an easier to search state, and
3. caching/memoizing it so the import.meta call is only ever made once

[FredKSchott]

To paint the other side of this, we hear a lot of good feedback about how our explicit data loading (ie: import someData from '../data/some.json) is much easier to reason about than 11ty's implicit flow (ie: magic _data folder). 11ty's approach is definitely powerful, but it is also hard to reason about unless you know exactly what you're doing around data flow and how to reference that data.