Kendo-angular: [DropDowns] Preventable valueChange event

[JacopoSciampi]

I'm submitting a...

• Bug report

Current behavior

Expected behavior

It would be perfect if the selectionChange event give the user the entire Event with in it the value changed.

Minimal reproduction of the problem with instructions

There is no need to use plunker or post some code. Just add a selection change and call a function in your component.ts to see what the event passed is, and you will figure out that it's always the "name" of your selected item.

What is the motivation or use case for changing the behavior?

I'm currently programming a code where I need the dropdown-list prevent the default action in some cases. So in my code that is simply a (selectionChange)="myFunction($event)", when the selection change I just got what it changed, without the possibility to interact with the event. If I'm right, in javascript the selection change give you back the entire event (but I could be wrong).

Environment

Package versions:

Omit this step if the problem is reproducible on our demo site.
Browser:

Every browser

System:

• TypeScript version:5.6.0
• Node version: 5.6.0
• Platform: Windows

[luKiPfeffer]

I would also need this functionality.
Otherwise i see no possiblity to cancel the selection event:

e.stopPropagation();

[dimitar-pechev]

The selectionChange event emits the entire selected value, not just the name, i.e. if you are using primitive values as data for the dropdownlist, the emitted value will be the selected string (see example), and if you are using objects - the entire selected object will be emitted (see example).

Currently, there are no plans for making breaking changes to the dropdownlist api in order to make the selection event preventable. Apart from changing the api, making the event preventable raises a few questions:

• What do you expect to happen when you prevent the selection when the user clicks on a specific item (clear the entire selection or revert to the last valid one)?
• The selectionChange event is also fired when the options list is closed and the user changes the value with the keyboard arrows. What happens when he reaches an item the selection of which is prevented (e.g. should it skip that item)?

What you could use, however, is the recently added disabled items feature (available in the package kendo-angular-dropdowns v. 3.1.0). To use it, you are expected to pass a function to the dropdownlist component that checks each item on the list against certain criteria defined by you. This way you can prevent your users from selecting those items in the first place.

[ujaske]

When preventing selection I would expect that nothing happens - no state change at all.

Disabled items are not a substitute for preventing selection. E.g. the following scenario: I want user to be able to select any value from dropdownlist; Upon selection a warning popup is displayed allowing the user to cancel or confirm the action; Only if the user confirms I want to apply the selection that was made and have it reflected in GUI.

I thought that this will help me to do exactly that:

Use the value property. If the value is set through the value property, you have to hook up to the valueChange event and manually update the value of the value property.

The above _almost_ works. The value is not updated as expected, however dropdownlist's GUI does not reflect that the value has not changed - it shows the newly "selected" value.

[tsvetomir]

Just to note that a preventable selectionChange event will not help with the above scenario.

The event can only be cancelled synchronously while the dialog implies asynchronous confirmation, unless it's a plain Window.confirm()

[LambdaCruiser]

Ujaske raises a great point here. I would expect that using value & valueChange bindings gives me full control over the value of the dropdown. And yet the displayed value changes even if I don't do anything in my valueChange handler. I consider this a bug - there should be no side effects like that in the Angular world, the value displayed on the control should stay in sync with its [value] input at all times.

If I had full control over the value then the above scenario would not be a problem. There would be no need to prevent the event - if the user does not confirm the warning I just wouldn't change the value at all.

[geraldbauer]

Why not have a new event? A pre-change event? The use case that @ujaske describes is one I have also. Having the ability to display a modal warning message telling the user that the change has ramifications and asking if s/he want to continue is a good user experience. (Not ideal, I have a work around - calling back into the changed event method to reset the value. And yes, I code by keyboard and mouse events.)

[dimitar-pechev]

I thought that this will help me to do exactly that:
Use the value property. If the value is set through the value property, you have to hook up to the valueChange event and manually update the value of the value property.

The component value will be updated according to the passed value through the template, however, that value needs to have changed in order for Angular to register it. If the value hasn't changed with a change detection cycle in between the old and the new value, the framework will not even notify the component that something had happened.

Ujaske raises a great point here. I would expect that using value & valueChange bindings gives me full control over the value of the dropdown. And yet the displayed value changes even if I don't do anything in my valueChange handler. I consider this a bug - there should be no side effects like that in the Angular world, the value displayed on the control should stay in sync with its [value] input at all times.

The DropDowns hold the concept of internal value - thus the internal value is changed upon user interaction even if the bound property is not updated. The same behavior is observed with a plain input or a select element. Here's an example with the aforementioned native HTML elements.

Why not have a new event? A pre-change event? The use case that ujaske describes is one I have also. Having the ability to display a modal warning message telling the user that the change has ramifications and asking if s/he want to continue is a good user experience. (Not ideal, I have a work around - calling back into the changed event method to reset the value. And yes, I code by keyboard and mouse events.)

We've considered this as a possible enhancement, but as mentioned above, having a synchronous event will not allow the user to use custom dialogs. So this would still not work.

So, after an internal discussion we've decided to not implement anything in that spirit and provide just an example how the value can be controlled through the component API with a confirmation dialog. Here's a demo.

[skultetc]

I know this issue is closed, but I wanted to let you know I'm also looking for this functionality. While we are not able to use a synchronous event with a custom dialog, being able to prevent propagation of the event would allow us to stop the change event on certain conditions, display the custom dialog, and based on the response do nothing or manually make the value change. If the condition doesn't meet our custom criteria then we let the event continue. Currently this is not possible at all since we are unable to stop the event conditionally.

[dimitar-pechev]

The DropDowns do allow you to control their value through their API, so if you want confirmation on value change and not seeing the new value at all before user prompt, you can store the contender value, set the component value to its previous one, prompt the user, and only then change the component value to the new one. Here's an example.