[dwds] Implement hot reload and publish 24.3.4 #2583
Conversation
- Modifies the Chrome proxy service to call a callback that the injected client has setup in order to do a hot reload. - This callback forwards to the restarter. - This restarter reads from a path that Flutter tools sets up beforehand in order to fetch the changed sources and their associated libraries. - Issues a hot reload to DDC using that data. - Reassembles the Flutter engine to render a frame if the extension exists. - Returns a ReloadReport on whether or not this operation succeeded.
| import 'dart:js_interop'; | ||
|
|
||
| import 'restarter.dart'; | ||
|
|
||
| @JS('dartDevEmbedder') | ||
| external _DartDevEmbedder get _dartDevEmbedder; | ||
|
|
||
| // Flutter tools should set this path up before a hot reload. | ||
| @JS('\$reloadScriptsPath') | ||
| external String get _reloadScriptsPath; |
There was a problem hiding this comment.
@nshahan I know we talked about potentially forwarding this to the strategy provider, but I think the plumbing may be uglier than this. It'll need to be passed to the injected client upon creation, and the injected client should know that this arg should only matter for the DDC library bundle restarter. It is doable though if we want to go down that route.
There was a problem hiding this comment.
Actually, I'm gonna reverse course a bit here: #2584.
It'll be a good amount of plumbing, but it's worth it to decouple IMO.
| _logger.info('\$dartHotReloadDwds request complete.'); | ||
| } catch (e) { | ||
| // TODO(srujzs): We should bubble up the error, but `ReloadReport` needs | ||
| // more fields to capture that info. |
There was a problem hiding this comment.
Just FYI the VM does already encode the reason into the reload report payload. We extract it in our testing framework here:
https://github.com/dart-lang/sdk/blob/6e17841614ed095168314c48a60ebc0db1539aac/pkg/reload_test/lib/src/_vm_reload_utils.dart#L173-L189
There was a problem hiding this comment.
I ended up adding a subclass for ReloadReport because it looks like we call toJson, and the implementation in ReloadReport only ever returns the type and success. Without this, it ended up erasing any of the notices we have to Flutter tools.
There was a problem hiding this comment.
LGTM overall!
My only question is whether or not we should be explicitly referencing Flutter service extensions from DWDS instead of providing some sort of callback to the Flutter Tool so it can issue the service extension request itself.
Ideally we'd keep DWDS as target agnostic as possible and avoid adding Flutter specific logic (although I'm fairly certain we haven't been consistent on this front historically).
| @@ -25,6 +34,30 @@ extension type _Debugger._(JSObject _) implements JSObject { | |||
| await invokeExtension(method, '{}').toDart; | |||
| } | |||
| } | |||
|
|
|||
| Future<void> maybeInvokeFlutterReassemble() async { | |||
There was a problem hiding this comment.
Does this belong here or in the Flutter Tool?
There was a problem hiding this comment.
We do need to invoke the developer extension here, but which ones should be up to Flutter tools.
I filed #2584 to register developer extensions in the provider as well as register the reload sources path. I'll work on that after getting this and the hot reload PR in Flutter tools landed and release a new version afterwards to integrate with.
There was a problem hiding this comment.
I take it back! :)
I forgot we can invoke extensions directly within Flutter tools. #2585. I'll wait until this lands to publish.
The ReloadReport gets jsonified using `toJson` so we need a custom class to override it so that `toJson` includes all the things we need to transmit errors.
cc @jyameo