Skip to content
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

Fields default to Blank String #1126

Merged
merged 11 commits into from
Mar 28, 2018
Merged

Fields default to Blank String #1126

merged 11 commits into from
Mar 28, 2018

Conversation

MichaelRomani
Copy link
Contributor

  • Summary
    Closes issue Fields default to null value #977
    Widget values default to blank string when value is null.

  • Test plan
    Values for title, image and body within redux store get set to '' when value is null (date currently being set to current date)

  • Description for the changelog
    Default values directly provided by each widget.

@verythorough
Copy link
Contributor

verythorough commented Feb 21, 2018

Deploy preview for cms-demo ready!

Built with commit e8945fb

https://deploy-preview-1126--cms-demo.netlify.com

@verythorough
Copy link
Contributor

verythorough commented Feb 21, 2018

Deploy preview for netlify-cms-www ready!

Built with commit e8945fb

https://deploy-preview-1126--netlify-cms-www.netlify.com

@erquhart
Copy link
Contributor

erquhart commented Feb 22, 2018

This approach works, but I'd like to see a less involved method for handling defaults since every widget will need to tackle this concern.

Right now, we're intentionally setting empty fields to null: https://github.com/netlify/netlify-cms/blob/b4b584682473924556a41cae10f64f085b0f432b/src/actions/entries.js#L261-L263

A null value represents "the intentional absence of any object value", while undefined represents a value that simply hasn't been set (spec). The latter is a more accurate description of fields that have no default value, so I propose we remove the default setting of null, allowing empty fields to return undefined instead.

In doing so, we gain the ability to use React's defaultProps to set empty values in widgets (they only work with undefined values).

Thoughts?

@MichaelRomani
Copy link
Contributor Author

Shawn, just to clarify, you'd like me to set a default for 'value' using defaultProps for each of the editor widgets that has 'value' within its propTypes object. Is this correct? Also, should I default each to an empty string including objects that might ultimately be set to a date / boolean?

@erquhart
Copy link
Contributor

erquhart commented Feb 23, 2018

Each value will either be a number, string, boolean, array, object, or an array/object containing these types. Dates, for example, are stringified by their widget on change. Most widgets will use an empty string, with the exception of the boolean, object, and list widget. Perhaps there are others, those are the only ones that come to mind at the moment.

I'd expect Boolean to default to false, object to an empty object, and array to an empty array. But again, that's just off the top of my head without testing.

@MichaelRomani
Copy link
Contributor Author

Thanks, I will make the adjustments and submit early this week!
-Mike

@MichaelRomani
Copy link
Contributor Author

I've updated the PR to include 'defaultProps' for values located within the editor widget files. I did not set the default for the date/time as the current set up will only set the current date / time if value is not equal to an empty string. I also updated the createEmptyDraft function to set all values as undefined in place of null.

@@ -259,7 +259,7 @@ export function createEmptyDraft(collection) {
return (dispatch) => {
const dataFields = {};
collection.get('fields', List()).forEach((field) => {
dataFields[field.get('name')] = field.get('default', null);
dataFields[field.get('name')] = undefined;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@MichaelRomani We still want to allow users to manually set a default here, just default it to undefined instead of null. The code would be field.get('default'), just removing null as the second param like @erquhart mentioned.

@MichaelRomani
Copy link
Contributor Author

@tech4him1 - I've made the adjustment, setting it equal to - field.get('default').

@erquhart
Copy link
Contributor

erquhart commented Feb 27, 2018

Getting close!

The ultimate test is creating a new Kitchen Sink entry in the demo - currently failing: https://deploy-preview-1126--cms-demo.netlify.com/#/collections/kitchenSink

@@ -15,4 +15,8 @@ MarkdownPreview.propTypes = {
value: PropTypes.string,
};

MarkdownPreview.defaultProps = {
value: '',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason we need to set this on the MD preview, and not any of the other previews?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you referring to the 'RawEditor' and 'VisualEditor' files?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as the kitchen sink goes, I'll take a look this evening or tomorrow afternoon. My apologies, I did not test creating a new sink.

Copy link
Contributor

@tech4him1 tech4him1 Feb 27, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I just noticed that you set a default value on the MarkdownPreview as well as the MarkdownControl. Was there a reason?

@tech4him1
Copy link
Contributor

@MichaelRomani Maybe I missed it, but is there a reason a default isn't set for the ListControl?

@tech4him1
Copy link
Contributor

@erquhart Is changing the default from null to undefined going to be a breaking change?

@tech4him1 tech4him1 closed this Feb 27, 2018
@tech4him1 tech4him1 reopened this Feb 27, 2018
@erquhart
Copy link
Contributor

It would only be breaking for an installation if someone were intentionally checking for that null value in an external custom widget, in which case, the null value isn't a part of our published API, so it's not technically a breaking change. I also think the likelihood of real world problems resulting is very low, but I'm quite open to being told I'm wrong 😄.

@MichaelRomani
Copy link
Contributor Author

ListControl - A defaultProp for value was already set in this file as:
value: List()

MarkdownPreview - I removed the defaultProps that had been added to this file. I mistakenly thought it was receiving 'undefined' and needed to be set to ''.

Kitchen Sink Error -The error seems to have been coming from ObjectControl. I think the issue is that the defaultProp should have been set to a Map Object as:
Map().
Locally, Kitchen Sink is now working.

Let me know if this makes sense and I'll push these changes up to this PR for review.

@erquhart
Copy link
Contributor

Sounds good, push it up!

@tech4him1
Copy link
Contributor

@MichaelRomani Great, thanks!

@MichaelRomani
Copy link
Contributor Author

I've updated the PR. Let me know if changes are needed.

@erquhart
Copy link
Contributor

erquhart commented Mar 2, 2018

Any thoughts from anyone about the breaking change concern?

cc/ @tech4him1

@tech4him1
Copy link
Contributor

@erquhart On #1126, does the CMS internally treat null differently than undefined? Maybe by writing a key as empty vs not writing at all, or anything like that?

If not, I don't see a big concern with backwards compatibility.

@erquhart
Copy link
Contributor

erquhart commented Mar 2, 2018

Not that I'm aware of. If bugs emerge we should submit fixes with test coverage, but I haven't seen any issues.

Copy link
Contributor

@tech4him1 tech4him1 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should be documented at some point for widget authors, but the PR looks good to me!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants