Dart and Flutter applications can be compiled with deferred loading.
For Dart standalone, the VM in AOT, and dart2js support deferred loading by compiling into separate "loading units".
The resources information from @ResourceIdentifier or @pragma('dart2js:resource-identifier') is organized via loading units as well.
In Flutter (for Android and web), multiple "loading units" can be assigned to a "deferred component" manually. Also assets are assigned to deferred components manually. https://docs.flutter.dev/perf/deferred-components
The question is how we should treat native code assets, wasm assets, and data assets with regards to applications being split up at runtime in multiple loading units // deferred components.
Communication from build and link hooks to Dart/Flutter
Does the Flutter embedder have enough information to put dynamic libraries and data assets in the right "deferred component" in Flutter automatically?
Do dart2js have enough information to put any wasm assets or data assets (read as bytes). In the right place? Is there even such thing as the right place? Or is anything loaded as HTTP requests as separate files anyway?
If the above answers are that embedders need not be supplied with information from users, then we can omit mentioning loading units (and deferred components) in the native_assets_cli Config/Output and protocol.
(If we want parity between data assets in the flutter pubspec.yaml and the native assets CLI, then we do need to output deferred components. But of course those don't say anything for Dart standalone, because there is no such concept in Dart. Dart only knows about "loading units" which are automatic.)
Communication from Dart/Flutter to build and link hooks
When running build / link hooks, would it be useful to know in what loading unit (and/or deferred component) assets are used?
Since the Dart code accessing the asset is fixed, splitting an asset up in multiple parts per bundle wouldn't work. If the asset is split up into two (or more) parts, one might as well use different asset IDs in the first place.
Maybe a bigger question is whether once we start adding data assets to dart2js (which is currently the only used dart standalone configuration with deferred loading), whether we need to add a concept of "deferred components" as well, or whether "loading units" is the right abstraction.
Dart and Flutter applications can be compiled with deferred loading.
For Dart standalone, the VM in AOT, and dart2js support deferred loading by compiling into separate "loading units". The resources information from
@ResourceIdentifieror@pragma('dart2js:resource-identifier')is organized via loading units as well.In Flutter (for Android and web), multiple "loading units" can be assigned to a "deferred component" manually. Also assets are assigned to deferred components manually. https://docs.flutter.dev/perf/deferred-components
The question is how we should treat native code assets, wasm assets, and data assets with regards to applications being split up at runtime in multiple loading units // deferred components.
Communication from build and link hooks to Dart/Flutter
If the above answers are that embedders need not be supplied with information from users, then we can omit mentioning loading units (and deferred components) in the native_assets_cli Config/Output and protocol.
(If we want parity between data assets in the flutter pubspec.yaml and the native assets CLI, then we do need to output deferred components. But of course those don't say anything for Dart standalone, because there is no such concept in Dart. Dart only knows about "loading units" which are automatic.)
Communication from Dart/Flutter to build and link hooks
When running build / link hooks, would it be useful to know in what loading unit (and/or deferred component) assets are used?
Since the Dart code accessing the asset is fixed, splitting an asset up in multiple parts per bundle wouldn't work. If the asset is split up into two (or more) parts, one might as well use different asset IDs in the first place.
Side note: The current
dart:API (https://dart-review.googlesource.com/c/sdk/+/351140/6/sdk/lib/ffi/assets.dart) does have no concept about deferred loading. So this might not work with deferred loading.Bigger questions
Maybe a bigger question is whether once we start adding data assets to dart2js (which is currently the only used dart standalone configuration with deferred loading), whether we need to add a concept of "deferred components" as well, or whether "loading units" is the right abstraction.