This PR is now out of date

---

But not abandoned; work on this feature continues in:

• [web] webOnlyWarmupEngine + js-interop APIs engine#32017
• [web] flutter.js initialization with ui.webOnlyWarmupEngine #100177

---

Old description

This is a first attempt at yielding full control to the programmer over the initialization of a Flutter Web app.

Currently, Flutter Web apps start as soon as possible, and take over the whole screen. With this change, the startup of an App can be split in three stages (four, if we count the cleanup stage too):

• Injecting the serviceworker/main.dart.js
• Initializing the engine
• Running the flutter app
• Cleaning the app (currently not implemented)

To achieve this, some JS-interop and Promise-wrangling is needed. The new workflow is as follows:

• The user injects flutter.js in their index.html, and once that script is loaded, calls _flutter.loader.loadMainDartJs
• flutter.js injects main.dart.js, and sets up a _flutter.loader.didLoadMainDartJs callback. (This callback must be in a known location, because the first time Flutter calls JS, it needs to do so from a known place.)
• The Dart wrapper script detects that the _flutter.loader has been used in JS, and sets up a FlutterLoader object that controls de lifecycle of the app.
• The FlutterLoader calls didLoadMainDartJs in JS, with an instance of an EngineInitializer.
  • This resolves the promise returned by loadMainDartJs in step 1.
• From this moment on, the loading of the application is a sequence of Promise-based objects that let the user walk through the three (four) stages described above:

loadMainDartJs -> EngineInitializer.initializeEngine -> AppRunner.runApp -> AppCleaner.cleanApp (optional)

The new API above allows users to write their own (informative) splash screens, for example:

• https://dit-tests.web.app (the red circles should turn green as the app loads, and the button becomes enabled once the app is ready to start. The app only starts when the button is pressed).

Backwards compatibility

This will be backwards compatible with old versions of index.html, but testing that hasn't been a priority of this first PoC.

Testing

No tests yet, but I've tried to minimize the amount of code living in "untestable" parts of the app (template files, and build scripts), and add as much as possible into flutter_web_plugins, where it's somewhat testable.

(Tests are probably failing now)

This is a WIP/RFC/Draft PR, so for now, there's no issues/checklist.

Manual testing

Clone this branch into your flutter/flutter fork, and ensure that your flutter binary is the one coming from your Github checkout.

With the new version of flutter on your box, you'll be able to create a new app normally by using flutter create. That should come with the new flutter.js and index.html templates.

In order to get the see any changes you make in your test app that you just created, you'll need to add this to its pubspec.yaml:

dependency_overrides:
  flutter_web_plugins:
    path: /usr/local/google/home/dit/github/flutter/packages/flutter_web_plugins

And then be pretty nuclear with rebuilding your flutter tool. In my case, I've ended up using:

rm -fr web && flutter create . && flutter clean && rm ~/github/flutter/bin/cache/flutter_tools.* && flutter run -d chrome

To ensure that changes in every type of file (dependency, template, application...) are applied at once. YMMV here.