Skip to content

fix(web): fix some casting issue on Web JS Interop #12852

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
May 30, 2024
Merged

fix(web): fix some casting issue on Web JS Interop #12852

merged 2 commits into from
May 30, 2024

Conversation

Lyokone
Copy link
Contributor

@Lyokone Lyokone commented May 30, 2024

Description

Replace this paragraph with a description of what this PR is doing. If you're modifying existing behavior, describe the existing behavior, how this PR is changing it, and what motivated the change.

Related Issues

fixes #12820

Checklist

Before you create this PR confirm that it meets all requirements listed below by checking the relevant checkboxes ([x]).
This will ensure a smooth and quick review process. Updating the pubspec.yaml and changelogs is not required.

  • I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • My PR includes unit or integration tests for all changed/updated/fixed behaviors (See Contributor Guide).
  • All existing and new tests are passing.
  • I updated/added relevant documentation (doc comments with ///).
  • The analyzer (melos run analyze) does not report any problems on my PR.
  • I read and followed the Flutter Style Guide.
  • I signed the CLA.
  • I am willing to follow-up on review comments in a timely manner.

Breaking Change

Does your PR require plugin users to manually update their apps to accommodate your change?

  • Yes, this is a breaking change.
  • No, this is not a breaking change.

@Lyokone Lyokone merged commit 4b56df1 into master May 30, 2024
18 of 23 checks passed
@Lyokone Lyokone deleted the fix/12820 branch May 30, 2024 08:47
if (value is JSObject &&
value.instanceof(GeoPointConstructor as JSFunction)) {
return GeoPoint((value as GeoPointJsImpl).latitude.toDartDouble,
(value as GeoPointJsImpl).longitude.toDartDouble);
} else if (value is DateTime) {
return Timestamp.fromDate(value);
// Cannot be done with Dart 3.2 constraints
// ignore: invalid_runtime_check_with_js_interop_types
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But this is invalid code, I think! Runtime behavior will be wrong w/ wasm!

Copy link

@srujzs srujzs May 30, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Drive-by comment:

It looks like both Dart values and JS values flow to value. In this case, I'd recommend checking all the Dart values first (is DateTime, etc.). After that, I'd cast value to a JSAny?, and then do isA checks with the resulting JSAny?. As an example:

if (value is DateTime) {
  ...
} else {
  // Note that if value is still a Dart value, this cast is unsafe, so check all the Dart values first.
  final jsValue = value as JSAny?;
  if (jsValue.isA<GeoPointJsImpl>()) {
    ...
  } else if (jsValue.isA<JSArray>()) {
    List<JSAny?> list = (jsValue as JSArray).toDart;
    ...
  }
}

It also looks like there's a check against List<dynamic>. If value here is actually a JS array, use isA<JSArray>, as is List<dynamic> may be true when compiling to JS, but false when compiling to Wasm. The general guidance is that if a value is a JS value, use interop to type-check it and not Dart is checks.

@firebase firebase locked and limited conversation to collaborators Jul 9, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[FirebaseRemoteConfig]: Wasm build crashes on fetchAndActivate()
6 participants