CPLAT-1858, CPLAT-1857: Builder to build on backwards compatible boilerplate

[corwinsheahan-wf]

Ultimate problem:

Dart 2 drops support for transformers

How it was fixed:

Add an analogous builder (factory name overReactBuilder) which provides the same functionality and operates on boilerplate which is compatible with both Dart 1 and Dart 2. See the section about transition boilerplate in the Migration Guide

Testing suggestions:

• Tests added which cover build output
• Functionality tested on internal repositories using over_react.

Potential areas of regression:

• Pretty much everything

---

FYA: @greglittlefield-wf @aaronlademann-wf @kealjones-wk @evanweible-wf @maxwellpeterson-wf

[greglittlefield-wf]

Done with first pass, looking good

[greglittlefield-wf]

This is actually a TODO leftover from the transformer; the problem occurred when extending a non-abstract component, which had a generated implementation of typedPropsFactory mixed in.

class FooComponent<T extends FooProps> extends UiComponent<T>
  // mixin added by transformer
  with _$FooComponentMixin { ... }
class _$FooComponentMixin {
   FooProps typedPropsFactory(map) => new _$FooPropsImpl(map);
}

class BarProps extends FooProps {}
class BarComponent extends FooComponent<BarProps>
  // mixin added by transformer
  with _$BarComponentMixin { ... }
class _$BarComponentMixin {
   BarProps typedPropsFactory(map) => new _$BarPropsImpl(map);
}

Then it would complain something like

typedPropsFactory in class BarProps (Map) => BarProps is not a valid override of
typedPropsFactory in class FooProps (Map) => <T extends FooProps>

Since BarProps isn't always a valid subtype of T.

Edit, sorry, I got it kind of backwards. The error would be:

typedPropsFactory in class FooProps (Map) => FooProps is not a valid override of
typedPropsFactory in class UiProps (Map) => <T extends FooProps>

Since FooProps isn't always a valid subtype of T.

---

Now with the way that the builder generates the typedPropsFactory in an additional subclass that is never subclassed fromprovides a type for T, we shouldn't hit that conflict in BarPropsFooProps!

Theoretically, you should be able to reinstate the typing (or, since you don't need to redeclare the typing on overrides, just remove the as dynamic) and it'll work!

-typedPropsFactory(Map backingMap) => new $propsImplName(backingMap) as dynamic;
+typedPropsFactory(Map backingMap) => new $propsImplName(backingMap);

[aaronlademann-wf]

I thought these changes were slated for Dart 1 and Dart 2 SDK compat? Shouldn't the lower bound remain >=1.24.3 in that case? Or am I misunderstanding the milesone?

[corwinsheahan-wf]

Transformers can't exist in a Dart 2 repo b/c barback doesn't have any Dart 2 compatible versions.

[aaronlademann-wf]

mmm... we should probably change the milestone description then, IMO. It says pretty clearly that we're targeting dart 1 and dart 2 support, which sounds like it isn't possible.

[evanweible-wf]

We will still effectively be supporting both Dart 1 and Dart 2, but the method for doing so will be the dual release lines (eg. 2.0.0-dart1 and 2.0.0-dart2).

[corwinsheahan-wf]

Yep, except it's +, not -, right? Also I believe that the plan is to have 2.0.0 and 2.0.0+dart1 (i.e. Dart 2 is the default)

[aaronlademann-wf]

How will the dual release lines work if the SDK lower bound (and other dependency ranges) are Dart 2 only @evanweible-wf ?

[evanweible-wf]

That's actually how the dual release lines work. For every version that we want to release, we'll actually cut two releases. The 2.0.0-dev branch will be our divergence point – we'll branch off of current master to make a master_dart1 branch before we merge 2.0.0-dev in and we'll cut the dart1 releases off of that branch and dart2 releases off of master. So, for example, the 2.0.0 release would look like this:

• 2.0.0-dart1
  • tagged from dart1_master branch
  • environment constraint of >=1.24.3 <2.0.0
  • uses the transformer
• 2.0.0-dart2
  • tagged from master branch
  • environment constraint of >=2.1.0 <3.0.0
  • uses the builder

As a consumer, this is all transparent once deprecation warnings have been taken care of. We will depend on a version range like we normally do:

dependencies:
  over_react: ^2.0.0

And then pub will pull in the appropriate version based on the version of the Dart SDK that is installed. This is how the dart2_constant package works.

[aaronlademann-wf]

This is one of those blocks of code that ... when you see it... you wonder - WITAF is dart format doing?

Like... how could this possibly be the "canonical" way to format this code?

[evanweible-wf]

QA +1

• CI passes

Will thoroughly test this on our internal consumers before merging 2.0.0-dev to master.

@Workiva/release-management-p

[corwinsheahan-wf]

+1 to others' commits