Giter VIP home page Giter VIP logo

Comments (8)

bebraw avatar bebraw commented on September 22, 2024

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.

bebraw avatar bebraw commented on September 22, 2024

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.

skipjack avatar skipjack commented on September 22, 2024

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.

bebraw avatar bebraw commented on September 22, 2024

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.

skipjack avatar skipjack commented on September 22, 2024

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.

bebraw avatar bebraw commented on September 22, 2024

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

from antwar.

bebraw avatar bebraw commented on September 22, 2024

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.

bebraw avatar bebraw commented on September 22, 2024

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)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.