Google+ Sign-In: Page Level Configuration
On Monday the Google+ Javascript SDK team announced the release of a number of enhancements to the sign-in SDK on the web. These are all things that have either been directly requested by developers, or were created in response to something that developers have asked for, but I wanted to go into a bit more depth on one of the more subtle, but also very useful, changes.
The feature is the combination of the page level configuration and the dynamic sign in callback. This simplify managing configuration for a page, makes managing sign-in state easier, and generally provide a much better feel for the user.
Page Level Config
The biggest change is moving configuration information from either HTML data- attributes or Javascript options to meta data on the page itself. This means that you won’t run into a problem of having one button configured with scopes A and B, but another with just A (which can lead to confusing situations), or miss out some app activity types. The configuration is supplied as meta tags with names constructed from google-signin- + the option, e.g. clientid.
As you can see this allows you to define the callback as well, so you really don’t need to pass any options to a sign-in button:
<div class=“g-signin”></div>
Dynamic Sign-In Callback
This is the one that really improves the experience for me though. One of the general problems developers faced was how to trigger an immediate mode check. If you display the sign-in button, then it can be there for a while before the check has completed, which looks a bit odd to a returning user. The normal method was to hide the sign-in button off screen until the check had been completed. With this change, the callback will fire on initial page load.
On top of that, it also tracks the sign-in state of the user. Try visiting the example page in an incognito window, sign-in, and then in another tab sign out of Google. You'll see an error immediate_failed_user_logged_out. The reverse would happen if you signed-in using the same browser instance, and had previously granted access. Very cool!
This means we can drive behaviour directly from the callback, which actually makes the code simpler. Here we are just checking the state and displaying the appropriate buttons. We don’t need to worry too much about whether the user is signed-out, not logged in to Google, automatically signed-in or manually signed in. Just as an example, we’ll tweak the message depending on whether they consented or were seamlessly signed-in.
The important thing to note in the callback is that we’re not triggering this by creating the button - we only call gapi.render when we have a confirmed signed-out state, so our flow is much more cleanly encapsulated.
