-
-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support export default
objects for pages
#708
Comments
Yeah, this behavior is supported (although not documented, I should do it). So you can do: export default {
sectionTitle: "Lint rules",
layout: "lintRule.tsx",
toc: [],
content: function*(...) {
}
} |
Thanks @oscarotero, that sounds good. Is there any chance we could force this behavior? I'm glad to migrate to this object notation, but I'd like to enforce it so I don't find myself in the same spot 6 months from now. |
What do you mean with "force this behavior"? Here you can see the code implementing it: https://github.com/lumeland/lume/blob/main/core/loaders/module.ts#L24 |
I mean that I'd like a project to only allow using the object notation - ie. this is allowed: export default {
sectionTitle: "Lint rules",
layout: "lintRule.tsx",
toc: [],
content: function*(...) {
}
} but this results in an error: export const sectionTitle = "Lint rules";
export const layout = "lintRule.tsx";
export const toc = [];
export default function*(...) {
} This corresponds to the: const site = lume(
requirePageIsADefaultExport: true // open to bike shedding, effectively if it's specified throw an error if the default export is not an object containing all the configuration
...
); from the original comment (#708 (comment)). |
Ah, got it. I'm not sure this should be a Lume option, because it's responsibility of the loader, that doesn't have access to Lume config. Maybe a solution is to create a custom loader for tsx files using the code of the original loader with some modification. Solution 1The easier solution: Create your module loader and use the import map to load it. {
"imports": {
// ...
"lume/core/loader/module.ts": "./_plugins/module-loader.ts"
}
{ Solution 2Because only the // Modify the original loader code to export this function, that loads the content but without modifying it:
import { load } from "lume/core/loaders/module.ts";
// Now we create our custom data transformer:
function toData(mod: Record<string, unknown>): RawData {
for (const [name, value] of Object.entries(mod)) {
if (name !== "default") {
throw new Error("Only the default export is allowed");
}
if (isPlainObject(value)) {
return value as RawData;
}
return { content: value }
}
// And export the new loader:
export default async function load(path: string) {
const data = await load(path);
return toData(data);
} Then, we can change the Lume plugin to load modules, adding a new option to customize the loader. Finally, we can configure this new loader in the _config.ts file: import lume from "lume/mod.ts";
import moduleLoader from "./_plugins/module_loader.ts";
const site = lume({
// lume config
},
{ modules: { loader: moduleLoader } },
); What do you think? |
Enter your suggestions in details:
In
deno-docs
we have a good amount of pages both hand-written and generated ones.I often find myself confused because the data for a page is scattered among numerous
export
s:I'd like to request (and I'm happy to work on it) to force using object notation for a page. So the above would become:
It would be great if this could be forced in the
lume()
config like so:The text was updated successfully, but these errors were encountered: