Optional endpoint for content type

[jimafisk]

It would be useful to be able to define a Type that does not have an endpoint.

Scenario 1: You want a type called content/main_menu/ to hold link information for a navbar.

Scenario 2: You have a component with information that you want to be able to share across different pages but it needs to be flexible enough that it shouldn't be hard-coded into a template.

In either scenario you don't want a node / endpoint that visitors can go to directly, you just want to pull the data in from the allNodes prop and use it however you'd like. Users should be able to extend the site config file (plenti.json) to account for this, something like:

"types": {
  "main_menu": ":none"
},

Currently the only replacement pattern we account for is :filename, but should extend this to look for :none.

It would also be nice to be able to specify this when creating a new type by using a flag: plenti new type <type_name> --endpoint=false

[jimafisk]

In talking through this with @stephanieluz, the ideal workflow would be:

1. To remove the endpoint, simply delete the corresponding template for the data source (i.e. layout/content/<template_name>.svelte)
2. When creating a new type via the CLI, you can still pass the --endpoint flag, which will just omit creating a corresponding template file (e.g. plenti new type <your_type> --endpoint=false)
3. You will need to manually filter types without an endpoint out of the allNodes object if creating links:

<script>
  export let allNodes;
  import { makeTitle } from '../scripts/make_title.svelte';
</script>

{#each allNodes as node}
  {#if node.type != "your_type"}
    <a href="{node.path}">{makeTitle(node.filename)}</a>
  {/if]
{/each}

This would negate the need for a :none replacement pattern, although it's tempting because we could probably pass this value straight through and just check for it in the client router here. This new approach might require using fs in the router to check if import paths exist, which I was hoping to avoid. Maybe combine the two approaches?

[jimafisk]

Checking for a corresponding svelte template during the build in data_source.go works pretty well. That way we can still add the content source to the allNodesStr but omit it from the staticBuildStr which actually creates the HTML.

If you iterate over allNodes but don't remove types without an endpoint, it appears svelte is smart enough to remove links without a valid {node.path} on the client which is pretty neat. The fallback HTML will still show these though.

With this approach you don't need a :none replacement pattern and you don't need fs in the router 👍. The content will still have a {node.path} value, but it will 404 so it's your job to filter these objects out when trying to make links out of nodes. I assume most of the time you'll be wanting to filter for a specific type or two rather than only trying to filter out a type of two.

[jimafisk]

Ahh nope, I was wrong above:

If you iterate over allNodes but don't remove types without an endpoint, it appears svelte is smart enough to remove links without a valid {node.path} on the client which is pretty neat.

What was really happening is I was ending filepath.Walk prematurely before writing to the nodes.js file, which the client uses for the allNodes object. This was making any type without an endpoint unavailable to use.