-
Notifications
You must be signed in to change notification settings - Fork 567
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add hot reload capabilities to DartPad UI #3128
Conversation
PR HealthBreaking changes ✔️
Changelog Entry ✔️
Changes to files need to be accounted for in their respective changelogs. Coverage ✔️
This check for test coverage is informational (issues shown here will not fail the PR). API leaks ✔️The following packages contain symbols visible in the public API, but not exported by the library. Export these symbols or remove them from your publicly visible API.
License Headers ✔️
All source files should start with a license header. Unrelated files missing license headers
|
Has the code landed in
Here's my SDK version:
|
The prerequisite change landed in the Dart SDK yesterday but a Dart roll has not happened into the Flutter SDK yet. We're trying to push one through today. Once that happens it'll be available on the main Flutter channel. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM - let's not land this yet until we're ready.
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