[feature-request] declarative access to currentUser

[Scarygami]

As opposed to waiting for the google-signin-success event or binding to signedIn and observing changes, and then getting the user information as gapi.auth2.getAuthInstance().currentUser.get().getBasicProfile() it would be nice to have this information exposed as currentUser property that could be bound to instead of signedIn.

That would simplify creating a log-in UI that displays name/picture of the logged in user after a successful authentication. Sample

Not really essential since it's easy enough to create yourself, but people wouldn't have to know/learn about the gapi.auth2 calls that way.

[atotic]

We had that in original implementation, but decided to take it out. The reasoning was that we were replicating gapi.auth2.getAuthInstance().currentUser.get().getBasicProfile().

It might come back in one day, I am counting your vote :)

Note to self, a nice way to do it would be:

basicProfile: {
    computed: 'getBasicProfile(signedIn)'
}

[ebidel]

I think we should provide this to uses. We ended up doing the exact same thing for the I/O web app. There's clearly a need for a computed property :)

[Scarygami]

As for "replicating": Isn't the main purpose of this element to replicate the behaviour of the gapi.auth2 methods, hiding the complexity of the actual calls? ;)

[ebidel]

+1. The whole point of these components is to smooth over API complexities.

[atotic]

Do we want to expose any additional information, such as getBasicInfo() if available?

[Scarygami]

I think just having the user information available (without having to call any extra methods) would be best. The BasicProfile object you get is a bit strange in JS terms, since you have to use get-Methods to get the actual values, a behavior that I would hide for the computed property to allow direct data binding, something like:

_computeUser: function (signedIn) {
  if (!signedIn) { return undefined; }
  var profile = gapi.auth2.getAuthInstance().currentUser.get().getBasicProfile();
  return {
    id: profile.getId(),
    name: profile.getName(),
    email: profile.getEmail(),
    imageUrl: profile.getImageUrl()
  };
}

getBasicProfile() could be undefined depending on the scopes used in which case only the id of the user would be available via gapi.auth2.getAuthInstance().currentUser.get().getId()

One extra thing that might make sense is to expose the AuthResponse object as computed property as well (gapi.auth2.getAuthInstance().currentUser.get().getAuthResponse()) in case people want to use the access_token / id_token directly outside of the JS client library.

[masonlouchart]

Some news about it? The _computeUser method proposed by @Scarygami could be "enough"?

[masonlouchart]

The feature shown by @ebidel at the Google I/O will be available soon or is still to be implemented ?

[ebidel]

Which feature? We didn't use anything new for sign in this year.

On Wed, May 25, 2016, 11:58 AM Mason Louchart [email protected] wrote:

The feature shown at the Google I/O https://www.youtube.com/watch?v=__KvYxcIIm8&feature=youtu.be&t=22m52s will be available soon or is still to be implemented ?

— You are receiving this because you modified the open/close state. Reply to this email directly or view it on GitHub https://github.com/GoogleWebComponents/google-signin/issues/98#issuecomment-221720573

[atotic]

The <google-signin> in the video has a user property. That's what this feature request is all about.