Add hot reload capabilities to DartPad UI #3128
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This change integrates DDC hot reload into DartPad allowing for a faster iteration cycle and stateful reload.
The new reload workflow is currently limited to the main branch and only for Flutter applications. As the beta and stable branches of the SDK gain support for hot reload, we can expand this.
How it works:
This PR adds 2 new API entrypoints that invoke DDC with flags that produce JS using DDC's new module system. This new module system is what enables hot reload. Upon receiving the new code and loading them into the page as local blobs, the
hotReload
callback is invoked in the DDC embedder API. This triggers DDC to fetch the new file and reload the specified library, in this case the synthetic library created with the user's code. Once the hot reload is done, we trigger a reload event in Flutter via the 'reassemble' developer extension.Hot reload doesn't work for all changes, some changes require a full restart. DDC has the ability to diff the new code provided to it against the kernel of a previous compilation. If it detects an unsafe change it will error. In order to facilitate this diffing, DartPad needs to pass the dill file from the last generation of the code. I've extended the request/response model to include a base64 encoded string of the relevant dill file. The previous dill will get stored in memory on the client and attached to the next request. The dill file only includes the user code library (since that's the only thing that can change) and is therefore fairly small.
I've intentionally left the API for the "old" DDC invocation as-is so that the new version of the API is backwards compatible. This effectively adds 2 new endpoints which should be a safe operation.
In testing this I realized that the reload requests were fairly slow because a lot of libraries were getting included in each compilation. To fix this, I've updated the pre-compiled code (flutter_sdk.js/flutter_sdk.dill) to include all the libraries that are always needed. This cut compilation times from ~2000ms -> ~500ms.
See videos of full workflow with these changes:
Full DartPad Hot Reload demo.webm
DartPad Hot Reload Error.webm