Parameterized data loaders & pages

[mbostock]

What if we supported dynamic routes for data loaders, e.g. customer/@[login].csv.ts would match customer/@mbostock.csv, and would pass --login=mbostock as a command-line argument (parameter) to the data loader. This way you could use the same data loader to generate multiple files (though all files would need to be statically referenced in order to be built).

[mbostock]

This would also apply to data loaders requested from parameterized pages. For example you could have a route @[login]/index.md, and adjacent @[login]/profile.csv.ts; then --login=mbostock would get passed to the data loader if you access @mbostock/ and @[login]/index.md references FileAttachment("profile.csv.ts").

The challenge is that we’ll need some way to enumerate all the possible values of the [login] parameter… 🤔

[Fil]

I can see how we could generate it from all links found in the static pages (since it would be nice to test links anyway, per #363), but also how it could be in the config (as an array), or in front-matter, like:

--- 
login:
 - one
 - two
 - three
---

[tel]

I'm highly interested in this. As an example, I have some code that does (somewhat intensive) simulations in Rust. I'd love to be able to parameterize those simulations in the call to the data loader and have the data be cached.

Ideally, this means that I can write the data loader file (sim.parquet.rs) and pass it arguments. Each call to the loader ought to be cached so that my workflow only involves rerunning the simulation when I change either the sim.parquet.rs file or its parameters. That way I can iterate on data exploration much more rapidly than I could without the caching.

Without parameterized data loaders, I can achieve something similar by making many different *.parquet.rs files each calling the underlying simulation code with different parameters. I haven't tested this yet, but I imagine this will work poorly with the caching system as if I make a change to the underlying simulator (a common event) I would need to manually invalidate all of those data loader files so that they have a chance to be re-run with the new dependency.

I can also imagine solving this with a feature such as #145. That might be more flexible, though I haven't thought it through and it'd also be annoying to have to constantly write out the Cargo.toml preamble.

[Fil]

We could also require that the values be enumerated in the config file (for build, not for preview where it would be uncontrolled—leaving the developer free to explore).

[cedricr]

We could also require that the values be enumerated in the config file (for build, not for preview where it would be uncontrolled—leaving the developer free to explore

Sveltekit solves that by crawling + optional configuration when prerendering or a static target is requested :
https://kit.svelte.dev/docs/page-options#entries