I assume the issue here is that you are rendering a single nameInput instance in two places.

This is definitely not idiomatic react and I can't ever think of seeing this in the wild. Just render two instances. If you want the value synced then it should be a controlled component, where the locked state is passed in as a prop.

> If you want the value synced then it should be a controlled component, where the locked state is passed in as a prop.

This is the kind of stuff that's difficult for me to wrap my mind around. If I have to remember to "do it this way, but not that way", that's mental overhead. Especially when it's difficult to articulate exactly under what circumstances this problem occurs.

Obviously, there are plenty of people that have no problem with it. However, my first inclinations seem to be more likely to be those that React has problems with. I'm having a difficult time "thinking in React".

I'm not sure this is anything specific to react? Its just a question of internal vs external state. Internal state gets managed by the component itself, external state gets managed by some ancestor in the tree. One component's internal state is another's external state. No different to objects or any other data modelling exercise imo.

As for rendering a single instance in two places, you'd see weird behaviour trying to do the same with raw DOM element instance (well not so weird as not being able to render in two places).

Everything you say is true for pretty much every technology?

No. Some technologies use paradigms that are much more natural to me. Of course, this will vary from person to person. I'm not saying that anyone should stop using react. I'm just saying that I find it to be difficult. Specifically more difficult than other technologies.

Been working with React since 2014. That is the damndest thing ever, especially that it doesn't even throw a warning.

It seems like an identity confusion issue where the VDOM diff is ambiguous, and React resolves it in the "wrong" way. Adding keys to each `LabeledInput` resolves the issue, but I'm surprised that the runtime doesn't complain when you create the inputs without keys.

I wonder if this is why the checkbox that's checked moves, but stays in the same relative position (the second checkbox in the list): https://medium.com/@ryardley/react-hooks-not-magic-just-arra... or if it's just the ambiguous VDOM diff causing that.

If you render the inputs via a list, like

    const inputs = isBob ? [name, confirmation, request] : [name, request]

then it complains that there's no key prop and the issue persists. This shows it's because of confused identity. In the example, it doesn't complain because it doesn't understand that {name}{confirmation}{request} is essentially an unrolled loop.

    {name}{confirmation}{request}

is basically a hidden render loop. If you had something like

    const inputs = [name, confirmation, request]

and rendered that via inputs.map() (or just {inputs}), it would have complained about the missing key prop. React can't seem identify which state belongs to which item in the "iteration".

Using a conditional render like

   {nameInput}
   {isBob ? confirmationInput : null}
   {requestInput}

seems to avoid the issue as well, without using a key prop. So yeah, beware of hidden loops.

Yea, I was startled by the issue at first, but once I checked it in more detail it took me like 5min to figure out what was going on.

I'll grant the particular example or edge case is not available in the public docs, but it's extremely easy to intuit what is happening and relate it to the requirement of list components needing keys.

Like I replied to OP, you would be in all likelihood using arrays anyway, instead of this contrived pattern.

I’ve been coding in React for a few years and I’ve never seen anything like this. Bookmarking this so I can take a look tomorrow and also in case someone provides an answer.

I seem to have a talent for coming up with things that shouldn't be, can't be, or are difficult to express in react. Note that I'm not particularly interested in other ways of writing this that would work. I now know several. I'm more interested in simple general rules that one could follow to stay out of trouble.

> I'm more interested in simple general rules that one could follow to stay out of trouble.

I don't know what to tell you, just don't do this?

I've been working professionally for years in React and have never encountered this particular issue. Once I've gotten to to it this morning with fresh eyes it's taken me like 5min to understand - React sees this as a list of the same element, which requires keys - this on the other hand is extremely common and well documented, so even a junior could intuit it.

This is a contrived example and as a moderately experienced developer you would almost certainly reach for the idiom, which would be rendering the input as a list with a map, in which case you would see clearly what's going on, get a warning, and a clear mapping to the official docs [1]

As far as footguns go, I think this is a weak and contrived example. I get why one would not want to work with React - maybe they don't like JSX, or the lack of baked-in state management, that there are a million ways to do the same thing, the general philosophy of the framework, etc.

But I've worked with many other technologies on the front and the back end and not only have I seen infinitely worse than this, I can't think of a technology where if you try really hard to break it, you won't find ways to do so.

[1] https://reactjs.org/docs/lists-and-keys.html

Thanks for your thoughts.

I eventually did figure out what's going on. I did figure out that using key= solves it. I also found I could use class components and make the three labeled instances in the constructor. That gives them a long enough lifetime to stay consistent also.

I'm not trying to tell anyone else they shouldn't use react. It's great that so many find it to be so productive.

You might say I dislike the general philosophy of react. I would rather choose whether I'm using 1-way or 2-way binding than being told. I actually have come around on JSX. I think it's pretty good now.

As for being weak and contrived, I don't know what to tell you. This honestly seems like a natural way to write this. I'm a react beginner. When I ran into this, it took me some time to figure it out, but I did eventually. I suppose another part of the philosophy I don't like is entire premise of virtual DOM and reconciliation. It creates another layer of concerns the developer needs to think about. This kind of stuff should be an implementation detail. Instead, you have to remember to use an array rather than unrolling. Or just use keys everywhere. More precisely, maybe you don't need to. But I would need to.