Comments (8)
Maybe this would be a good chance to rethink the schema like this:
const section = {
index: {
title: 'Index title',
content() {
return require('./content/index.md');
},
layout() {
return require('./layouts/Index').default;
},
process() {
content(o) {
return marked(o.file.body);
},
// And other hooks as before
}
},
page: {
content() { // old path() + processPage combined
return require.context(...);
},
layout() {
return require('./layouts/Page').default;
},
process() { // Earlier processPage
content(o) {
return marked(o.file.body);
},
title(o) {...}
// And other hooks as before
}
},
// Same as earlier
redirects: {}
};
Even though more verbose, this would allow me to drop some special case handling from the code (no more custom pages since they become just index
pages) and would allow us to implement processing as described in the issue.
from antwar.
Maybe sections should be able to have sections too. That would be an additional field, sections
, and it would recurse using the same schema.
from antwar.
Even though more verbose, this would allow me to drop some special case handling from the code (no more custom pages since they become just index pages) and would allow us to implement processing as described in the issue.
Idk, the antwar config over at webpack.js.org already feels very noisy to me. The change in #124 would reduce that greatly, and was one of main the reasons I was thinking of moving to phenomic (where that is the built-in behavior).
Is there a reason we can't just have it default to processPage
if no other function is given? Also from within the process
callback, developers should be able to determine the page based off filename and treat it differently themselves if need be.
from antwar.
Is there a reason we can't just have it default to processPage if no other function is given? Also from within the process callback, developers should be able to determine the page based off filename and treat it differently themselves if need be.
I wonder if we should fold both index/page above into a single definition and handle it through a branch like that. Only layout
would need a branch. This would kill duplication and keep it simple. You also get the default behavior unless otherwise specified.
The same rules could apply recursively so that if you add more sections below the section, it applies the rules by default unless they have their own overrides.
Does this sound good?
from antwar.
Yeah that sounds like a good solution. There's a lot of duplication right now in our config but from the looks of it, 90% of it could be rolled up into a single, higher-level definition.
from antwar.
Ok, I'll give it a go then. Likely weekend work.
from antwar.
Here's the current specification I ended up with after thinking about it carefully:
module.exports = () => ({
template: {
title: 'Smoke test'
},
output: 'build',
layout: () => require('./layouts/Body').default,
paths: {
'/': {
title: 'Section test',
content: () => (
require.context(
'./loaders/page-loader!./pages',
true,
/^\.\/.*\.md$/
)
),
layouts: {
index: () => require('./layouts/Index').default,
page: () => require('./layouts/Page').default
},
redirects: {}
},
standalone: {
title: 'Standalone test',
content: () => require('./layouts/Standalone').default
}
}
});
I realized processPage
can disappear entirely if we push the problem to a custom loader. Doing this simplifies Antwar logic a lot as it has to do far less. I still have to finish the implementation and play around with the scheme a bit.
Going with a combination of a configuration and a loader seems like a good compromise as it gives you a lot of flexibility with the cost of having to write that loader per project.
from antwar.
I merged the feature to master
. Still docs etc. to do. I expect we'll work based on PRs from now on.
from antwar.
Related Issues (20)
- Cannot read property 'children' of undefined HOT 1
- Allow partial references to Markdown HOT 1
- Live examples? HOT 1
- ETIMEDOUT getting started HOT 2
- Site descriptions render unprocessed markdown HOT 3
- Site does not shrink to smaller screen sizes
- How to specify devtool for built JavaScript? HOT 2
- Reflect Content Structure in Routing Structure HOT 7
- Relative Links in Development vs. Production HOT 5
- Missing Title in Head
- Is there a roadmap about the antwar ? HOT 4
- Roadmap HOT 3
- Push redirects to a webpack plugin HOT 1
- React 16 HOT 2
- Antwar Interactive ID Resolving Bug HOT 1
- Use template-literal instead of EJS HOT 2
- Shared vendor bundle HOT 1
- Set title and description via rendered page
- Generated paths (js, and interactives) are not using the "publicPath" webpack config HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from antwar.