Due to a typo in PR#7667 where I put 'DispatchConfig' when the type was
'EventTypes', there were some flow errors being thrown.
Then PR#7642 fixed a bug in SimpleEventPlugin and added some untyped
methods, which threw more flow errors.
Last, while fixing this, I fixed two eslint errors in the
SimpleEventPlugin test.
* Cull disabled mouse events at plugin level. Remove component level filters
* DisabledInputUtils tests are now for SimpleEventPlugin
* Add click bubbling test
* Add isInteractive function. Use in iOS click exception rules
* Invert interactive check in local click listener. Add test coverage
* Reduce number of mouse events disabable. Formatting in isIteractive()
* Switch isInteractive tag order for alignment
* Update formatting of isInteractive method
In order to properly type an `Operation`, we need to change the call site from having two arguments: one for `type` and one for `payload` into an object that contains both. This isn't a perf regression because we were already constructing this object in the first place and doesn't change the emitted event so shouldn't affect the dev tools.
None of the call sites are actually flow-ified so it isn't technically used but once we will, it'll make sure that we don't send random strings and payload through those very generic methods.
React IDs have been killed and there was one call site left in a test. I trimmed down the implementation to keep only what is actually used and inlined it inside of the test so we don't get more people using it in the future.
* Type SimpleEventPlugin and TapEventPlugin
- Renamed file from 'ReactSynteticEvent' to 'ReactSyntheticEventType'
- Fills in the 'any' holes that were left in DispatchConfig type and the
type annotations in EventPluginRegistry.
- Adds polymorphic PluginModule type and related types
- Uses hack to support indexable properties on 'Touch' type in
TapEventPlugin
The issue in TapEventPlugin is that the code is accessing one of four
possible properties on the 'Touch' type native event using the bracket
accessor. Classes in Flow don't support using the bracket accessor,
unless you use a declaration and the syntax `[key: Type]: Type`.[1] The
downside of using that here is that we create a global type, which we
may not need in other files.
[1]: https://github.com/facebook/flow/issues/1323
Other options:
- Use looser typing or a '@FixMe' comment and open an issue with Flow to
support indexing on regular classes.
- Rewrite TapEventPlugin to not use the bracket accessor on 'Touch'. I
thought the current implementation was elegant and didn't want to
change it. But we could do something like this:
```
if (nativeEvent.pageX || nativeEvent.pageY) {
return axis.page === 'pageX' ? nativeEvent.pageX : nativeEvent.pageY;
} else {
var clientAxis = axis.client === 'clientX' ? nativeEvent.clientX : nativeEvent.clientY;
return nativeEvent[axis.client] + ViewportMetrics[axis.envScroll];
}
```
It turns out that flow cannot type `this` with a function constructor + prototype overrides. Turning it to a class makes flow happy and has minimal impact on the output.
In open source, we already use the loose version of the class transform and internally we have one that's outputting even less code if you have `@preventMunge` in the header.
See discussion in https://www.facebook.com/groups/2003630259862046/permalink/2098480820376989/
This commit takes the first incremental step towards adding type checks
to the React event code. A couple of issues came up.
There is an issue with the SyntheticEvent type: Flow declares a
SyntheticEvent type[1] that lacks the non-public properties which are
used in React internals. To solve this I declared a class that extends
SyntheticEvent. This class can be expanded as we add Flow types to more
places where SyntheticEvent instances are referenced.
I'm happy to change this if folks prefer a different approach.
Some options I considered:
- Override the SyntheticEvent declaration with our own declaration
- Pro: We can use 'SyntheticEvent' as a type just like we are used to
when working in any other codebase.
- Pro: No need to import any type since it's a declaration
- Pro: Only one version of SyntheticEvent; less confusion.
- Con: Could get out of sync with real implementation.
- Con: Duplicates part of the type declared in Flow.
- Import the SyntheticEvent class and use that as the type
- Pro: Keeps type definition in sync with the real implementation.
- Con: Declaration overrides implementation so I'm not sure this would
work.
- Con: Have to remember to import the type.
- Declare a separate type called ReactSyntheticEvent that extends
SyntheticEvent
- Pro: Stays in sync with the Flow SyntheticEvent type;
less duplication.
- Pro: Differentiates this type from the Flow SyntheticEvent type;
less confusion.
- Pro: No need to import any type since it's a declaration
- Con: Could get out of sync with real implementation.
I also ran into an issue where a variable was only non-null when
'__DEV__' is true, similar to PR #7586.[2] The work-around is to force
it to be typed non-null and add a comment documenting the reason. At
this time Flow doesn't have a better way to deal with the situation.
Next steps:
- Specific type for the 'dispatchConfig' property of SyntheticEvent
- More detailed types for PluginName and PluginModule
Lastly; note that I renamed some variables to follow the convention of
reserving PascalCase for classes, enums, and Flow types.
[1]: https://github.com/facebook/flow/blob/master/lib/react.js#L277-L293
[2]: https://github.com/facebook/react/pull/7586/commits/b99eb5087bc2df3bcb64d76a2d75953978f61f34
We used to copy and paste the same big blob many times in order for it to work with keyOf which is no longer a constraint. This pull request takes a list of all the events as string and generate those data structures at runtime.
It reduces the size of React by 1k post gzip and flow is able to extract the structure out of it :)
Jest 15 has just been released and is way more awesome: http://facebook.github.io/jest/blog/2016/09/01/jest-15.html
This pull request updates jest from version 12 to 15. Right now there's a fix in jest around Symbol that hasn't been released yet, so this will break CI and cannot be merged it. But once it ships by the end of the day, we'll be good to go :)
See comments inline for all the changes I've done.
This is the last callsite of keyMirror! It removes 0.5k gzipped :)
The only trick with this one is that ReactTestUtils actually iterates over the list of all the events. Instead of duplicating the logic, I used the $Enum feature of flow that lets us statically extract out the type from the dynamic value. Inside of react-dom we're no longer requiring the file directly so it doesn't bloat the file size, and we still get to have static typing, best of both worlds!
This one is interesting because we have transaction objects being passed around everywhere in the codebase but there's actually no Transaction class. It's a "mixin" that comes to life by being Object.assigned to the prototype of a real "class" (before class was cool!). Therefore, we can't just say `var Transaction = require('Transaction'); (transaction: Transaction) => { }` because it would be the object that contains a mixin and not an instance of a transaction.
The trick I use is to export `TransactionType` and alias it to `Transaction` in the file as it doesn't actually require transaction. In case they do, we'll figure it out, but in the few files I looked at, it doesn't seem to be the case.
For the perform function, it actually typechecks pretty well!
This one was really interesting to type as it's doing a lot of unusual JavaScript. Fortunately flow is now pretty kick ass and I've been able to mostly type it. The only missing piece is that it won't check the constructor arguments.
If you are a fb employee, you can follow the discussion here: https://www.facebook.com/groups/flowtype/permalink/1132359430146004/
Incrementally type ReactInstance by adding the types of attach/detachRef.
I moved isValidOwner as a function inside of the file since it's never used externally.
This one involves a bit more work as I added "phantom" flow types to a bunch of places where the type is a ReactPropTypeLocations even though those files are not `@flow` yet.
A good side effect is that `ReactPropTypeLocationNames` keys are now correctly typed, this means that they cannot go out of sync without breaking flow :)
Flow doesn't really support the concept of variables that are non-null but only inside of a `__DEV__` block. There's an internal post about it ( https://www.facebook.com/groups/flowtype/permalink/1132437726804841/ ) and the conclusion is that we should force it to be non-null and trust the developer to put the proper DEV checks in place.
We need to export FlushHistory type and I submitted a PR on flow to fix the type of console.table which is too restrictive.
I'm already starting to see the benefits of flow, I can look at random variables in the code and flow knows what shape the objects are! It's really useful to try and understand what's going on :)
Flarnie Marchan
Paul O’Shannessy
Nathan Hunzaker
Toru Kobayashi
Christopher Chedeau
Filip Spiridonov
Brandon Dail
hkal
Dan Abramov
Flarnie Marchan
Ben Alpert
Christoph Pojer
Christopher Chedeau
Mateusz Burzyński
Ben Alpert
Miller Medeiros
Kevin Lin
Marcin Mazurek
Clay Miller
TedPowers