Extending Oracle JET with Google Sign-In is hard — here’s how to do it

Don’t panic, we’ll tell you how it’s done!

We’ve got an Oracle JET application here at enpit that allows us to quickly capture and submit travel expenses. The other day we wanted to integrate a simple login mechanism to our application. No one wants to force the user with another username-password combination to remember, so we quickly decided to use Google Sign-In. Their guide is pretty comprehensive, so it shouldn’t be too hard, right? Wrong.

How not to do it

Here’s the code snippet from that guide I mentioned, alongside the typical Oracle JET RequireJS call:

What happens is that Google’s API magically transforms the div element with the g-signin2 class into a login button. When the user completes the sign-in process, the onSignIn function gets called. It looks fairly simple and actually works like a charm. But what if you actually need the user’s data for more than just logging it? Chances are you want to store it in one of your ViewModels and/or use it for making calls to your webservice. Then this approach gets you nowhere, as the onSignIn function lives outside the scope of RequireJS and your Knockout view models (plus it clutters the global namespace which is almost never a good idea).

How not to do it either

Folks who have some experience in JET will know what to do in order to introduce the onSignIn function to RequireJS: Create a new RequireJS module and a corresponding HTML template. In the module, create a Knockout view model and attach the onSignIn function to self. As anyone who is not that familiar with JET may be a bit confused now, here’s the code:

One problem is that the sign-in button does not know the onSignIn function anymore. You can fix this by attaching that function to the window object (like I already did in line 13 in the above example). This allows you to store the user data in your ViewModel and share it with other models. However, there are still three problems left here:

1. The onSignIn function is leaked to the global window object once again, and it is kind of an ugly workaround.
2. In JET, you normally use RequireJS and Bower to manage and load your dependencies (such as Knockout, Hammer etc.). Loading an additional external dependency via a script tag in the HTML header is at the very least a code smell here.
3. The sign-in button does not adhere to the Alta UI look & feel (which may or may not be a problem for you and your application).

How to do it

This attaches the correct click handler to the button programmatically, so no references are leaked to the window object. As the button is defined as an ojButton component, it is styled as all the other buttons in your application. And more importantly, RequireJS is used for loading the script, just as in the rest of your JET application (at least I hope so!).

“But wait, what about using bower for loading the dependencies!” you might think, and you are right. The correct way to load the Google Sign-In API would be to add an entry to your bower.json, copy it into your libs directory via Grunt and then finally load it in the define call of the corresponding ViewModel. This was left out to make the example as concise and comprehensible as possible (and these details concerning the build process of a JET application fall out of the scope of this article).

TL;DR For integrating the Google Sign-In API into an Oracle JET application, make sure to:

• use an ojButton component for the button
• load the API script via RequireJS, not a script tag in the HTML
• attach the click handler in your ViewModel in order to be able to store and share the user data in the models variables

Want to learn more about this and more topics about building Oracle JET applications? Make sure to sign up for the workshop that Andreas Koop and I will run at this year’s DOAG conference in Nürnberg (it’s in german though)!

More information on Oracle JET

• Getting Started: http://www.oraclejet.org
• Collection of Oracle JET Resources (german): http://www.enpit.de/jet