Web Support

[navaronbracke]

The extension types language feature is scheduled to ship in Dart 3.3, which is the next stable release for Q1 2024. This is currently available on the Flutter beta channel.

The Gigya SDK provides a web implementation as defined here

Proposal

Add support to the gigya_flutter_plugin using this API so that the plugin also works on the web.
Preferably this is done using Dart's JavaScript interop, which is the new way of implementing web specific functionality for plugins.

Methods

• initSdk() Gigya Web SDK integration - make example start properly on the web #45
  • add cname argument to web platform interface, per cname argument missing in sdk.init call #71
  • handle network error when trying to load the SDK (intercept script.onError event & remove the script tag from the DOM)
• isLoggedIn() Gigya Web SDK integration - make example start properly on the web #45
• logout() Gigya Web SDK integration - make example start properly on the web #45
• addConnection() Gigya Web SDK integration - add / remove social connection #53
• finalizeRegistration() (only supported on the web?) Gigya Web SDK integration - registration #50
• forgotPassword() Gigya Web SDK integration - forgot password #64
• getAccount() Gigya Web SDK integration - get/set account info #52
• getSession()
• linkToSite()
• login() Gigya Web SDK integration - make example start properly on the web #45
  • Add the user's preferences and subscriptions to the account response where needed
• register() Gigya Web SDK integration - registration #50
  • Support accounts.resendVerificationCode
  • Support accounts.initRegistration for the lite accounts flow.
• removeConnection() Gigya Web SDK integration - add / remove social connection #53
• send() (not supported on the web?)
• setAccount() Gigya Web SDK integration - get/set account info #52
• setSession()
• showScreenSet() Gigya Web SDK integration - screen sets #54
• dismissScreenset() see f5b4314 for context
• socialLogin() Gigya Web SDK integration - social login #51
• sso()
• getJWT() (port for native using send("accounts.getJWT"))

Services

• InterruptionResolverFactory
• OtpService
• WebAuthenticationService

Other

• use the new package:web instead of dart:html for accessing the window and such
  • Bump package:web to version 0.5.0
• fixup the stub for Promise, which should have been a JSPromise from dart:js_interop
• fix the generic type for JSArray / JSPromise (fix has landed upstream in the Dart SDK)
• audit any missing thisArg arguments for callAsFunction() invocations (otherwise we'll run into type errors)
• Add missing const to empty list literals, const <Foo>[]
• Migrate existing bindings to extension types
  • We can also get rid of the helper class for the Response interop layer for our use case. The new extension types have access to the representation type. Thus we can have the 'overridden' methods redeclared, using the supertype for implementation purposes.
• Migrate to using the explicit Javascript types (JSObject, JSFunction, JSPromise once the interop API is further along) Primitive types are still allowed (int, double, null, bool, String) See https://github.com/dart-lang/sdk/blob/main/sdk/lib/js_interop/js_interop.dart
• Audit uses of // ignore_for_line / // ignore_for_file (There are 4~ uses, but these are needed to keep API variable names)
• Audit whether the web implementation forwards the error details (errorCode, errorMessage, errorDetails) to GigyaError()
• Remove exports in web/static_interop/response.dart
• Remove the WebErrorCode enum (it only has one usage in the Dart implementation of the Web SDK, which is not what I expected it to have. Keeping it around probably is not worth it)
• Run dart format on the web implementation sources (the formatter doesn't yet support extension types)
• Replace dart:js_util, package:js, and dart:js imports with dart:js_interop and dart:js_interop_unsafe, as the former is now unsupported in dart2wasm
• Replace uses of allowInterop(Function) with Function.toJS, as the latter is what the web compilers do for the Function type
• Remove the redundant @staticInterop and @anonymous annotations, these are not needed for extension types

Nice to have

• WASM support (see also the upcoming kIsWasm constant)
• Fix the manual is checks for JS types. On the JS backends (dart2js, DDC, dart2wasm) these checks will always succeed due to an implementation detail. Instead we should use the new isA<T extends JSAny>() function from dart:js_interop. This new function is only available in Dart 3.4, so it will have to wait a little.
• Support dynamically structured JS objects in the interop layer, using dartify()/ jsify() interop API's
  • context parameter
  • data parameter for get/set accountInfo
  • customButtons parameter (showScreenset)
  • customLang parameter (showScreenset)
  • Support global configuration, as defined here: https://help.sap.com/docs/SAP_CUSTOMER_DATA_CLOUD/8b8d6fffe113457094a17701f63e3d6a/415942c570b21014bbc5a10ce4041860.html
    • I think just documenting how to do this yourself is the better option, since initSdk() manually loads the Gigya script on-demand, which prevents uers from including the global config there. We should just tell users to add a <script> tag in the <head> of their index.html, which initializes window.__gigyaConf. We could also add a Dart API to set the configuration, but in my opinion this is not worth the effort.

[navaronbracke]

@tal-mi I wanted to ask if getting this implemented is still on your radar? As this is adding support for a new platform, I don't think it is high priority, but it would be nice to see this getting further along slowly.

[navaronbracke]

As the inline-class feature has been renamed to extension types, I might hold off on implementing the web specific part of the platform interface. Once we get extension types as a feature (and JS interop supports it), I'll revisit my work here, so that we can migrate to extension types in one go.

I've put what I have already on-hold for now. I'll get in touch with the language team on a timeline for the extension types.

We could also decide to work on the implementation right now, and migrate to extension types once the JS interop API's require us to do so.

[navaronbracke]

FYI: I have finished migrating the Web implementation parts to extension types. Now we wait for that feature to land in a stable release. (Which if I look at the timeline might be at the end of this year, with a Dart 3.3.0 stable release, as 3.2.0 is a dev release)

As the extension type feature specification has been accepted and has had some work done in the analyzer / Common Front-End, I have started migrating the bindings that I already wrote into extension types.

This way I can already try to validate the new bindings. Once the feature has shipped into a Dart stable release, I will bump the minimum Dart version of the plugin accordingly.

Ref: https://github.com/dart-lang/language/blob/main/accepted/future-releases/extension-types/feature-specification.md

[navaronbracke]

@tal-mi Flutter 3.19.0 and Dart 3.3 are available on stable as of today. We can start bringing web support to customers on the stable branch.