-
-
Notifications
You must be signed in to change notification settings - Fork 32.5k
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
[flow] Fix Higher-order Component typing #8419
Conversation
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 will hold future changes on the src. I'm gonna focus on upgrading enzyme.
// Provide the theme object as a property to the input component. | ||
export default function withTheme<BaseProps: {}>(BaseComponent: ComponentType<BaseProps>) { | ||
const factory = createEagerFactory(BaseComponent); | ||
const withTheme = (): HigherOrderComponent<{}, InjectedProps> => (Component: any): any => { |
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 don't get it. Why changing the API?
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.
It's unlikely that we will ever need configuration options.
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.
Consistency. Sanity. My sanity. Seriously. If you want to edit it back, you can, but I'd just prefer one chosen HOC 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.
Maybe @istarkov could give us some light here. For instance, I can see the pure
typing.
@rosskevin Are you saying that we need HigherOrderComponent
to get flow going through the HOCs?
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.
@rosskevin recompose seem to have HOC factories as well as HOCs depending on the use cases. I will work on this if you prefer 👼 .
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.
HigherOrderComponent
solves the default prop not found issue linked in the description.
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.
Yep, for most enhancers to type them properly they must be a function, pure is bad example as it just do nothing. So based on my experience there are no other ways
I'm back, working on the karma tests now. |
So this one is huge.
Essentially, I mis-typed the HOCs, which was hiding errors for static analysis. Once I corrected the HOC types based on the docs, I then ran into a flow issue where it did not recognize
defaultProps
inside the wrapped component. Luckily, there is a published type in react-flow-types that solves it.The remaining fallout was immense. Over 1700 flow errors. I have fixed all the errors, and there should be no functional changes except one:
withTheme
. In the interest of consistency (and these HOCs are not easy to type), I altered the execution ofwithTheme
fromwithTheme(Component)
towithTheme()(Component)
to match everything else we have and the same pattern used inrecompose
.For release notes, it isn't necessarily a breaking change, but this PR is bound to reveal existing flow errors in the user's code which was previously hidden.
Also:
babel-plugin-flow-react-prop-types
$FlowFix Props|State
from 0.53 conversionBreaking change