Allow empty fields to be removed from frontmatter on update

[richblend]

Is your feature request related to a problem? Please describe.

When an optional field is left empty, it is not written to frontmatter at all when first published.
If an existing entry is updated, and a field that previously had a value is now empty, it is set as an empty string, instead of being removed completely.

I am seeing this behaviour on image fields. This is a problem for my build (using Gatsby JS), as when it infers its Graphql schema from the frontmatter data, it will incorrectly infer an image field as a string (since it detects the empty quotes), whereas I need it to be completely removed from frontmatter (in this case Graphql will not try to infer its schema from that particular entry).

Describe the solution you'd like

There is at least one existing issue requesting the opposite (#1988 - where updating empty values should default to empty string), so I think this could be an opt-in feature.

I'd like to be able to add an attribute to a widget field config, something like deleteWhenEmpty: true, that would completely strip out the frontmatter field if it is empty when published.

Describe alternatives you've considered

I have tried to deal with this on the Gatsby side, to remove nodes from Graphql that use empty quotes, but haven't had any luck so far.

Additional context

[lmcorreia]

I think it would be better if we could infer this from require: false, no? If the field is not required and is empty when persisting, get rid of it. From the top of my mind, no SSG would complain about it.

Although, there's some potential to break stuff for people relying on the existence of fields in frontmatter because in the templates they're evaluating against empty strings and not just falsy values (I remember having to do such things in Harp, hence the concern).

[erquhart]

Inferring from require makes a lot of sense. We can implement now with an opt-in flag and then make it default behavior in the next major release.

[lmcorreia]

@erquhart Besides this thing that I found reported on #2067, I also found that if input fields are left untouched (at least) when creating a new entry, these won't be featured in the global state and thus will not be part of the serialized data handed to the backend class for persistence. So, technically, if you create a collection with a non-required field, you can happily create entries for which the field will never be present on the frontmatter. This is not as much a workaround for @richblend as it is a faulty behaviour IMHO so we should also discuss handling this situation.

[lmcorreia]

@erquhart I'm giving a shot at tackling this as follows:

1. Make sure the default widget values are loaded into the redux store so they can persist even if the inputs are left pristine. This goes somewhat against what was discussed in Values from string and markdown widgets come out as either empty string or undefined, depending on whether the field has been edited #1449 (comment) but seems to be the correct behaviour to expect.

2. Add the flag/option discussed here to be able to filter out the default value / emptied out / pristine inputs when persisting.

As to possible "breaking changes", I believe that users relying on the "workaround" mentioned in my last comment would be relying on an implementation detail and thus we should go ahead with launching such a feature as a minor bump (probably with a word of warning on the changelog).

Let me know what you think, I'm going to start laying down some ground work. Thanks!

[erquhart]

We definitely need the widget's initial value in the store, agreed.

Regarding including/excluding fields in output, I propose that the CMS never evaluate a field's value for "emptiness", and instead always persist values as is. The only exception would be null/undefined, which should always result in the removal of the field from output.

If we then add an emptyValue field configuration option for specifying what the value should be if the field is empty, you can set it to "" to get an empty string in your output rather than field removal. We can't drive this behavior based on required because a developer may want non-required fields to still output an empty string. The CMS should ignore the emptyValue option and defer to the individual widget for its handling.

Tangentially, I'm now thinking default should also be handled by individual widgets instead of by the CMS core. It would uncomplicate the state issues we're seeing with making sure defaults are applied correctly, as the CMS would be unaware of default values, so field values would only ever be manipulated by the widgets themselves.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[TidyIQ]

This needs an urgent fix. You can't use Gatsby with Netlify CMS until this issue is resolved.

[erquhart]

Closing in favor of #995.