-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
Custom delimiters #1064
Custom delimiters #1064
Conversation
Deploy preview for netlify-cms-www ready! Built with commit 98b33c9 |
Deploy preview for cms-demo ready! Built with commit 98b33c9 |
Thanks @Swieckowski! Going to take a look at this soon. |
Good to hear @erquhart, hopefully I can do a PR on my other issue claim soon enough as well. |
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.
LGTM - thanks @Swieckowski!
I'll review ASAP. |
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.
Thanks @Swieckowski!
'yaml-frontmatter': FrontmatterYAML, | ||
'json-frontmatter': frontmatterJSON(customDelimiter), | ||
'toml-frontmatter': frontmatterTOML(customDelimiter), | ||
'yaml-frontmatter': frontmatterYAML(customDelimiter), |
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.
I do wonder if there is a better way to avoid the overhead that is incurred here. The benefit of the single objects that we had before was that there was only a single instance of each created for the entire CMS (7 total instances). Now, we're creating three new objects for each page, then, throwing them all away (unless one is used). That just seems a little wasteful to me.
To pass a custom parameter, we're obviously going to have to do more than one instance. I think the cleanest, most sustainable way would be to create only one instance per collection.
For now, I wonder if we could just wait to pass the customDelimiter
in until after formatByName
returns the function. I haven't thought this through that much, though.
@erquhart Do you think this could cause performance problems now, or would you like to merge this, and change it later? I haven't worked with JS enough to know how expensive this really is.
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.
I doubt any real performance penalty would happen here. I did have the same thoughts on improvements, but trying to prioritize timely merges over ideal code. This passed the "good enough" test for me, personally.
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.
So because I'm passing in customDelimiters here, you're saying that each object gets actually instantiated while before it did not? That totally escaped me, I can test out a few things and make this more optimized if you'd like.
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.
@Swieckowski The difference is that a new object gets created with each function call, instead of just reusing the same one. I think, like Shawn said, that it's probably not worth delaying the PR just to try to optimize the code. I don't really want to delay it just for that, and we can optimize later if necessary. Do you agree?
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.
Sure! I was just trying to make sure I was following your logic correctly.
src/formats/formats.js
Outdated
} | ||
|
||
// If a file already exists, infer the format from its file extension. | ||
const filePath = entry && entry.path; | ||
if (filePath) { | ||
const fileExtension = filePath.split('.').pop(); | ||
return formatByExtension(fileExtension); | ||
return formatByExtension(fileExtension, customDelimiter); |
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.
I don't think we need to pass customDelimiter
to formatByExtension()
when it doesn't use it. That can always be added later if needed.
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.
I just removed the unnecessary passing of customDelimiter to formatByExtension(), it was a remnant of a different train of thought. Sorry I didn't have it cleaned up before.
Are there any other steps I should take with this?
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.
Nope, thank you.
}[name]; | ||
} | ||
|
||
export function resolveFormat(collectionOrEntity, entry) { | ||
// Check for custom delimiter | ||
const customDelimiter = collectionOrEntity.get('frontmatter_delimiter'); |
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.
I think we need to throw if a frontmatter_delimiter
is set without an explicit format
being set. This might be better checked in the reducer config validation section (/src/reducers/collections.js
).
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.
@Swieckowski I think we discussed this before, was there something that I missed?
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.
Ah yes, I remember bringing that up myself but don't recall a specific response, sorry. Should I get on that asap?
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.
No problem! I'd like to have it in before merge -- if you're busy, I can do it.
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.
I can have it done by 2 or 3pm tomorrow if that's alright.
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.
Oh, no hurry at all, thank you!
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.
@tech4him1 I've been a bit swamped with job search stuff haha, but I hope my latest commits address what you were talking about. We now throw an error if someone has a frontmatter_delimiter set without setting their format or not setting it to the proper frontmatter formats.
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.
Also, since I've added tests and documentation, how do I add that to my contribution? The add contributor script is failing on me, perhaps because I've already run it once on my github username?
Eww resolving conflicts in GitHub's UI results in a merge commit 🤦♂️ . Anywho, feel free to merge when you're happy with this @tech4him1. Thanks again @Swieckowski! |
The explicit `yaml-frontmatter`, `toml-frontmatter`, and `json-frontmatter` formats above do not currently support custom delimiters. We use `---` for YAML, `+++` for TOML, and `{` `}` for JSON. If a file has frontmatter inside other delimiters it will be included as part of the body text. | ||
The explicit `yaml-frontmatter`, `toml-frontmatter`, and `json-frontmatter` formats support custom delimiters. We use `---` for YAML, `+++` for TOML, and `{` `}` for JSON by default, but you can configure a custom delimiter. | ||
You can configure a custom delimiter with `frontmatter_delimiter`, but it only applies if you have a frontmatter format specified. | ||
If a file has frontmatter inside other delimiters it will be included as part of the body text. |
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.
Thanks for including this change in the docs!
Could you format this like the other config options? Something like:
frontmatter_delimiter
: description here
I think you could also add the default delimiters (+++
etc) to the descriptions for the explicit frontmatter formats instead of putting them all together in the frontmatter_delimiter
description.
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.
@verythorough I took your comments into consideration, I hope the changes reflect the direction you were looking for.
…lify-cms into customDelimiters
…tmatter format being declared
src/reducers/collections.js
Outdated
@@ -38,6 +38,12 @@ function validateCollection(configCollection) { | |||
// Cannot infer format from extension. | |||
throw new Error(`Please set a format for collection "${ collectionName }". Supported formats are ${ supportedFormats.join(',') }`); | |||
} | |||
const frontmatterFormats = ['yaml-frontmatter','toml-frontmatter','json-frontmatter'] |
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.
I'd rather have this list imported from src/formats/formats.js
, like we did for the supportedFormats
one above. Just easier to keep it together.
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.
Fixed. I will think more carefully about where I place things from now, thanks for your patience.
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.
Oh no, not a problem at all. Sorry to bug you with little things.
@Swieckowski Looks like the rebase messed up the all contributors, you should be able to run it again and add tests and docs. |
@tech4him1 I think I've addressed all of your concerns except for the minor optimization. Which I could slightly ameliorate with a switch statement refactor instead of the object property approach currently used, but I don't think the derailment from the norm is worth the slight optimization (which wouldn't bring the performance back to the same level anyway). The community's been really helpful, and I think my next PR will benefit from all the input I've received. |
- Summary
This allows users to specify their own custom delimiters for frontmatter if they've specified a format type. Closes #980
- Test plan
I checked all the different types of format settings with unique delimiters. Not sure if I could have done more.
- Description for the changelog
- A picture of a cute animal (not mandatory but encouraged)