Rmwc: Chips: The purpose of onRemove vs onTrailingIconInteraction

[TrySpace]

"rmwc": "^5.7.1"

I don't really understand why the behaviour of clicking on the trailing icon internally removes the chip (It should then rather be called removeIcon), while we also have a onTrailingIconInteraction method we can use, but basically I have no choice in what the behaviour of the trailing button is...

So why even have a separate onTrailingIconInteraction, while we can just use the onRemove (except having the different eventType perhaps)?

The issue I have is that I'm rendering an array of chips [ 1, 2, 3 ]:

  map(tags, (tag, key) => {
              return (
                <Chip
                  key={key}
                  label={tag}
                  icon="close"               
                  onRemove={evt => this.props.removeTag(evt)
                />
              )
            })

Then in the parent I'm removing the tag from the array (because I need the new state of the tags, which the component does not provide afaik, so I create a new array of the items there)

But what happens then, is it updates the state of the component, re-renders the tags, but will remove TWO array items, because internally it is being removed, but also externally. So both the states are out of sync....

The only way right now to avoid this behaviour is use icon='close' so the remove icon is on the left side, so I can remove it like I want to.

I'm not sure what the intended way is to use an array of items statefully, instead of only having an initial tag array rendered, and then using the chipId value to remove it and update a state, but then the chips are not adherent to the state anymore, and live in their own isolated reality.

Perhaps adding a property to the ChipSet like dontUseOwnState or customRemoveBehaviour, idk.
Although my opinion is that a component like this should not use its own isolated state eitherway, but that would deprecate it.

[jamesmfriedman]

I wholeheartedly agree with your opinions on state management. One of the more awkward parts about building / maintaining this library is the integration with material components web. There are several open issues (some by me) around the fact that they don't implement proper control flow in their component patterns. I've had to go to some extreme lengths in order to workaround these shortcomings.

As far as the specific issue with the chip, can we some it up by saying you would like the trailing icon to be something other than an X and NOT automatically remove the chip?

[TrySpace]

As far as the specific issue with the chip, can we some it up by saying you would like the trailing icon to be something other than an X and NOT automatically remove the chip?

Yes, that about sums it up 😜

[sangdth]

It took me 1 hour until I realized this weird behavior is not my fault. Damn! 😢

[TrySpace]

you would like the trailing icon to be something other than an X and NOT automatically remove the chip?

yes, otherwise there is no real point in customizing the icon, or having a separate onTrailingIconInteraction

[jamesmfriedman]

Yeah, I agree on all counts. This stemmed from trying to implement all of mat-webs underlying apis, but I agree there is not purpose for something like that, especially in React.

Will get this cleaned up for the next big release which is getting closer.

[jamesmfriedman]

This seems like the lesser of all evils without breaking current behavior

/** Defaults to true. Set this to false if your trailing icon is something other than a remove button. */
  trailingIconRemovesChip?: boolean;

[jamesmfriedman]

Fixed in 6.0.0.