Leif Åstrand

The interesting question here is how we can distinguish between this completely legitimate use case of icons for disabled components and a situation such as a disabled "download" link or...

Something like that might be an option even tough that puts a burden on each component with support for e.g. icons. I would also prefer introducing a wrapper that overrides...

Speculation on how to reproduce: this might be a timing issue with a component becoming invisible concurrently with a user triggering a keyboard event related to the same component.

Changing `PasswordField` to not send the string passed to `setValue` to the browser is an interesting idea, though I suspect the actual benefit is quite small. The reason for this...

Good point about storing passwords for other purposes than end-users' login details. This is indeed something that could be considered, although I'm afraid it might not be on the top...

Should be quite easily implemented with a separate server-side field for the real value and then storing a random bogus value in the shared state, although you might then also...

No changes on this front in newer versions. Seems like the warning in the documentation just wasn't picked up when documentation for newer versions was rewritten from scratch. I created...

Simplified reproduction case: ```ts import { useSignal } from '@vaadin/hilla-react-signals'; export default function EmptyView() { const s = useSignal('signal'); return {[1].map(x => {x})} } ``` It seems like this issue...

It's irrelevant whether `key` is documented as required even though that requirement is not strictly enforced. What matters is that the error message gives no indication that the cause of...

>Maybe the array index would be better here? The whole point of the `key` prop is so that the rendering logic in React would have something more than just the...