Inconsistent argumentt for onRequestDelete callback about material-ui-chip-input

[advance512]

This was not fixed, right?

onRequestAdd receives an object (if you use dataSource and dataSourceConfig) while onRequestDelete receives a string, being just the value of the item in the data source.

e.g.

onRequestAdd({ label: "Some label", value: "SOME_ENUM_VALUE"});
onRequestDelete("SOME_ENUM_VALUE");

[leMaik]

It was fixed, but in the other way: onRequestDelete no always gets called with the value (which is either the string or the value property when using dataSourceConfig.

[advance512]

Isn't this inconsistent?

You get the item in one, the value in another. Sure, sometimes the item is a string, sometimes it contains a text/label and the value string.

Seems to me that it would be more consistent to stick to either value or the complete item.

Anyways, I work around it by translating it so I can use it in redux-form.

[leMaik]

Yes, but at least it's consistent for onRequestDelete calls, which it wasn't before. Making it consistent between onRequestAdd and onRequestDelete would be a breaking change, unfortunately (and I don't want to break everyone's code even if this is < 1.0.0).
I could do that when I update this to material-ui@next and bump the version to 1.0.0, though. 👍 Could you please open a new issue for that?

[advance512]

Done. Awesome work, btw. :)

I'll probably wrap it in a new lib, that support redux-form and that can integrate into Google Places. Soonish or laterish

[leMaik]

Thank you, @advance512 ☺️
That sounds like a good idea. I have an example for formsy support here, it may help you when building a redux-form wrapper.
Let me know when you're done, I'd like to link that as related project. 😉

[advance512]

I have the redux-form wrapper, actually. I had to split it into two:
A "multi-select" and a "tags input". The reason is that with a DataSource, I need to use onRequestAdd, but without one, I need to use onChange (which, btw, gives you the complete list of items, also a tad inconsistent, but there IS only one handler).

I don't have time to port my existing, ugly, component that merge react-places-autocomplete and react-select to do the Google Places thing, but I will soon - it's the only non-Material UI component I currently use.