Coming out of #955 / #1212, one follow up item was that after the change to collapsing down the API directory into the page directory, instead of being its own top level directory
src/
pages/
api/
search.js
A question of mixed content came up as a discussion around that topic, which basically came down to, what if you actually wanted pages in that directory? Like for actual API documentation.
src/
pages/
api/
index.html
Details
So we could easily support this for static pages, e.g. markdown and HTML, just like we detect normal pages. But what happens if you actually wanted a server / pre-rendered page, like say for building up a table of contents, or auto generating docs, e.g.
// src/pages/api/index.js
import fs from 'fs/promises';
export default class ApiDocsPage extends HTMLElement {
connectedCallback() {
// could also come through the graph as constructor props
const pages = await fs.promises.readDir('./.').filter(file => file.split('.').pop() === 'md'));
this.innerHTML = `
<h1>Table of Contents</h1>
<nav>
<ol>
${
pages.map((page) => {
const name = page.replace('.md', '');
return `<li><a href="/${name}/">${name}</a></li>`;
}).join('')
}
</ol>
</nav>
`;
}
}
How would / could Greenwood specifically detect this case vs just any other API route? Basically, have Greenwood support all these use cases at once
src/
pages/
api/
search.js // classic API route
index.html // static page
docs.js // SSR page
Most naive approach could be to just have SSR pages in the API directory export a flag, which we already support?
https://www.greenwoodjs.io/docs/server-rendering/#prerender
export const prerender = true;
// or
export const ssr = true;
Summary
Coming out of #955 / #1212, one follow up item was that after the change to collapsing down the API directory into the page directory, instead of being its own top level directory
A question of mixed content came up as a discussion around that topic, which basically came down to, what if you actually wanted pages in that directory? Like for actual API documentation.
Details
So we could easily support this for static pages, e.g. markdown and HTML, just like we detect normal pages. But what happens if you actually wanted a server / pre-rendered page, like say for building up a table of contents, or auto generating docs, e.g.
How would / could Greenwood specifically detect this case vs just any other API route? Basically, have Greenwood support all these use cases at once
Most naive approach could be to just have SSR pages in the API directory
export
a flag, which we already support?