feat: Google Sign In button component

[jfmcquade]

PR Checklist

• PR title descriptive (can be used in release notes)

Description

Adds a new component: google_sign_in_button. This component has no exposed parameters, it's value will displayed as the test on the button.

On click, the button automatically triggers the equivalent of the auth: sign_in_google action. Additional actions can be authored as usual, e.g. click | emit: force_reprocess, and these will be triggered after the sign in logic completes, see example below.

This applies styling according to Google's strict guidelines for such a button – including rendering the Google logo inline.

Google's docs offer multiple styles (light/neutral/dark themes, pill/rectangular shape). Whilst we could expose options to customise these to authors, for now I've opted to just support the light/pill style. As the Google branded styling doesn't match our theming anyway, I don't think it's crucial to expose these options, and the "light" themed button is the most flexible for different applications (the border means it looks good on all background colours).

Git Issues

Closes #2774

Screenshots/Videos

comp_google_sign_in_button:

button_google_sign_in.demo.mov

[esmeetewinkel]

Thanks! Looking good in RTL (broken record...)

It seems that Google's styles don't properly adapt to Arabic / RTL, see https://developers.google.com/identity/branding-guidelines?hl=ar
and neither does the button when displayed in the app.

One other comment is that the button doesn't amend well to long text strings (they just run off the page rather than wrapping and the button height increasing). However, I think we can accept this, since Google only allows very particular text strings to appear on this button anyway and trying a few languages I couldn't find any where these strings were so long that they would need wrapping on a screen size of 360px.

[jfmcquade]

Thanks for testing, @esmeetewinkel (I'll get back into the swing of remembering RTL...). Seeing as I used the exact code Google share, I can imagine that readers of RTL languages probably encounter this wrongly styled button regularly...

Your code suggestion is spot-on, I've updated with these commits and it should now display like this:

As for the long text string issue, I'm inclined to agree that we don't need to handle long text strings, and can restrict ourselves to Google's suggestions (including the shorter versions if necessary). Obviously it would be possible to configure the variant to handle longer strings, but seeing as currently the styling is just lifted wholesale from Google, it's probably not worth fiddling with it unless we have a real use case.

[esmeetewinkel]

Functional test passed

[chrismclarke]

Thanks @jfmcquade

I'm not sure I can quite see in the code how the custom text is included in the component, however I think actually we don't want to include custom text. The strict guidelines you referred to are quite explicit

To encourage users to click the button, we recommend the call-to-action text "Sign in with Google", "Sign up with Google", or "Continue with Google". It should be clear to the user that they are signing into your app or signing up for your app with their Google credentials, not signing up or registering for a Google account on your app.

So I think we should stick to a single "Sign in with Google" and find a sensible way to mark within translations (not sure how we currently mark hardcoded strings for translation)

[chrismclarke]

nit(blocking): Given that the google_sign_in button has very specific behaviour I think it would be best if not included in default button component as a variant, but instead be it's own standalone component, e.g. google_sign_in_button. I can see most of the code you have already put in it's own file, but I think probably best not including in the base button component at all

Longer term we would likely plan around feature modules also registering their own components (like modules do), and so likely this would be something like an auth_google_sign_in_button component, although I think keeping as google_sign_in is still fine. It should by default include the action to sign in with google, and any user-defined action_list could be triggered after

[jfmcquade]

Thanks, @chrismclarke, I've added 3c7a79f which makes the following changes:

• The button is now a standalone component, with author reference google_sign_in_button
• The button is now hardcoded to trigger the logic to sign in with Google on click. Any authored click actions will be triggered afterwards (FAO @esmeetewinkel)

I've updated the PR description accordingly.

In terms of the displayed text on the button, @esmeetewinkel and I discussed this morning and thought it would make sense to keep this as a directly author-able value.

For one thing, I don't think we do have a good system for handling translations of hardcoded strings: we have strings like "Next", "Previous" and "Done" in the tour service, see

open-app-builder/src/app/feature/tour/tour.service.ts

Line 55 in f8d523b

nextLabel: this.translateService.translateValue("Next"),

, which I believe are just manually added to the translation inputs to ensure a translation exists; then there's https://github.com/IDEMSInternational/open-app-builder/blob/master/packages/data-models/app-config/globals.ts, which contains global hardcoded strings but is not integrated into the translation system (and hasn't been updated since 2022).

In any case, we thought that the authoring flexibility is desirable: it may be that we wish to have a longer or shorter text string displayed and these may vary by language (indeed, the direct translation of one string may be longer in another language). Potentially we could expose a variety of hardcoded messages via a param (e.g. text: call_to_action_1 or text: call_to_action_short), but I think it's more straightforward to keep the text as directly authorable via the component row value.

[chrismclarke]

In terms of the displayed text on the button, @esmeetewinkel and I discussed this morning and thought it would make sense to keep this as a directly author-able value.

For one thing, I don't think we do have a good system for handling translations of hardcoded strings: we have strings like "Next", "Previous" and "Done" in the tour service, see

open-app-builder/src/app/feature/tour/tour.service.ts

Line 55 in f8d523b

nextLabel: this.translateService.translateValue("Next"),

, which I believe are just manually added to the translation inputs to ensure a translation exists; then there's https://github.com/IDEMSInternational/open-app-builder/blob/master/packages/data-models/app-config/globals.ts, which contains global hardcoded strings but is not integrated into the translation system (and hasn't been updated since 2022).

I can see a limited number of strings in packages\data-models\app-config\globals.ts which are renamed to as APP_STRINGS in packages\data-models\appConfig.ts. It would be good to create a follow-up issue to decide on how we want to manage in the future for integrated into translation workflows, but I think for now having the link to google text recommendations on the comp example you've added seems reasonable to me

[chrismclarke]

Thanks for the updates @jfmcquade , looks good to me

[jfmcquade]

I can see a limited number of strings in packages\data-models\app-config\globals.ts which are renamed to as APP_STRINGS in packages\data-models\appConfig.ts. It would be good to create a follow-up issue to decide on how we want to manage in the future for integrated into translation workflows, but I think for now having the link to google text recommendations on the comp example you've added seems reasonable to me

Thanks, I've made a follow-up issue here: #2797