MaggieAppleton / arbour

A growing place
MIT License
8 stars 1 forks source link

We have some way to define post types and expected properties #11

Open MaggieAppleton opened 10 months ago

MaggieAppleton commented 10 months ago

Somewhere in the repo there's a place we can declare and edit all the post types and their properties.

Draft schemas (may change - good assumed starting point)

Post (Generic type that covers what I call both "notes" and "essays" – only diff is length and done-ness. This is the base type for more specific post types)

Book

Micropost

Question

Belief/Claim/Zettle

Maybe these are implicit as part of the folder structure and metadata within files or maybe it's explicit somewhere like types.json?


Assuming we should keep these super simple, but in theory (technically savvy) users should be able to build other custom types with unique properties in the system, such as:

DaveCoded commented 10 months ago

This might not be possible (or just prohibitively difficult) with the current plan to use 11ty. If we have these types with defined properties, I'm not sure how to enforce them. It could be done at build time in two ways. If you make a mistake with the properties for a type, either the site doesn't build and you get an error, or it builds with a warning that additional/missing properties were skipped.

The ideal experience would be to have feedback in your editor while authoring a markdown file. If you have a file in a certain directory (e.g. notes), or add type: "note" to the frontmatter, the editor can show errors until you have all required properties in the frontmatter, etc. Think you get this for free with "collections" in Astro.

I'll have a think, but we may need to decide how important having a strict, explicitly defined schema is versus a more implicit one, where the definition lives in the template used to display a type.

MaggieAppleton commented 10 months ago

Oh okay, I wasn't too worried by enforcing them. Although I agree it would be a pretty crappy user experience to make a basic mistake in a markdown file and then get a build error. Then have to go hunting for where the mistake is. That would be great to have feedback in your editor, or some other way to help users debug / catch simple errors in their markdown files.

I think it would be okay for it to be implicit. I don't think it's super important to have it strict and enforced (as long as we build in good error messages). Part of the solution could also be giving users template files when they make a new post so they're not writing markdown properties by hand.

But I may be anchored to 11ty as being an easy solution to a lot of other problems and don't want to throw it out over this.