schultek
[Question] Which one does Jaspr support: "Hot Restart" or "Hot Reload"?
From jaspr serve -h
Runs a development server that serves the web app with SSR and reloads based on file system updates.
Usage: jaspr serve [arguments]
-h, --help Print this usage information.
-i, --input Specify the input file for the web app.
-m, --mode Sets the reload/refresh mode.
[refresh] (default) Performs a full page refresh and server reload
[reload] Reloads js modules without server reload (loses current state)
This relates to the --auto option from webdev. Hot-reload is currently not stateful because of this. I haven't had the time to check if it can be made stateful somehow.
Do you have any insights for this? How does dawn work?
Thanks for the explanation. As I've played around with webdev, I've noticed that in the JavaScript environment, unlike the Dart VM, the top-level Dart variables that contain the state are reinitialized during the reload. But that is not the case for variables attached to the window.
Example:
// after each reload, our state is lost.
int count = 0; // assume that it's incremented after some clicks in the app.
import 'package:js/js.dart';
// after each reload, our state is maintained.
@JS()
external int count; // assume that it's later initialized and incremented after some clicks in the app.
Maybe we can achieve a stateful hot reload with this approach.
But the next issue is that runtimeType's identity is changed after each hot reload in the JavaScript environment (this is not an issue in Dart VM). Thus, when runtimeType is checked in the diffing process, our widget tree gets replaced instead of updated, and therefore State<T> is lost.
With all that said, if Dart had behaved the same in the JavaScript environment and the Dart VM, Dawn and Jaspr could support a stateful hot reload by default.
After all, it is possible to implement a stateful hot reload since Vue has done it.
Cool, thanks for this. I will try it out a bit, although the runtimeType issue might become a problem but let's see.