Moving from @staticInterop type to interop extension type leads to an extra apply call

[srujzs]

Compiling this:

import 'dart:js_interop';

import 'dart:html' as html;

@JS()
@staticInterop
class Node {}

extension NodeExtension on Node {
  external Node removeChild(Node child);
  external Node? get parentNode;
}

/*
@JS()
extension type Node._(JSObject _) {
  external Node removeChild(Node child);
  external Node? get parentNode;
}
*/

void main() {
  final nodes = html.window.document.nodes;
  final node = nodes[0] as Node;
  node.parentNode?.removeChild(node);
}

leads to:

    main() {
      var node,
        t1 = window.document.childNodes;
      if (0 >= t1.length)
        return A.ioore(t1, 0);
      node = t1[0];
      t1 = type$.nullable_JavaScriptObject._as(node.parentNode);
      if (t1 != null)
        type$.JavaScriptObject._as(t1.removeChild(node));
    },

Replacing the @staticInterop definition with the interop extension type results in this:

    main() {
      var node,
        t1 = window.document.childNodes;
      if (0 >= t1.length)
        return A.ioore(t1, 0);
      node = t1[0];
      t1 = type$.nullable_JSObject._as(node.parentNode);
      if (t1 != null)
        type$.JSObject._as(t1.removeChild.apply(t1, [node]));
    }

where the difference is that instead of directly calling removeChild(node), we're now doing a removeChild.apply(t1, [node]). It isn't clear why this is the case - the only real functional difference that I can tell is that one is a JavaScriptObject (the @staticInterop type), while the other is a JSObject. Erasing @staticInterop types as JSObject doesn't result in the longer call either, so there must be something else here.

cc @leonsenft

[leonsenft]

Is this only because we're using nodes from dart:html? Is apply() not used if we use package:web instead?

[srujzs]

That's a good question - I can't quite get the equivalent code, but this is good enough:

import 'dart:js_interop';

@JS()
external Window get window;

@JS()
@staticInterop
class Window {}

extension WindowExtension on Window {
  external Node get document;
}

@JS()
@staticInterop
class Node {}

extension NodeExtension on Node {
  external Node removeChild(Node child);
  external Node? get parentNode;
  external Node get firstChild;
}

/*
extension type Window._(JSObject _) {
  external Node get document;
}

@JS()
extension type Node._(JSObject _) {
  external Node removeChild(Node child);
  external Node? get parentNode;
  external Node get firstChild;
}
*/

void main() {
  final node = window.document.firstChild;
  node.parentNode?.removeChild(node);
}

With @staticInterop:

    main() {
      var t1 = type$.JavaScriptObject,
        node = t1._as(t1._as(t1._as(self.window).document).firstChild),
        t2 = type$.nullable_JavaScriptObject._as(node.parentNode);
      if (t2 != null)
        t1._as(t2.removeChild(node));
    },

With interop extension types:

    main() {
      var t1 = type$.JSObject,
        node = t1._as(t1._as(t1._as(self.window).document).firstChild),
        t2 = type$.nullable_JSObject._as(node.parentNode);
      if (t2 != null)
        t1._as(t2.removeChild.apply(t2, [node]));
    }

So it seems like the answer is no, this is not because of dart:html. I'll update the title to reflect that.

[sigmundch]

Interesting.

A couple thoughts. By default external methods are lowed to callMethod (from js_util, maybe we should change that to use js_interop_unsafe in the future). Then callMethod can be lowered even further to use callMethodUnchecked0 in certain cases.

Tweaking your example a bit:

import 'dart:js_interop';

@JS()
external A get a;

@JS()
@staticInterop
class A {}

extension Ax on A {
  external A m1(A? child);
}

@JS()
external B get b;

extension type B._(JSObject o) {
  external B m2(B? child);
}

extension Bx on B {
  external B m3(B? child);
}

main() {
  a.m1(a);
  b.m2(b);
  b.m3(b);
}

We generate the direct call to m1, but the apply call to m2 and m3. So I don't believe this is because of how the members are declared themselves, but more likely because of criteria we use to decide whether the extra lowering is permitted (e.g. whether the inputs to the method are safe to bypass the assertInterop check).