null/undefined property logic can result in unexpected behavior with custom elements

[jramanat-oracle]

Describe the bug
When preact is reconciling vdom to the live dom for a property that's defined on the target element, it goes through this code:

                else if (
			name !== 'href' &&
			name !== 'list' &&
			name !== 'form' &&
			// Default value in browsers is `-1` and an empty string is
			// cast to `0` instead
			name !== 'tabIndex' &&
			name !== 'download' &&
			name in dom
		) {
			try {
				dom[name] = value == null ? '' : value;
				// labelled break is 1b smaller here than a return statement (sorry)
				break o;
			} catch (e) {}
		}`

Namely, it coerces null/undefined values to the empty string before doing a property assignment. This can lead to unexpected behavior for custom element properties that are not expected to be string-valued (and for which null/undefined may be legitimate property values).

To Reproduce
Steps to reproduce the behavior:

1. Go to https://codesandbox.io/s/zen-satoshi-vw6c8?file=/src/index.tsx (note the initial undefined behavior)
2. Click on any of the numeric-valued buttons and see the expected results.
3. Click on the null or undefined behavior and see the misleading '55' output rather than the expected initial behavior.

Note that in the initial rendered case, the "base" property of the element is undefined and the component renders accordingly. However, after selecting another value, there's no way to get back to that same initial state. Additionally, since this property was not coded to expect strings, the addition operator results in string concatenation which can produce misleading output when the intent was to specify null/undefined.

Expected behavior
It should be possible to specify null/undefined values for custom element properties.

[jramanat-oracle]

I'd be happy to work on a PR here, but wanted first to check whether the use case we're trying to support seems reasonable, and if so, what the original intent was behind this empty string coercion to better understand the constraints of any possible code fix.

[JoviDeCroock]

Still accurate on main src/diff/props.js#L123 continues to coerce null/undefined to '' before the property assignment.

Closing this so the discussion happens in one place rather than three. Please follow and weigh in on #4416 — a concrete custom-element use case like yours is genuinely useful input for that decision. Sorry it sat this long without a straight answer, and thanks for the precise write-up and repro.