Closed jaredcwhite closed 3 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)
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.
@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.
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.
Update: I got it working with subfolder trees out of the gate. 😃 See #139
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.
I think we're good to go at this point. Closing.
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:
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.