Skip to content

CPLAT-4031: Make builder compatible with Dart 2 only boilerplate #227

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 16 commits into from
Feb 7, 2019

Conversation

corwinsheahan-wf
Copy link
Contributor

@corwinsheahan-wf corwinsheahan-wf commented Feb 1, 2019

Ultimate problem:

Currently the 2.0.0-dev branch only contains support for building on the transition boilerplate.

How it was fixed:

  • Add support for Dart 2 only boilerplate by generating consumable companion class for @Props(), @State(), @AbstractProps() and @AbstractState() annotated classes, as well as generated consumable class for props mixins.
  • Is still backwards compatible with the transition boilerplate.

Testing suggestions:

  • CI Passes (tests and examples added)

Potential areas of regression:

Everything


FYA: @greglittlefield-wf @aaronlademann-wf @evanweible-wf @maxwellpeterson-wf @sebastianmalysa-wf @georgelesica-wf

@corwinsheahan-wf corwinsheahan-wf requested a review from a team as a code owner February 1, 2019 20:55
@aviary-wf
Copy link

Security Insights

No security relevant content was detected by automated scans.

Action Items

  • Review PR for security impact; comment "security review required" if needed or unsure
  • Verify aviary.yaml coverage of security relevant code

Questions or Comments? Reach out on Slack: #support-infosec.

@corwinsheahan-wf corwinsheahan-wf changed the base branch from master to 2.0.0-dev February 1, 2019 20:55
Copy link
Contributor

@greglittlefield-wf greglittlefield-wf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looked at everything but the tests, found a couple small things but otherwise looks great!

updateCompanionClass(name, true);
validateMetaField(companionClass, isPropsClass(name) ? 'PropsMeta': 'StateMeta');
} else {
if (!member.name.name.startsWith(privateSourcePrefix)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On Dart 2, this validation should happen regardless of whether or not the companion class exists. The class should always be prefixed with _$

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In other words, I think this check should be moved up to line ~145


if (variable.initializer != null &&
!expectedInitializer.contains(variable.initializer.toString())) {
if (variable.initializer != null && expectedInitializer != variable.initializer.toString()) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just occurred to me that this misses empty initializers, which we shouldn't support anymore

Suggested change
if (variable.initializer != null && expectedInitializer != variable.initializer.toString()) {
if (variable.initializer == null || variable.initializer.toString() != expectedInitializer) {

Copy link
Contributor

@aaronlademann-wf aaronlademann-wf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is... impressive work @corwinsheahan-wf!

So close... so very, very close!!!

if ((variable?.initializer?.toString() ?? '') != expectedInitializer) {
error(
'Factory variables are stubs for the generated factories, and should not have initializers '
'unless initialized with a valid variable name for Dart 2 builder compatibility. '
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This message is leaking some legacy. I think we can drop the "...should not have initializers unless initialized with..." part and just tell them that they "should be initialized with ".

@evanweible-wf
Copy link
Contributor

@corwinsheahan-wf Just noticed this when reading the docs updates - any reason the generated factory implementation needs to be public?

return '$publicGeneratedPrefix${componentClassName}Factory';

@corwinsheahan-wf
Copy link
Contributor Author

corwinsheahan-wf commented Feb 7, 2019

@evanweible-wf That does need to be public. When a component is a subtype of another component, the super component's factory is referenced as part of the factory for the sub component:

parentType: $SuperComponentFactory,

The super and sub components can, and will often be, in separate libs

Copy link
Contributor

@aaronlademann-wf aaronlademann-wf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

Copy link
Contributor Author

@corwinsheahan-wf corwinsheahan-wf left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 to Evan's commit

@evanweible-wf
Copy link
Contributor

QA +1

  • CI passes
  • Verified locally against two internal consumers using backwards-compat boilerplate and the dart2-only boilerplate.

@Workiva/release-management-p

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants