There is no point in having the details attribute

[wpalahnuk]

There is no point in having the details attribute

[wpalahnuk]

Could you expand on this a little bit? Because the ng-model and details attribute are meant to fulfil two different roles.

The ng-model is tied directly to the textbox's value, a two-way binding, changing one changes the other. The details attribute is there for if you need to access the detailed results of the google autocomplete search, the latlng, different address components, etc. It's a one-way binding to that result. You can't set this value, you just provide an object that will hold the returned results.

The easiest way to see this is in the advanced example; http://plnkr.co/edit/GF3nM3XfYX9El2w11pGo?p=preview. Where the autocomplete(ng-model) mirrors the textbox exactly, but the details(details attribute) is only changed when one of the locations is selected

[lookfirst]

Thanks for your response and the plunkr. I hacked it up to show you want I mean.

http://plnkr.co/edit/oEMo4QUleRbggMq6TGBB?p=preview

The only thing I really tested was the entering of a name into the field and seeing the 'details' section of the web page filled out correctly. My solution does kind of break the showing of text as you type since form.location.name eventually turns into a mess, but I can't actually think of a usecase for that since you are showing that same data in the input field. If you really want it, I'd add another model attribute for that.

You can also rewrite the data that goes into the ngModel to be a bit easier to navigate than going through the ugly json model that is returned from the places service.

I also suggest that you add $setValidity() handling as well so that it is possible for the user to know if the form is valid or not. Something along the lines of:

ctrl.$setValidity(attrs.ngModel, valid)

I'm not an angular expert by any means. I'm just spending a tons of hours trying to come up to speed with it and thought I'd share a bit of what I've learned. Thanks!

[wpalahnuk]

..but I can't actually think of a usecase for that since you are showing that same data in the input field..

The use case is to make it easily integrable into a form. Having ng-model bound to the textbox value makes this much easier. Sometimes you don't want all the information that comes in the detail object and just care what the textbox actually says after a user selects an option from the dropdown. Or possibly the user doesn't select something and just types something in.

If you really want it, I'd add another model attribute for that.

Wouldn't this be basically the same as how it's setup now? just with the detail object in the ng-model instead of the textbox's value?

Really I think the issue is that the value in the textbox and the value returned by the service need to be handled separately, because they could potentially be different. For example what happens when a user selects an option from the dropdown, but then changes the text without selecting a new option. The textbox's value will be different from the detail object

Would you mind explaining your use case? or providing an example? I'd really love to look at it in detail

You can also rewrite the data that goes into the ngModel to be a bit easier to navigate than going through the ugly json model that is returned from the places service.

I also suggest that you add $setValidity() handling as well so that it is possible for the user to know if the form is valid or not. Something along the lines of:

Would you mind creating separate issues for these? I'll have to look at them later.

[lookfirst]

Ah, I see your point. I'll close this issue.