An empty Field.String produces undefined by default, not an empty string

[kimroen]

🐛 Bug Report

This could be expected and intended behavior, and if so you can close this and consider it feedback 😊

When you empty out a Field.String, the resulting value in the form is undefined, and not '' (an empty string). This can be confusing, especially if combined with a default data value of '' when setting up the form.

To Reproduce

In this CodeSandbox, we find a form with one field which has the default value '', and a corresponding Field.String to edit it:

function MyForm() {
  return (
    <Form.Handler defaultData={{ myPath: '' }}>
      <Field.String path="/myPath" />
    </Form.Handler>
  );
}

The value of /myPath when this form is rendered is '', as expected. However, when you type a character and then remove it, the value of /myPath is undefined.

Expected behavior

I expected the value of /myPath to be an empty string after editing, not undefined.

Why is this unexpected?

If you've worked with React for any amount of time, you've probably done something like this to make a controlled input:

const [fieldValue, setFieldValue] = useState();

return (
  <input value={fieldValue} onChange={(e) => { setFieldValue(e.currentTarget.value) }} />
);

And if you have, then you've also seen this warning that shows up when you start typing:

Warning: A component is changing an uncontrolled input to be controlled. This is likely caused by the value changing from undefined to a defined value, which should not happen. Decide between using a controlled or uncontrolled input element for the lifetime of the component.

So at least for me, I instinctively give the value a default value of empty string.

As a bonus, keeping it a string makes dealing with the types easier 😊

Eufemia Version

Browser JS: 10.51.2

Browser CSS: 10.51.2

[kimroen]

Now I realize that there's a property called emptyValue that we could specify to be an empty string, but two things:

1. I expected that to be the default
2. If you specify that and also specify an empty string in defaultData on the form, then the actual value until the field is edited is undefined. This is probably a separate bug, though

[andlbrei]

I'll chime in with my viewpoint based on using JSON schema for validation.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": [
    "myString"
  ],
  "properties": {
    "myString": {
      "type": "string"
    }
  }
}

This will allow myString: "", but not myString: null (or the absence of the attribute).
In our case this works fine. No value in the field means it's not a string. If we would want an empty string, we'd set it with emptyValue (I don't see any case where we need to have an empty string though).
If the default would be an empty string, we would need to have a minimum length check as well to ensure the string actually has content.
Not a big deal, but more work.

[tujoworker]

I think that its unlikely that we can change that in the future. For sure can we try to create tools to make fields/components as easy as possible to use.
But when we see at other fields, like the Number field, then I think its more clear that undefined as a "data" value, is a good choice. Because we often can't have a default value.

I think its great to have a discussion around this, and any suggestion to improve the tooling are welcome 🫶

[kimroen]

I think that its unlikely that we can change that in the future. For sure can we try to create tools to make fields/components as easy as possible to use.
But when we see at other fields, like the Number field, then I think its more clear that undefined as a "data" value, is a good choice. Because we often can't have a default value.

Yeah, like I said in the "bug report" I expected as much 😊

Two more points, just to have mentioned them:

1. If we treat the empty value of a string field as undefined, then the type of it in data needs to be string | undefined. The type that we receive in onSubmit for the submitted value is the same type as the type of data in general. Especially when fields are also marked as required, that can be annoying and/or require extra parsing as part of submit to clarify/prove that the value is the expected shape in the end. This problem is not caused by the type of empty string fields, but having it work like this makes it relevant for more fields
2. We often want to trim the value in a string field before evaluating presence, and since trimming a string with only spaces results in an empty string (not undefined), that is implicitly also an "empty value" regardless of the default

Either way, we're probably going to fix this in our case by using the default of undefined and then coercing to an empty string before submitting. This was mostly about it being like this by default being unexpected 😊

If you specify [emptyValue=""] and also specify an empty string in defaultData on the form, then the actual value until the field is edited is undefined. This is probably a separate bug, though

About this one, I suppose I should report that as a separate bug.

[tujoworker]

Thank you for the good feedback 🫶

If you specify [emptyValue=""] and also specify an empty string in defaultData on the form, then the actual value until the field is edited is undefined. This is probably a separate bug, though

Yes, this is a bug. Here is a PR #4111 with an attempt to fix this.

[tujoworker]

We often want to trim the value in a string field before evaluating presence, and since trimming a string with only spaces results in an empty string (not undefined), that is implicitly also an "empty value" regardless of the default

If you trim simply white spaces, you can use the trim on all string fields.

[tujoworker]

I expected the value of /myPath to be an empty string after editing, not undefined.

I have two suggestions. And I'm not sure what we can or should do. So I would like to get your thoughts about it:

1. We could "remember" the given "defaultValue" from the data set. For empty strings, it may be just as fine. But what about numbers? or other data types? They need to still fall back to undefined.
2. You could solve this on your side by using a transformIn on the Form.Handler:

const transformIn = ({ value }) => {
  if (value === undefined) {
    return ''
  }
  return value
}

[tujoworker]

🎉 This issue has been resolved in version 10.52.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[tujoworker]

Proposal

Introduce fallbackData on the Form.Handler that can contain values that will be used when a field gets undefined.

When used with defaultData , it will be deep merged, but the defaulData will take precedence for the "initial" data.

When emptyValue is set on a field to something else than undefined, then this value will take precedence over fallbackData.

What are your thoughts on such a way of solving the "issue"?

[kimroen]

Thanks for the additional thoughts!

We could "remember" the given "defaultValue" from the data set. For empty strings, it may be just as fine. But what about numbers? or other data types? They need to still fall back to undefined.

I'm not sure I understand how this in turn would relate to defaultData on the form handler 🤔 We use defaultData to pre-fill the form with various data from the backend when someone is resuming filling out a form, so in those cases we don't want them to be the empty value, but I take it that today if you set defaultData the value there will override the defaultValue on the field (I wasn't aware of this property)?

You could solve this on your side by using a transformIn on the Form.Handler

Interesting, I haven't looked much at these transform functions so that could be something to look at for sure 👍

Introduce fallbackData on the Form.Handler that can contain values that will be used when a field gets undefined

Not quite sure what I think about this - the first reaction I have is that I'm not sure this is a better remedy to the unexpected behavior I reported here than just surfacing the default behavior a bit more would be 🤔

• The word "fallback" here, what is the meaning in this context? If the user hasn't picked anything, then "fall back" to this value? Or more in a technical sense, the "value" in the form will "fall back" to this value when it's not set?
• What's an example of how this could be used that means fallbackData is better than something closer to the existing "emptyName" naming pattern?
• How does this relate to "resetting" the form?

I think I'll have to pretend it exists for a moment and try it in our actual form to see if this makes things simpler or not. Gut feeling is that it'll just be repeating the shape of the form data in a new spot, but maybe there's some default behavior or merging I'm not thinking about.

[tujoworker]

Thank you for all your thoughts and feedback – they’ve been really helpful.

I understand that introducing something new can add complexity, which we want to avoid. Changing the current behavior of defaultData could also lead to unwanted side effects.

If emptyValue and/or defaultValue can address the actual issues where they arise, I believe that's the best approach.

But we still may optimize the outcome of these, such as TypeScript support, like you mentioned:

As a bonus, keeping it a string makes dealing with the types easier 😊

[tujoworker]

🎉 This issue has been resolved in version 10.54.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀