Pass hot reload/hot restart callbacks and reload sources path to StrategyProviders instead
Closed this issue · 3 comments
Currently, with hot restart, we call a developer extension method to disassemble the Flutter engine after we've successfully hot restarted the application. This allows the Flutter engine to restart state.
As we add hot reload, we're doing something similar: reassembling the Flutter engine so that it renders a new frame after a hot reload.
Similarly, we assume there exists a path in the global window that the injected client can request to find the paths that have changed for a hot reload.
This would also help analytics determine the cost of reload vs reassemble.
These are all implicit assumptions that are tied to Flutter tools. We should avoid this and instead have the providers take several options:
- One for developer extensions (including args) that need to be called after a hot restart (note that DWDS must do this as it is able to evaluate JS expressions, where Flutter tools does not).
- One for developer extensions (including args) that need to be called after a hot reload, like
reassemble. - One for the reload sources path that DWDS fetches from.
Actually, the vm service has a hook to invoke a service extension (specifically reassemble). Perhaps we should use that instead and use more of the run_hot.dart implementation in general.
A consideration on moving reassemble to Flutter tools instead of DWDS: it may come across a race condition where files are reloaded and execution continues, but the UI hasn't been updated yet.
Since reassemble is asynchronous, this is unavoidable. We can't execute it in the debugger while the program is paused because it is asynchronous, and waiting for a Promise outside of the debugger (and therefore, not paused) may continue executing user code first.
This is done - there's an option for reload sources and reassemble is called in Flutter tools as well as DWDS doesn't need to call it itself.