[flow] Upgrade to flow 0.53.1#7869
Conversation
- ran flow-upgrade - switch React.Element<any> references to React.Node - switch all react imports to `* as React` and use the React.* for access to uniformly access both function and types - linted
This isn’t a fix, it just gets past the error. I assume generated prop types are still invalid.
* [docs] Fix missing props in css-in-js examples `this.classes.root` wouldn't work - `this.props.classes.root' would. * Update css-in-js.md
|
Some notes to those that find this, to use flow + react in what was formerly known as |
|
Docs are failing so more left... |
|
Docs are working again. Another FYI, with this PR I've converted several additional components to Flow, increasing our coverage. |
|
@oliviertassinari - do you see anything on ButtonBase that would cause react-docgen to just fail entirely? I couldn't find anything |
| // @flow | ||
|
|
||
| import React from 'react'; | ||
| import * as React from 'react'; |
There was a problem hiding this comment.
Why do we need to perform such change? I have never seen such pattern for importing React. That's hiding something.
There was a problem hiding this comment.
The only migration I could find so far: https://github.com/facebook/react/pull/10510/files
There was a problem hiding this comment.
It allows import of both types and functions. Without it we need to import everything separately. Since the migration tool automatically does this and all examples use it, it seemed to be what users are most likely to be familiar with. We can incrementally switch to individual imports.
There was a problem hiding this comment.
All the documentation references it this way: https://flow.org/en/docs/react/components/
Specifically addressed in the note here: https://flow.org/en/docs/react/children/
There was a problem hiding this comment.
Sounds good then for the source code 👍. I haven't looked at the demos, but I don't think that they should be flowtyped covered as used in an unknown environnement. We have been using flow weak so far.
There was a problem hiding this comment.
Demos I have kept as weak as possible. The only change was I had to change extends React.Component to extends React.Component<any, any>
There was a problem hiding this comment.
@rosskevin Won't that break with users using Typescript or not using the babel flow plugin?
There was a problem hiding this comment.
Maybe we could disable flow for the demo folders instead.
There was a problem hiding this comment.
I'm not sure if it will break without the flow type stripping plugin or not. If we decide to, I'll PR separate.
There was a problem hiding this comment.
I'm not sure if it will break without the flow type stripping plugin or not
|
I have created #7880 to get the docgen working properly again. |
|
No on #7880, I'm hoping somebody will pick up the docgen issue, it affects every single flow user of docgen. Worst case if someone doesn't pick up in a week I can look at it. No on #7881, I'm going to address it next (today). It is a pre-existing problem and not caused by this PR (a small amount of growth is). I think I can solve that one today due to my familiarity with PRing on that plugin. |
|
Will address #7882 demos today as well. |
|
@rosskevin Awesome, one step at the time 👍 |
|
Nice work! |
Fixes #7788
This is a massive changeset to accomodate the major change in flow's built-in libdef for react. The changes and reference to docs are outlined in the release notes: https://github.com/facebook/flow/releases/tag/v0.53.0
Given this huge changeset, it is virtually un-reviewable.
Once the tests pass on CircleCI, I'll be squash merging, and I pledge to handle what would normally be reviewable separately and timely.