-
Notifications
You must be signed in to change notification settings - Fork 10.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[gatsby-transformer-remark] support frontmatter default values plugin option #5495
Conversation
Deploy preview for gatsbygram ready! Built with commit 3ffbe16 |
Deploy preview for using-drupal ready! Built with commit 3ffbe16 |
This is nice simple solution to the problem. Would be great to see this merged. |
for(const key of defaultKeys) { | ||
data.data[key] = data.data[key] || frontmatterDefaults[key] | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about using lodash _.merge here? It would be less verbose and it would allow deep merge (which imo would be useful because current implementation just take care of first level frontmatter fields )
Two thoughts:
|
@Undistraction Good observations. Maybe this is something we could implement in gatsby core - possibly adding some actions that could be used in |
@pieh This does feel like it belongs in the core, but I'm guessing that will involve a lot more hoops to jump through. I don't want to derail this PR with complexity and I guess the validation idea has potential to introduce a lot of complexity. However I do think it needs to support different defaults for different markdown nodes, otherwise it is very restrictive and I think its utility will be limited. If it can support different nodes it becomes really useful, and pretty much solves the issue where no field is defined on any of the nodes causing GraphQL errors because the field isn't inferred. |
I think if you want default values, you're better off writing a plugin that adds fields with |
@KyleAMathews Quick outline of API - each entry is an array containing:
This approach allows all fields to have default values set and provides a single location for throwing useful validation errors when a required field is missing and a default value doesn't make sense.
|
Looks great! |
@KyleAMathews You OK with it in the gatsby repo or would you prefer it external? |
External — we're trying to keep this repo for essential plugins only. The plugin will show up in https://www.gatsbyjs.org/plugins/ as long as you add |
Yeah. It was only a matter of time before Gatsby popped its shirt buttons with all those plugins. Thanks. I'll get something up tomorrow. |
@KyleAMathews Am I right in thinking that hooks are called in the order that the plugins are defined in I'm thinking each entry needs a way to define the name of the field it will write to. That way this becomes even more powerful, because it would support transforms as well:
I also think that passing in
Or do you think this is taking it a step too far? The problem is that if the plugin is writing defaults (and can't write to the markdown directly), it has to write to node fields which are also immutable meaning that they cannot be updated later by other plugins or in the user's own |
@KyleAMathews I've created a plugin to handle creation of node fields, supporting default values, transformations and validation. I think it's pretty flexible. I'd really appreciate your feedback if you get a moment to take a look: https://github.com/Undistraction/gatsby-plugin-node-fields |
Nifty! Looks really powerful and useful. Only feedback is some examples would help people browsing through the README understand what it can do. |
This is for #5392. I'm quite not sure if it's okay to have this option defined at 2 levels deep frontmatter --> defaultValues, but this looks good to me.