[web] implement PluginUtilities for flutter web

[jonahwilliams]

...or don't, maybe it doesn't make sense.

[amreniouinnovent]

@jonahwilliams I think if you added a suggested PluginUtilities List then the developers could vote on it

[goderbauer]

Related: #33614

@jonahwilliams @yjbanov Have you given it any thought if these APIs would be implementable on the web? They could help us with restoring anonymous routes. That problem is described in http://flutter.dev/go/restoring-anonymous-routes and PluginUtilities.getCallbackHandle / PluginUtilities.getCallbackFromHandle could be an alternative to Ephemerons to solve it.

For reference, the sub-problem that these APIs are solving for us is the following:

Given a static function we need to be able to obtain a serializable identifier for that function. And given that serializable identifier (in another instance of the app) we need to be able to re-obtain the original function object.

[jonahwilliams]

Anything involving isolates is not implementable on the web.

[goderbauer]

The API itself is independent of isolates as far as I can tell.

[jonahwilliams]

Depends on what you mean by implement - we could no-op it certainly, but we can't get handles to callbacks that can be shared across isolates.

[leafpetersen]

Under the assumptions that:

• the callback is a static function (not a closure)
• there isn't version skew between the serializing code and the deserializing code

I don't see any reason why it should be impossible to do what @goderbauer is looking for in JS. @sigmundch @rakudrama could possibly provide more accurate commentary.

Just because it's possible in principle though doesn't mean that it would just fall out of the current compilation strategy . But I actually think it might not be far off - you could use a class ID plus a static method name maybe?

[sigmundch]

Sorry for the very slow response here.

Is the expectation that the serialized id is usable within a single version of the app or across multiple versions? I don't see a reason why the former can't be supported, but the latter could be problematic.

Many teams consider the names of their methods internal and/or sensitive, so we wouldn't want to use the original class/method name as part of the serialized form. When we minify an application, the minified name would work, but that is not stable across multiple compilations of the program.

[goderbauer]

For my use case, the serialized id only has to be usable within a single version of the app.

[goderbauer]

/cc @mdebbar This is the missing API we talked about in the meeting the other day. I am using it to restore anonymous Routes (i.e. Routes pushed with push(Route route)).

[mdebbar]

This was an email thread between @goderbauer, @sigmundch and I (May 11th 2020):

@goderbauer:

Just to give some more context. I've implemented my use case (state restoration for Flutter) for mobile relying only on the functionality provided by PluginUtils.getCallbackHandle and its inverse PluginUtils.getCallbackFromHandle. I am using these to generate a serialized ID for static functions. Later, the serialized id is used to call that static function again. This all happens in the same version of the app.

That's the only functionality I need for my use case. I no longer need Empeherons or LookupMaps if we can make the callback handle thing work on the web.

@mdebbar the statement that state restoration only needs to work within the same version of the app is also correct on the web, right?

---

@mdebbar:

It depends on what "same version of the app" means. In production mode, I think it's clear what the same version means. But in development, what does it mean? Does it break every time I make a change and rebuild?

I understand that it's not desirable to ship visible class and method names to users. Can we make the ID a hash of the class+method names? That way it could still work across app versions as long as the class+method names haven't changed.

---

@goderbauer:

The mobile implementation does take a hash of (I think) library, class, and method name. In order to translate the hash back to the method, it stores a file with the hash<>method lookup table on disk. Where would we store that on the web?

---

@mdebbar:

The lookup table can be stored as part of the app code itself, but this means it has to contain all the possible static methods in the app.

Another way to do it would be at app startup when the dart sdk is creating all the prototypes and attaching methods, etc. And whenever a static method is attached to the prototype, its hash would also be added to the lookup table at runtime.

I'm not sure which approach would give us a smaller footprint.

Is there a solution that doesn't require a lookup table? I'm curious. Because I think regardless of whether the ID is a hash or a random number, there has to be a lookup table anyway.

---

@sigmundch:

I believe the main constraint for the web is minification. I don't believe this would be an issue during development with DDC, where we already use stable names across rebuilds to keep compilation modular. Even in dart2js, I believe it should be possible with -O1 (or --no-minify).

For deployment we don't want to preserve the original names because it can leak sensitive data (e.g. a method name can be the name of an unreleased feature). If the ID is a non-reversible unique hash derived from the original name, then they could potentially be stable. I do worry about collisions though.

[mdebbar]

@sigmundch @goderbauer is it possible to use the mobile approach on the web too (take a hash of library, class, and method name)? The lookup table can live in the Dart code as a const map.

I do worry about collisions though.

Mobile also suffers from collisions. Any idea how they are handling it? Or is mobile just not worried about collisions?

[goderbauer]

Mobile also suffers from collisions. Any idea how they are handling it? Or is mobile just not worried about collisions?

/cc @bkonyi, who implemented the mobile functionality, if I remember correctly.

[bkonyi]

Mobile also suffers from collisions. Any idea how they are handling it? Or is mobile just not worried about collisions?

/cc @bkonyi, who implemented the mobile functionality, if I remember correctly.

We just don't worry about collisions since the likelihood of there being a collision should be near zero, even if there's a double-digit number of entries.

[mdebbar]

@sigmundch is it possible to do the same on web and ignore hash collisions?

[sigmundch]

yes that sounds reasonable