Value Bindings

[luggage66]

For discussion:

I added some value bindings for my personal use. If there is interest in adding these I can add tests, documentation, etc.

They are to bind the "Selected value" from the autocomplete to the viewModel without writing a select event handler for the purpose each time.

<input data-bind="autocomplete: { source: PossibleColors, selectedValue: SelectedColor}" />

var viewModel = {
    PossibleValues: [ 'Red', 'Green', 'Blue' ],
    SelectedColor: ko.observable();
}

There are 3 new 'bindings'.

• selectedItem: Gets the ui.item
• selectedValue: Gets the ui.item.value
• selectedLabel: Gets the ui.item.label

[gvas]

@luggage66: Thanks for the pull request!

Can you describe a real-world scenario when using these new bindings leads to simpler code than using the autocomplete's select event? After the user selects an item from the list, the selected item is stored in an observable. But you also have to be notified about this event, so you can use the stored value somehow. That means that either you have to create a subscription to the observable (this isn't better than subscribing to the autocomplete's select event) or use the observable in a computed. I think this latter case is where the new bindings could be useful, but I don't see how.

Also there is certain discrepancy between these bindings being one-way and that they must be bound to observables. I think one-way bindings are better handled by events, while observables are more naturally fit with two-way bindings. I was thinking about turning your selectedValue to a 2-way binding (it would be synchronized with the input's actual value), but then realized that knockout's built-in value binding could be used to do the same thing:

<input data-bind="autocomplete: {...}, value: actualValue" />

[luggage66]

I can make it write to non-observables to make it more flexible. I can also look into making it 2-way, which may be useful.

These bindings are nothing more than shortcuts to writing onSelect handlers for our most common scenario data-bind="autocomplete: { selectedItem: client, source: clients }, value: client.label". We use the ID (ui.item.value) in our api and carry the text (ui.item.label) along for the UI only. If it's too specific and doesn't belong in this library, that's cool, too.

[gvas]

I think that the selectedItem, selectedValue and selectedLabel can't be converted to 2-way bindings in an intuitive manner. If they remain 1-way then they should be handled by an event handler. I won't add them to the library.

I understand that these new options would make your work easier, so I have added new extension points to the binding handlers. Using those you can add your options to the autocomplete binding without recompiling the library. Please note that the extension points are only available from v0.7.0 of the library.

I hope that this is a satisfactory compromise.

[luggage66]

That's perfect.