feat(scully): add contentType to contentFolderPlugin route data

[cmgriffing]

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/scullyio/scully/blob/master/CONTRIBUTING.md#commit
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

PR Type

What kind of change does this PR introduce?

• Bugfix
• Feature
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Other... Please describe:

What is the current behavior?

contentType must be inferred from route in the route data when iterating routes in a page. Example: news and media(screenshots, videos, etc) types may both exist. On the news index page we would want to filter for only news posts.

Issue Number: N/A

What is the new behavior?

The new behavior adds a contentType field to the route data. This is extracted from the route.slug.folder.

Is there a better place to extract this value?

Is there a more preferred name for the property instead of contentType?

Does this PR introduce a breaking change?

• Yes
• No

Other information

[claassistantio]

All committers have signed the CLA.

[SanderElias]

@cmgriffing Can you elaborate your use case a bit?
Are you saying you want to be able to split out the different routes that all use contentFolder?
If so, I would propose doing that in the frontend using the ScullyRouteService, something like:

class MyComponent {
   private music$ = this.srs.available$.pipe(
    map(routes => routes.filter(route => route.route.startsWith('/music'))
   );
   private news$ = this.srs.available$.pipe(
    map(routes => routes.filter(route => route.route.startsWith('/news'))
   );
  ...
}

Or is this missing your point?

[cmgriffing]

In that case, the root /news page would be part of the results. You could just change it to /news/, but it seems inelegant. If thats the preferred filtering method thats fine. I just tend to like explicit over implicit.

A separate thought is that it might be useful to override at some point via the frontmatter, but still have an "idiomatic" prop for that filtering. (this is not that well thought out yet :) )

I'm happy to withdraw this, it just seemed seemed like such a small change so I skipped the Issue process to have code to help explain the idea better.

[SanderElias]

@cmgriffing Yes, that would be the preferred way of filtering. Also, you can already put whatever you want in the frontmatter stuff, and filter by that. That would even enable 'tag' sharing between different routes.
However, as nested content is now allowed, the way you determine the part is not working anymore.
I can, however, add something that will inject the 'base' part of the path as a data point. Is that something you would like?

[cmgriffing]

I think some kind of value would be useful.
In Gatsby the user would do something like this in their config:

{
      resolve: `gatsby-source-filesystem`,
      options: {
        path: `${__dirname}/src/posts`,
        name: 'post',
      },
},

That name would be available in a createNode hook as getNode(node.parent).sourceInstanceName. The verboseness of getting that value is down to how they are using GraphQL, but its still there for the dev if they need it. Dev in this case could be plugin/schematic author or end-user. The ability to get that value without inferring from the route is what I am looking for.

[SanderElias]

@cmgriffing I added the name option in #326, you can take a look there.
Going to close this. If the solution is not satisfactory, please open a new issue