Support multiple page types for query-posts plugin

[andreasvirkus]

Feature request

What problem does this feature solve?

Having multiple page collections, besides the standard _posts/ type, e.g. _jobs/ (to list all available job ads), _projects (for a portfolio maybe), etc.

What does the proposed API look like?

Maybe the user could add injectByType: 'slug' in the YAML frontmatter, where slug would have to match _<slug> in the directory name?

How should this be implemented in your opinion?

Within the saber-plugin-query-posts package, not yet sure of the technical implementation.

Are you willing to work on this yourself?

Yes. Would this feature be an OK addition? Is it maybe already solvable today somehow?

[issue-label-bot]

Issue-Label Bot is automatically applying the label feature_request to this issue, with a confidence of 0.92. Please mark this comment with 👍 or 👎 to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[krmax44]

I think this is a good idea. Maybe instead of only adding this feature, query-posts could be overhauled so that you can query pages in a more customisable way (the current implementation doesn't resemble that much of a query plugin, in my opinion, which would be awesome if it was).

[egoist]

I had thought about some kind of query syntax like this:

jobs.md

---
jobs:
   where: 
      - page.job === true
paginate:
   by: jobs
   segment: p
   perPage: 10
---

The front matter above makes Saber generate:

/jobs
/jobs/p/2
/jobs/p/3

And job posts are injected as page.jobs

[krmax44]

I don't know how I feel about doing querying in Markdown, since displaying the queried posts isn't usually done in the Markdown either. Maybe a layout-focused/Vue-page-focused API/query syntax would make sense.

[andreasvirkus]

@krmax44 do you mean something with a Vue plugin's syntax, so the user could call this.$queryPosts, e.g. 👇 ?

computed: {
  postsOfCurrentPage () {
    return this.$queryPosts(this.page)
  }
}

---

Edit: could this new proposed state API be utilised here somehow?
#553

[krmax44]

@andreasvirkus an API like that would be tricky to implement, as then pages would be fetched at runtime rather than at buildtime.

Maybe something like this would facilitate it:

export const data = {
  title: 'foo',
  queryPosts: { // Mongo-style querying
    where: {
      category: 'jobs'
    }
  }
}

or with a function:

export const data = {
  title: 'foo',
  queryPosts: (post) => post.title.startsWith('Job')
}

Would be awesome if this worked on layouts and pages.

The proposed state API could be used here, but I don't think it's necessary.

[andreasvirkus]

Good point about the runtime vs buildtime. In an .md file, would this then be:

where: 
  - category: 'jobs'

[krmax44]

Another possible API:

<template>
  <div>
    <h2>My posts</h2>
    <ul>
      <li v-for="page in $pages" :key="page.permalink">{{ page.title }}</li>
    </ul>
  </div>
</template>

<script>
// all posts created after 2019-01-01
export const data = {
  title: 'foo',
  queryPages: {
    // Mongo-style querying
    where: {
      type: 'post',
      createdAt: { $gt: new Date('2019-01-01') }
    },
    process(pages) {
      // only return title and permalink of posts (smaller bundle files)
      return pages.map(({ title, permalink }) => ({ title, permalink }));
    },
    // alternatively:
    process: ['permalink', 'title', 'attributes.createdAt']
  }
}
</script>

This could also be incorporated into #511.

[egoist]

Maybe it's finally the time to consider GraphQL? 😅

[krmax44]

Personally, I'd like to avoid GraphQL since it's intimidating to newcomers and usually adds a lot of overhead to simple projects. I can see the appeal due to its flexibility though, so if we can keep the overhead to a minimum (by making it optional when the defaults aren't enough) and explaining it really well in the docs so that anyone understands, it might work out.