-
-
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
Check for title/slug field on config load. #1203
Conversation
Deploy preview for netlify-cms-www ready! Built with commit 4044766 |
Deploy preview for cms-demo ready! Built with commit 4044766 |
d0c907d
to
f054994
Compare
Sweet! Is the WIP label still accurate? |
@erquhart I haven't tested it much yet. Also, is this, in your opinion, too big of a change to the backend, or is it good to merge? |
It's mostly a refactor, just porting the identifier logic out to a selector, which makes sense, and improving the error message. I haven't given it a thorough review, but it seems merge ready to me. |
fec276b
to
09f4d73
Compare
This is going to need some more work before merge. |
@erquhart I think I've fixed all the issues, but it probably deserves a pretty thorough review before merge -- the logic gets changed up quite a bit, it's not just a copy/paste. |
Ready for review reminder 😆 |
Alright I've got it queued. |
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.
The logic looks solid, just a few notes to simplify the implementation.
src/reducers/collections.js
Outdated
} | ||
|
||
const validIdentifierFields = ["title", "path"]; | ||
export const selectIdentifier = (entryData) => { |
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.
fieldNames
would be more self documenting than entryData
, which I would expect to be a map of the actual entry data.
src/reducers/collections.js
Outdated
@@ -34,7 +34,8 @@ function validateCollection(configCollection) { | |||
files, |
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.
This validateCollection
function is just validating configuration - I'd say move it to Actions/config
with the rest of the config validation (all of which may be worth porting elsewhere in the future), which allows you to put the new selector in with the rest of the selectors under the [FOLDER]
key.
1eab638
to
1d08984
Compare
1d08984
to
bbae4b5
Compare
@@ -40,6 +43,38 @@ export function applyDefaults(config) { | |||
}); | |||
} | |||
|
|||
function validateCollection(collection) { |
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.
Not a new function, relocated from the collections reducer (because it validates configuration), with the exception of the last conditional.
src/actions/config.js
Outdated
if (!!folder && !selectIdentifier(collection)) { | ||
// Verify that folder-type collections have an identifier field for slug creation. | ||
throw new Error(`Collection "${name}" must have a field that is a valid entry identifier. Supported fields are ${IDENTIFIER_FIELDS.join(', ')}.`); | ||
} |
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.
This last conditional was added for this PR.
@tech4him1 mind reviewing with this latest commit? I think it's good to merge if it looks good to you. |
@erquhart We'll throw every time here, instead of just when the |
Yeah that makes sense - let's not backport this one if we can get away with 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.
LGTM - I have a couple nitpicks, but nothing important. Tested the functionality manually and it works as designed.
src/actions/config.js
Outdated
// Cannot set custom delimiter without explicit and proper frontmatter format declaration | ||
throw new Error(`Please set a proper frontmatter format for collection "${name}" to use a custom delimiter. Supported frontmatter formats are yaml-frontmatter, toml-frontmatter, and json-frontmatter.`); | ||
} | ||
if (!!folder && !selectIdentifier(collection)) { |
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 the !!
bool coercion here is necessary. Any value which would turn into false
due to the coercion would also be ignored due to the &&
which follows immediately after.
src/backends/backend.js
Outdated
return identifier; | ||
}; | ||
const identifier = entryData.get(selectIdentifier(collection)); | ||
if (identifier === undefined) { |
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.
if (identifier === undefined)
seems overly specific when if (identifier)
seems to express the same semantics (none of false
, null
, and 0
are valid identifier field names either). If we'd rather avoid falsiness semantics, a better solution would be to use the second arguments to Immutable's .get
and .find
to explicitly return false
when nothing is found.
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.
This was just copying existing code, but if we're going for 2.0 this should be fine.
This PR fixes #690 by verifying that folder-type collections have a valid title ("slug"-able) field at CMS load time, instead of when the user tries to save an entry. It also explains how to fix the error.