Allow selection of entire item

[mcampster]

ui-select allows you to bind the entire item to ng-model. e.g. You have an array of countries:

[{name: "Australia", code: "AUS"}, {name: "United Kingdom", code: "UK"}]

You want to bind the selected country to your model - not so you have have either the name or the code, but the whole object so you may have

$scope.selectedCountry = {name: "United Kingdom", code: "UK"}

With the angular-schema-form-dynamic-select add on, you are forced to return your titleMap in name/value format. Whilst the map function allows you to pick a single property from each item to be your $$value$$, it would be nice to be able to select the whole item.

[mcampster]

The only work around I have at the moment would be to return, from my async service, a response like this...

[{
  name: "Australia", 
  value: {
    name: "Australia", 
    code: "AUS"
  }
}, {
  name: "United Kingdom", 
  value: {
    name: "United Kingdom", 
    code: "UK"
  }
}]

[nicklasb]

Actually, that is by design. I find it pretty odd to work with the objects themselves and not unique identifiers of some sort.
No offence, but I have difficulties imaginig a properly designed system that would require this?
What is the use case?

[mcampster]

System design aside, its a feature of ui-select and strap select that is being removed/masked by the add on. I'm simply suggesting that it should be up to the developer to decide how they use it.

Back to system design, unique ids is a very relational db way of thinking about things. Since this is a front end component, why should we be constrained by foreign keys and the need to lookup relationships in order to display the information we really want.

What about a fantasy football team. You had to choose 11 players and were not allowed to spend more than $100mil. Each player is selected using a ui-select. If you wanted to display a running total of how much you've spent and also who you had selected, how would you display that total? If each selected item was actually the player object, then aggregating the total would be easy. If it was a player id, now you have to perform some lookup of the id against some kind of player-store to find out their value and sum that. A bit of a crazy example, but I think perfectly valid.

[mcampster]

My suggestion would be to default to using the value, unless otherwise configured.

[nicklasb]

Actually, one of the reasons was that it actually wasn't a feature of strap select, only UI-select. That may have changed, though, And if you look att the stuff on this page, you'll see that everything is mongoDB-based. So not that relational. And for some reason, everything in a MongoDB database has an ID. And not without reason. IDs are always there somewhere.

Sure, there are use cases where the easiest solution is having the objects, and I am not much for complexity and strictness for its own sake. Today, most applications don't need relational databases for most things they do. But this is not about that.

Because WRT the fantasy football team, that's easily handled by bindings and views, not crazy things at all and basic functionality of Angular and all other frameworks. The deal with stores or whatever you may call them is that they ensure that you have each data in one place within the application and handled the same way. All CRUD and cache operations propagates around the application and ensures consistency. I am not talking about some externa data store, BTW.

Next, the problem is that you will probably need to use the data in the select for other stuff. And then your selects become your data stores. So then you have stores anyway. And in scopes other parts of the application may not naturally reach.

True, eventual consistency is a great concept sometimes but within an application it may become quite problematic unless you really have designed around the concept, and typically, that is how for example FB as a whole is designed, but not necessarily its individual functionalities.

So because applications will grow and data will change, I am careful with how I manage it. I start with figuring out where to put it and how to handle it. And then I go from there.

And totaly regardless of everything, I won't change the default behaviour of this component and break it for everyone using it.

If you feel that this is important functionality, I would certainly embrace a PR making it an option. :-)