onChange of Select Component should return the full data-structure and not just the value

[emmanuelonah]

What package has an issue

@mantine/core

Describe the bug

My assumption of the onChange behaviour is that it should return the full data-structure and not just the value because users might want to use the full data-structure(object of {label:string, value:string,....}).

What version of @mantine/hooks page do you have in package.json?

6.0.14

If possible, please include a link to a codesandbox with the reproduced problem

https://mantine.dev/core/select/

Do you know how to fix the issue

Yes

Are you willing to participate in fixing this issue and create a pull request with the fix

Yes

Possible fix

No response

[yshterev]

@emmanuelonah The value that goes into the select data prop usually is created from your own data structure. You should be able to access it in the onChange handler and find whatever you need.

[emmanuelonah]

@emmanuelonah The value that goes into the select data prop usually is created from your own data structure. You should be able to access it in the onChange handler and find whatever you need.

@yshterev Exactly thats my point, why do i need to run a derivative search to find what i have selected already when i could just get it from onChange.

I would say its data-stinginess looping through the data(s) when you could just pass into the onChange handler the looped object and the consumer do what they want with it rather than just assuming we only need the value field. This is a generic package and you dont know the usecases of your users. Its similar to select option onChange handler that returns an object.

[yshterev]

@emmanuelonah The obvious answer to this is that developers of Mantine UI don't want to add unnecessary logic to components and couple them with external data, unless really necessary. Increasing code complexity over time always leads to more bugs and more test cases to be covered. Accepting a request like yours ☝️ opens up the door to more similar requests.

TBH I also really like the current approach of Mantine to keep things simple.

[brrinta]

Or at least there can be a second option just like Ant Design Select onChange that contains the full option.
https://ant.design/components/select#select-props

[Hye-Dev]

If you specify the value key on AutoComplete, onChange still returns the label, despite the value key being included as a usable key in the data prop.

[pka420]

I think there should be an option to do it,
Coming from MUI, by default ChipSelect returns the whole object with onChange()

[VaZark]

I second this as the component already knows the selected data structure. Forwarding the selected item with onOptionSubmit reduces the repetitive task of walking through the data tree again on the project code.

Currently, I have a component based off of the standard Mantine Select merely to walk the data structure. Since Select already enforces a data format {label : string, value: string} it should not be a problem. This is required primarily for uncontrolled components that also have a default value

[owenshaupt]

Throwing another hat into the ring — I'd like an option to return the whole object, as well. Would be a game-changer when dealing with enums (where the label/value object is keyed using the value and not the label) which you're trying to match combobox/select inputs against.

[devdave]

This is an unfortunate quirk to how this works. Any thoughts on changing the behavior of these components to return the selected object and not just the value?

[Marjona6]

Another vote for this change. It's very annoying and time-consuming to have to search for the whole object when it could just be returned with onChange.

[rtivital]

onChange is called with 2 arguments. The second argument is the option object.

[Marjona6]

I had to build my own custom Select using Combobox because I need to show both a name and an email address in each option. But this means that the option argument being passed is composed of only active, className, value, and children, where children is React components. Is there a way to include other properties when mapping over options using Combobox.Option?

[laugri]

Hi there, adding to this. Being unable to access the object makes things extra complicated for what feels like a frequent use case.

On my part, I am using the autocomplete with async data to search within the users of my app and attach the selected user's id in a form. Two users can very much have the same name, so searching within the options using the value is not an option.

[crslam]

I am coming along with the same problem. Can you think of a fix?

[ramu-r]

Another vote for returning the label as well.

I've been using Mantine for a while and this is one change I keep coming back to again and again. Every time I get the value from a long select box and then have to loop over an array to get the label, it feels like a quick and dirty hack. It'd be great if the label was also returned along with the value.

And the label is almost always needed. Unless it's a very simple form that's immediately submitted, If I'm doing anything else with the value, I'll need the label to display the value in the page.

[ramu-r]

Ah Thanks for the reply. I was on an older version which didn't have the second argument. I updated now and it works. This should solve almost every case where I need the option.

Also, Thank you so much for creating Mantine, I'm a big fan of the library.

[wvha]

@rtivital Do you know where I can find this in the docs? Just started using Mantine and I love it so far. I would have expected to see it somewhere on this page
https://mantine.dev/form/get-input-props/

[rtivital]

It's not related to form in any way. It does not make sense to put it there. onChange function is described in the component props documentation.

[ramu-r]

@wvha https://mantine.dev/core/select/#onchange-handler

[SteveDowsett]

Its all well and good that the select component has access to the full object, but im using a combobox as i need to be able to render the options in a custom UI. You cant do that with a select (as far as im aware)

The full object really needs to be available in the onOptionSubmit as you rarely display the value that youd send back to a server for example....