react: Controlled inputs with the potential for `undefined` value

How about removing this warning? It really annoying and makes me write unnecessary checks. To my mind it is normal when in flux Store you have some data which is undefined

you can put value prop is null. No this also pops an error.

Resurrecting a zombie here. The number of newcomers struggling with this is so high… It migth be the most repeated react question in code sandbox. I think we all struggled with this once in our react learning and it’s crazy that 6 years after React keeps forbidding you to use undefined as a value and forcing to use ' ' or similar.

What if we actually want the value to be undefined or null?

Forcing people to use useEffect() or adding a logic layer to transform the '' values feels so weird.

Example: When I erase a number input I certainly don’t want to send a ''. I want to send a null or interprete indefined/null as a delete or similar.

'' is not delete, is an empty string, and thats a different thing.

Uncontrolled components are rare, i guess it would be nice to indicate that they are uncontrolled somehow and just make everything controlled by default 🤔

Ultimately, what you are really trying to specify is “this component is controlled, but is currently empty”. It is intentional that you specify this by setting the value to be the empty string. When the value is specified as undefined, React has no way of knowing if you intended to render a component with an empty value or if you intended for the component to be uncontrolled. It is a source of bugs. This is why the warning exists.

It sounds to me that this.props.search.get('term') should return the empty string instead of undefined, assuming the initial value of the search box is the empty string.

Alternatively, you could do a null/undefined check in this component, before passing the value to the input.

We haven’t received too much push back on this one, so I think it’s uncommon enough that the benefit outweighs the cost. Therefore, we probably aren’t going to change this, so there is nothing actionable in this bug. However, if our thinking changes on this matter, we can certainly reconsider.

React has no way of knowing if you intended to render a component with an empty value or if you intended for the component to be uncontrolled. It is a source of bugs.

While i can see the point, that this might be a source of bugs. I kind of disagree on the first part. The value property is part of the props object. Therefor you can use Object.keys() to figure out if that key has been intentionally added to the props object or if it hasn’t been. The key will exist if you explicitely set the property even if its value is undefined. When going with this approach <MyInput value={ undefined } /> would be a controlled component and <MyInput /> would be uncontrolled.

+1, please it’s really annoying.

A bit silly to get this warning. I’m not actually changing an uncontrolled input to a controlled input just because the default value is undefined. The element is controlled from the start. So the warning is wrong. So do I ignore the warning or do I implement a workaround for just this invalid warning by specifying || ''? I’d prefer the first, but sadly then my console gets way too messy. Is it possible to disable warnings?

Just hit this warning and realized that I actually do want to have undefined as the initial value otherwise how does the placeholder het rendered? The input box uses placeholder to render in case the initial value is undefined and setting the value to anything else stops the placeholder string from rendering.

This is just so annoying and doesn’t make a lot of sense. Another use case for undefined is when you have a number-only input, and you wish to be able to display an empty input, without the defaulted 0. Can we maybe get some traction on this?

@MartijnHols careful using || operator as a work-around: if the state variable is set to 0 or false, then comparison this will evaluate to '' (empty string) and overwrite the field value. My work-around was to use a helper function, https://github.com/garudacrafts/fun-fp/tree/master/src/function/coalesce, to check for undefined using typeof operator and wrap all my variables, like so: value={coalesce(this.state.session.date, '')}.

We had this exact problem:

// Clearly controlled
<TextField value="foo" /> 

// Should these be controlled or uncontrolled???
<TextField />
<TextField value={ undefined } />

We cycled through a few different options:

1. Pass null for the “controlled but blank” case. Not a huge fan of having both null and undefined hanging around though
2. Pass '' for the “controlled but blank” case. Works great for a TextField, but fails for a NumberField where there is no equivalent of an empty string. (0 is not ideal here either because sometimes we genuinely want the field to be empty)
3. Check if ('value' in props) to decide whether the component is controlled or uncontrolled. Very subtle/implicit though, requires us to spread ...props in both the TextField and anyone who wraps TextField e.g. NumberField
4. Pass a new prop like controlled={ true | false }. But eeeh. Feels like too much mechanics for the caller to be worried about
5. Make value a wrapper object like value={ { value: 'foo' } }, meaning if value is present, the component is always controlled, if not, it is uncontrolled.

// Uncontrolled
<TextField /> 

// Controlled with undefined value
<TextField value={ { value: undefined }  />

// Controlled with defined value
<TextField value={ { value: 'foo' } } />

^ I like this the most. It’s extra boilerplate, but it can be enforced with Typescript, and it’s reasonably explicit without requiring a whole new prop.

---

Quick addendum: why use uncontrolled components in the first place? I feel like as a general pattern it’s nice to have a component that only passes up a value to the parent when it is in a valid state; especially when you start building fields for more complex types like objects with multiple required fields, that take time and multiple keystrokes/clicks for the user to input.

BUT there are always going to be cases where you want the field to be controlled, so it’s pivotal to have a way to differentiate between them. And just checking if (value === undefined) doesn’t cover the case where the value is intentionally undefined.

Uncontrolled components are rare, i guess it would be nice to indicate that they are uncontrolled somehow and just make everything controlled by default 🤔

Although I generally agree with the opinions in this thread, I cannot support this statement. I’ve worked on projects where uncontrolled inputs are practically the default in every form. They are generally way more performant and have lately gained a lot of traction with libraries like react-hook-form.

It conceptually makes sense for the input to take undefined as value, as it is (for example) a valid return/render value for components. Seems to me like this would require a switch to a hasOwnProperty check in

https://github.com/facebook/react/blob/8e2bde6f2751aa6335f3cef488c05c3ea08e074a/packages/react-dom-bindings/src/client/ReactDOMInput.js#L40-L43

but I am not familiar enough with the react internals to say that this won’t cause a million other problems.

@jimfb One thing I don’t understand about the underlying idea is this: Uncontrolled components are supposed to use fValue instead of value – why does that not lead to the reasoning that the use of defaultValue means that the component is uncontrolled?

If both defaultValue and value are undefined, the component would assume to be controlled, which should not really break anything, right? So that approach should cover both use cases and enable undefined as a valid value for value without the warning.

Also, I find @cdxOo’s argument quite compelling.