Angular-google-maps: Allow for two-way data binding syntactic sugar

[lazarljubenovic]

Issue description
A common flow of data in Angular is to pass data in and out of components, creating hierarchy tree. For interactive things such as map, we usually want our data to change according to user interaction, such as moving the sebm-google-map-circle.

For example, there is input radius which means we can do [radius]="radius". There is also output radiusChange which means we can do (radiusChange)="radius = $event.radius". Angular provides syntactic sugar for this: [(radius)]="radius". When we change data, view changes. When the view changes, data changes too.

However, this is not possible for most other inputs. For example, [latitude] and [longitude] are inputs, but the output for this is (centerChange), which encapsulates both lat and lng values, making the code awkward.

Steps to reproduce and a minimal demo of the problem

Here's the plunker if what I'm talking about isn't clear enough: http://plnkr.co/edit/d4Ldrs3WCMhqkeCvjhSO?p=preview

Current behavior

<sebm-google-map-circle
    [latitude]="lat" [longitude]="lng"
    (centerChange)="lat = $event.lat; lng = $event.lng"
    [(radius)]="radius">
</sebm-google-map-circle>

Expected/desired behavior

<sebm-google-map-circle
    [(latitude)]="lat" [(longitude)]="lng"
    [(radius)]="radius">
</sebm-google-map-circle>

or

<sebm-google-map-circle
    [(center)]="{lat: lat, lng: lng}"
    [(radius)]="radius">
</sebm-google-map-circle>

angular2 & angular2-google-maps version

All.

Other information

I didn't have the opportunity to try all the components this package offers, but I took a quick look at the source code and found many mismatches like this, or a complete lack of the outputs. The circle and position/lat/lng thing I mention here is just an example.

[SebastianM]

@all please give your opinion on that topic. IMO it's not needed and follows the way the Google Maps API works.

[staticint]

I feel totally unqualified to comment on this as I am primarily a backend guy. But from what I understand two-way data binding is considered slow and reactive models is the current mindset to solve two-way data binding needs. Feel free to teach me something new.

[lazarljubenovic]

@staticint Quick summary of how it works follows. In Angular 2.x+, "two -way data binding" is a bit different from what it was in AngularJS 1.x (as far as I understood Angular 1 at least, I barely have any experience there). [(value)]="foo" is expanded to [value]="foo" (passing data in) and (valueChange)="foo = $event" (listening to event). It's really just a naming convention and some syntactic sugar on top. Data still flows only one way (the new Angular mantra of sorts).

As about my opening post here. It was just something I happened to need and expected to be available.

follows the way the Google Maps API works.

I don't have much experience with basic API, and I'd argue it might not always be a good idea to directly follow it and map it one-on-one.

Having [latitude] and [longitude] for inputs and (centerChange) for output is just weird to me. My intuition just calls for the same name here: [center] and (centerChange). Also having separate [latitude] and [longitude] inputs is not really necessary, since it's extremly rare to input only one of those, or to keep them in separated variables. Pretty sure everybody has something like [latitude]="position.lat" and [longitude]="position.lng" in their code. So another reason to have [center]="position" and then my suggestion would automatically be available because (centerChange) already exists.

I don't mind it though, it works perfectly fine this way, but as I see it, it's not using Angular's full potential and is a tad bit more code than it has to be.

[staticint]

@lazarljubenovic thanks for the clarification on how angular 2 data binding works.

[d4nyll]

@SebastianM @staticint Thank you for your work on this plugin.

I agree with @lazarljubenovic, that the lat and lng properties should be combined into one. You can then use the existing LatLngLiteral interface.

Not being able to bind the property two-way is not intuitive the way I look at it.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.