bridgetownrb / bridgetown

A next-generation progressive site generator & fullstack framework, powered by Ruby
https://www.bridgetownrb.com
MIT License
1.16k stars 112 forks source link

Simplify front matter defaults syntax #50

Closed jaredcwhite closed 3 years ago

jaredcwhite commented 4 years ago

Update: we ended up opting for a "data cascade" folder-based approach rather than changing the syntax of the defaults key in the config. See #139


I've always found the YAML syntax for defining front matter defaults to be extremely obtuse and I always have to look up a reference to remember how the heck to write it out. Really all I want to do is:

defaults:
  posts:
    layout: post
  pages:
    layout: page
  "some/path/to/stuff":
    category: stuff

Let's make this a whole lot better and then deprecate the old syntax with the goal of removing it for the 1.0 release.

Note: it should be a pretty straightforward swap because the old syntax is array-based, whereas the new one will be hash-based, so we can easily detect which syntax is being used.

jaredcwhite commented 4 years ago

We should do a full performance review of front matter defaults in general as part of this issue. Related issue in Jekyll: https://github.com/jekyll/jekyll/pull/8188 (it's unclear to me why lazily-loading defaults improves the build time so much…not something I would expect)

KonnorRogers commented 4 years ago

So heres the current syntax from bridgetown-website/bridgetown.config.yaml https://github.com/bridgetownrb/bridgetown/blob/8c0132909d3ca5cfe043df37865aeafb2fd96280/bridgetown-website/bridgetown.config.yml#L17-L34

The - scope: syntax is pretty gross I agree and I do like the idea of specifying the path as the key value.

I do like the idea of it being top level in the config rather than being nested into a _data folder.

However, I have also thought about the idea of the user defining defaults inside of a defaults.yaml file at the top level of a directory.

IE:

# ./src/_posts/defaults.yaml

layout: post
author: Jared White

Of course, I imagine the performance implications of reading multiple defaults.yaml is probably significantly worse than reading from a single source of truth.

jaredcwhite commented 4 years ago

@ParamagicDev I agree performance should be a concern, but since the number of defaults files would probably be fairly low for an entire site even with thousands of individual pages, I can't imagine it would be a huge hit over a single file. I really like your idea of a "data cascade" based on the filesystem itself — both Eleventy and Hugo have similar concepts, for example.

jaredcwhite commented 4 years ago

OK, I'm going to give the data cascade idea a try. For this initial version, I'm thinking it is only collection-scoped, so _collection_name/_defaults.yml. Next round of improvements would be to allow subfolder trees with their own unique defaults.

jaredcwhite commented 4 years ago

Update: I got it working with subfolder trees out of the gate. 😃 See #139

jaredcwhite commented 4 years ago

I'm keeping this issue open for a bit longer in case we have ideas for further improvements, but I think #139 will address most of the things people expect to do with front matter defaults.

jaredcwhite commented 3 years ago

I think we're good to go at this point. Closing.