Collections API: dev server #68
Conversation
Change of plans—maintain parity with Snowpack and Vite because our Collections API will use a different interface
| }, | ||
| perPage: 3 | ||
| }; | ||
| } |
There was a problem hiding this comment.
Proof of concept here: if you want to learn how to use this, look in the examples/blog folder
|
|
||
| const traverse: typeof babelTraverse.default = (babelTraverse.default as any).default; |
There was a problem hiding this comment.
🤷🏻 Babel why are you like this
| const ast = babelParser.parse(createCollection, { | ||
| sourceType: 'module', | ||
| }); | ||
| traverse(ast, { |
There was a problem hiding this comment.
This is a bit of cleanup for later, perhaps. Alongside our original __renderPage() transform, we‘re also doing one here for createCollection(). Reason is that this happens outside the script context, so we need to transform it separately. Overall not too bad as this will only happen once total per-page, but still something to revisit later.
drwpow
force-pushed
the
collections-api
branch
4 times, most recently
from
98c34f4
to
288aa15
Compare
| return { | ||
| statusCode: 301, | ||
| location: reqPath + '/1', | ||
| }; |
There was a problem hiding this comment.
Weird little bug: it‘s unexpected behavior when you set a pageSize: [num], but you try and load a non-paginated route. This attempts to redirect you to page 1, but it doesn‘t seem to be working in dev. Will have to investigate, but you basically only hit this if you‘re doing something confusing.
| // page | ||
| let title = 'Muppet Blog: Home'; | ||
| let description = 'An example blog on Astro'; | ||
|
|
||
| // collection | ||
| // note: we want to show first 3 posts here, but we don‘t want to paginate at /1, /2, /3, etc. |
There was a problem hiding this comment.
We could look into a config option in the createCollection API to customize pagination (at the very least, to choose whether page 1 is written to URL /posts/1 or /posts). Users most likely don't want duplicate /posts/index.html and /posts/1/index.html files written into their final build, and almost certainly don't want to maintain near-duplicate posts.astro and $posts.astro files to get it.
Happy to chat through this more though if I'm missing anything here
| } | ||
|
|
||
| /** import.meta.glob() */ | ||
| export function handleImportGlob(spec: string, { namespace, filename }: GlobOptions): GlobResult { |
There was a problem hiding this comment.
Since Astro is built on top of Snowpack, we shouldn't be overriding Snowpack's import.meta.glob support. Since that means something in Snowpack world, it would be confusing / hard to document if we overrode this to mean something else entirely in Astro.
Lets leave Snowpack's import.meta.glob and import.meta.globEager as-is, and just implement this as a single Astro API that lets an Astro component fetch content files locally (without resorting to fs). import.meta.fetchContent() for example.
There was a problem hiding this comment.
Maybe I am missing something, but when I use Snowpack‘s built-in import.meta.glob(), then it goes back through our Snowpack plugin, and I only get a __render() hook and none of the markup frontmatter, etc. Maybe you could show me how to load this properly tomorrow.
|
Superceded by #70 |
Changes
Gets collections API up and running.
Testing
Docs