-
Notifications
You must be signed in to change notification settings - Fork 58
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
UIP-2410: Basic DDC support #82
UIP-2410: Basic DDC support #82
Conversation
RavenNumber of Findings: 0 |
@@ -35,7 +35,7 @@ DomProps domProps([Map backingMap]) => new DomProps(null, backingMap); | |||
|
|||
typedef DomProps DomPropsFactory(); | |||
|
|||
class DomProps extends component_base.UiProps with DomPropsMixin, ReactPropsMixin { | |||
class DomProps extends component_base.UiProps with DomPropsMixin { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a breaking change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking the same thing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is part of "Fix mixing in the same props class twice"; ReactPropsMixin
is already mixed in by component_base.UiProps
@@ -45,7 +45,7 @@ class DomProps extends component_base.UiProps with DomPropsMixin, ReactPropsMixi | |||
final Map props; | |||
} | |||
|
|||
class SvgProps extends component_base.UiProps with DomPropsMixin, ReactPropsMixin, SvgPropsMixin implements DomProps { | |||
class SvgProps extends component_base.UiProps with DomPropsMixin, SvgPropsMixin implements DomProps { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this a breaking change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is part of "Fix mixing in the same props class twice"; ReactPropsMixin
is already mixed in by component_base.UiProps
var parameters = [] | ||
..add(props) | ||
..addAll(invocation.positionalArguments); | ||
return Function.apply(factory, parameters); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does this need test coverage?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point; though 99% of cases will use a ReactComponentFactoryProxy
, it's in here for backwards compatibility.
I'll add some tests around this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Coverage added in 88bce6c
(member.isGetter || member.isSetter) && | ||
!member.isSynthetic && | ||
!member.isStatic && | ||
member.metadata.any((meta) => meta.name.name == 'override') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens if the consumer isn't annotating overrides?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then they need to start annotating overrides if they want to get this opt-in fix 😛
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that's fine, seeing as the @override
restriction is documented. I put that restriction in place to avoid patching accessors that might not need it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll let Trent know that we should require the annotate overrides lint then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure that's necessary. The issue that this fixes is quite apparent when building in the DDC, so it's easy to identify which getters are problematic. And then there's also the tool that @georgelesica-wf, which should also identify problematic getters.
Plus, I'm not sure that anyone else outside of our team even uses this pattern. .
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Better safe than sorry
6568d96
to
b1a8bda
Compare
Codecov Report
@@ Coverage Diff @@
## master #82 +/- ##
==========================================
- Coverage 97.58% 94.81% -2.76%
==========================================
Files 29 31 +2
Lines 1402 1522 +120
==========================================
+ Hits 1368 1443 +75
- Misses 34 79 +45 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not seeing any issues in the current state of this code - waiting on further test coverage to +1.
@clairesarsam-wf ready for dev +1 |
+1 |
QA +10
Merging. |
Ultimate problem:
Running OverReact-based code in the DDC resulted in several runtime errors.
Also, the patterns of declaring abstract prop getters was problematic.
How it was fixed:
UiProps
classes from having props namedname
^3.4.0
to consume new.build()
APIgetProps
since Expandos not working on certain JS objectsfixDdcAbstractAccessors
) to work around DDC abstract accessor issue for props/stateTesting suggestions:
ddev test
ddev test -p chrome
(not done in CI, needs to be run manually)Potential areas of regression:
UiProps
+ fluent interface