Support Index Page Processing

[skipjack]

From webpack/webpack.js.org#1085:

We need someway to process index pages either via a separate processIndex function or allowing the index page to be processed with the main processPage function. For reference:

Also some way of including them with main section.all() data would be extremely useful.

[bebraw]

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.

[bebraw]

Maybe sections should be able to have sections too. That would be an additional field, sections, and it would recurse using the same schema.

[skipjack]

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.

[bebraw]

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?

[skipjack]

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.

[bebraw]

Ok, I'll give it a go then. Likely weekend work.

[bebraw]

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.

[bebraw]

I merged the feature to master. Still docs etc. to do. I expect we'll work based on PRs from now on.