Summary:
A nice bit of polish for apps is to update the separators between list items
when press actives the highlight (things get especially noticeable/ugly when
the separators are not full width and don't adjust). This can be difficult to
coordinate and update efficiently, so we bake the functionality into
`VirtualizedList`.
The approach taken here is a little different from `ListView`. We pass a new
`separators` object with `renderItem` that has easy-to-use callbacks for toggling
the 'highlighted' prop on both adjacent separators - they can be wired up
directly to the `onShow/HideUnderlay` props of `TouchableHighlight` (pit of
success and all that - we want those RN apps to be polished!), but we also
provide a more generic `separators.updateProps` method to set any custom
props. This also passes in `leadingItem` so more custom wiring can be done on
initial render (e.g. linking the highlight state with `Animated`).
This also moves the separator rendering into the `CellRenderer`. I think this might
also fix some subtle measurement bugs with the `onLayout` not capturing the
height of the separator, so that's nice too, but the main reason is to have
an easy place to store the state so we don't have to re-render the entire list
like `ListView` does. Instead we track references to the cells and call update
only on the two we care about so the feedback is instantaneous even with big,
heavy lists.
This diff also messes with a bunch of flow and updates the example to be more
like a standard list.
`SectionList` support is coming in a stacked diff.
**TestPlan**
Video demo:
https://youtu.be/uFE7qGA0mg4
Pretty sure this is backwards compatible....
Reviewed By: thechefchen
Differential Revision: D4833557
fbshipit-source-id: 685af46243ba13246bf280dae8a4223381ce8cea
Summary:
It was just adding unnecessary complexity. Users should just use standard React perf best practices, like `PureComponent` and `shouldComponentUpdate`.
This should be backwards compatible - existing `shouldItemUpdate` usage will just be ignored and should consider migrating to this pattern:
```
class MyItem extends React.PureComponent {
_onPress = () => {
this.props.onPressItem(this.props.id);
};
render() {
return (
<SomeOtherWidget title={this.props.title} onPress={this._onPress} />
)
}
}
...
_renderItem = ({item}) => (
<MyItem onPressItem={this._onPressItem} title={item.title} id={item.id} />
);
```
Which will automatically prevent re-renders unless the relavent data changes.
Reviewed By: yungsters
Differential Revision: D4730599
fbshipit-source-id: 0f61efe96eb4d95bb3b7c4ec889e3e0e34436e56
Summary:
After a fair bit of use, we have concluded that the `ItemComponent` mechanism is not worth the
hassle. Flow has trouble type checking it thoroughly, requiring an 'item' prop is annoying, and it
is very common to need to capture `this` anyway, e.g. for an `onPress` handler. A common pattern was
something like:
_renderItem = ({item}) => <MyItem foo={item.foo} onPress={() => this._onPress(item)} />};
...
ItemComponent={this._renderItem}
which wouldn't flow check the props and doesn't benefit from reusing components.
If we find some specific patterns that would benefit from the `ItemComponent` pattern, we can create
a new component that provides that API and wraps `FlatList` under the hood.
I'm going to do `SectionList` in a stacked diff.
Reviewed By: bvaughn
Differential Revision: D4625338
fbshipit-source-id: a4901f1c9d77e0115b0b8032b8c210f624e97ea3
Summary: Adding providesModule annotations to files that don't have a `providesModule` annotation but are in directories that packager crawls.
Reviewed By: cpojer
Differential Revision: D4612455
fbshipit-source-id: b23f0d6bbe2d26f480e93b56b67c6c8b1075e9f7
Summary:
The index is used to make sure the layout corresponds to the correct index, which can get
out of sync if cell layout is cached and then cells are re-ordered.
Reviewed By: bvaughn
Differential Revision: D4554721
fbshipit-source-id: 9acb37f390a6e40ad89f813b78f81b399ec11e9a
Spencer Ahrens
Bhuwan Khattar