Version 0.21.0

1. Build Method Improvement

All component build methods now return a single Component instead of an Iterable<Component>. This includes:

• The build() methods of StatelessComponent and StatefulComponents State:

  @override
  Iterable<Component> build(BuildContext context) sync* { 
    yield ... 
  Component build(BuildContext context) { 
    return ... 
  }
  

• The build() method of AsyncStatelessComponent:

  Stream<Component> build(BuildContext context) async* { 
    yield ... 
  Future<Component> build(BuildContext context) async { 
    return ... 
  }
  

• The builder parameter of Builder, ListenableBuilder, FutureBuilder, StreamBuilder and AsyncBuilder, e.g.:

  return Builder(
    builder: (context) sync* { 
      yield ... 
    builder: (context) { 
      return ... 
    }
  );
  

Migration

In case you need to manually migrate single components to the new build method, migrating is straightforward and in most cases trivial:

1. Change the method signature to Component build(BuildContext context) for normal components/builders, and Future<Component> build(BuildContext context) for async components/builders.
2. For build methods yielding a single child, simply remove the sync* modifier and return that child intead.
3. For build methods yielding multiple children, return a Fragment and provide the children as a List<Component>.

Reason for the Change

We noticed that in practice, most components already only return/yield a single child component. For those components, changing to a single child build method is the natural choice.

Additionally, this change allows to discontinue the special sync*/yield syntax used before and instead aligns more closely with Flutter's widget syntax. And while this syntax is not officially deprecated, it is not really recommended by the Dart team as it lacks certain performance optimizations (especially for js compilation) and doesn't support newer language features (e.g. no null-aware yield).

Lastly, changing to single-child components allowed for major simplifications and optimizations of the internal framework code of Jaspr, resulting in a less-complex, easier to maintain and more performant implementation.

2. New Migrate Command

The CLI will include a new migrate command meant for helping with the migration of breaking changes in new versions. This will not only be used for the Build Method Change, but also for any future change that allows for automatic migration.

Using the command is straightforward and follows the same style as the dart fix command:

• Running jaspr migrate with no options will check only show which migrations are available for the currently used Jaspr version, e.g. Build Method Migration for version 0.21.0 and newer.
• Running jaspr migrate --dry-run will compute and print all proposed migrations, but makes no changes to the code.
• Running jaspr migrate --apply will compute, print and apply all migrations.

2. New Component Scopes

3. Base Handling