Change Interaction::None to NoInteraction

[anthonyarusso]

The bevy::ui::Interaction interaction enum has an unidiomatic Interaction::None value. E.g. earlier I wanted to optionally query for interactions to a button entity, however matching Query<Option<&Interaction>, With<Button> would never reach the None arm.

[anthonyarusso]

@alice-i-cecile mentioned the issue of Interaction::None.is_none() == false which may not even compile.

[Davier]

earlier I wanted to optionally query for interactions to a button entity, however matching Query<Option<&Interaction>, With<Button> would never reach the None arm.

That's the expected behaviour. You never reach the None arm because all your entities with a Button component also have an Interaction component (since it's included in ButtonBundle). The query should probably be Query<&Interaction, With<Button>.

@alice-i-cecile mentioned the issue of Interaction::None.is_none() == false which may not even compile.

Not sure what that means. Is it a suggestion to implement is_none() on Interaction?

Aside from that, renaming Interaction::None makes sense if it's confusing people, so I'm in favour.

[alice-i-cecile]

Not sure what that means

This was a comment by me in Discord, mentioning that it's very strange that the standard is_none method doesn't work for an enum variant called None :) It's clear why it wouldn't, but it still causes confusion and extra cognitive load.

[cart]

Hmm imo Interaction::NoInteraction is redundant. I personally prefer Interaction::None because it's consistent with Option, not despite it. I'm not aware of any recommendations to not use None in enums. If anything, it feels idiomatic to me.

[cart]

I'm down to consider alternatives, but I'd prefer it if they didn't have Interaction in the name (and I'm still biased toward None).

[alice-i-cecile]

What if we solved this by adding and removing this as a sparse set component, then querying for the Option form? Much more feasible if we had #1613 though.

[Davier]

What if we solved this by adding and removing this as a sparse set component, then querying for the Option form? Much more feasible if we had #1613 though.

That's not possible. Interaction is set to None by default, and anytime the user stops clicking or hovering on the entity. If you remove the component, you remove the entity's ability to be interacted with.

[mockersf]

If you remove the component, you remove the entity's ability to be interacted with.

The system that manages that could work differently, with an Interactable component for entity selection, and then adding/removing the Interaction component to set its status. I think that would be less ergonomic, as it means the user would now have to check the component for its value, or if it was removed, but it maybe has better semantic that way

[cart]

I think redesigning the api should be out of scope for this pr (which is just about naming). This probably won't be the last time the Enum::None pattern shows up, so its worth discussing it. My preference is still for Enum::None over Enum::NoEnum. If nobody offers alternatives that don't repeat the enum name, I'm probably just going to close this out 😄

[cart]

Closing for now. Feel free to discuss further here if you come up with alternative ideas.