Open navaronbracke opened 1 year ago
@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.
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.
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.
@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.
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
cname
argument to web platform interface, per https://github.com/SAP/gigya-flutter-plugin/issues/71send("accounts.getJWT")
)Services
InterruptionResolverFactory
OtpService
WebAuthenticationService
Other
package:web
instead ofdart:html
for accessing the window and suchJSPromise
from dart:js_interopthisArg
arguments forcallAsFunction()
invocations (otherwise we'll run into type errors)const
to empty list literals,const <Foo>[]
extension type
sResponse
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.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// ignore_for_line
/// ignore_for_file
(There are 4~ uses, but these are needed to keep API variable names)GigyaError()
web/static_interop/response.dart
dart format
on the web implementation sources (the formatter doesn't yet support extension types)dart:js_util
,package:js
, anddart:js
imports withdart:js_interop
anddart:js_interop_unsafe
, as the former is now unsupported in dart2wasmallowInterop(Function)
withFunction.toJS
, as the latter is what the web compilers do for theFunction
type@staticInterop
and@anonymous
annotations, these are not needed for extension typesNice to have
kIsWasm
constant)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 newisA<T extends JSAny>()
function fromdart:js_interop
. This new function is only available in Dart 3.4, so it will have to wait a little.dartify()
/jsify()
interop API'scontext
parameterdata
parameter for get/set accountInfocustomButtons
parameter (showScreenset)customLang
parameter (showScreenset)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 initializeswindow.__gigyaConf
. We could also add a Dart API to set the configuration, but in my opinion this is not worth the effort.