Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Shouldn't 'ListView' be 'TableView' #143

Closed
nathanborror opened this issue Mar 11, 2015 · 4 comments
Closed

Shouldn't 'ListView' be 'TableView' #143

nathanborror opened this issue Mar 11, 2015 · 4 comments
Labels
Resolution: Locked This issue was locked by the bot.

Comments

@nathanborror
Copy link

Why not use more conventional names iOS developers will be familiar with?
@vjeux
Copy link
Contributor

vjeux commented Mar 12, 2015

We thought about it (the first version was called TableView) but there's a couple of downsides:

  • It doesn't have the same api, and works best with immutable data structures, so it would confuse iOS engineers.
  • TableView is an horrible name since it's not a table but a list. Web developers would be confused. The equivalent on android is also called ListView
  • The implementation doesn't actually uses TableView but a scrollview behind the scenes.
  • It only implements out of view cell management, but doesn't have TableView features such as swipe to delete, reordering... We may want to have a component that wraps TableView more closely and have those features and call it TableViewIOS.

We're not 100% api with the component api and it'll likely receive more love in the future. Not set in stone yet

@jaygarcia
Copy link
Contributor

Something to consider: swipe to reveal/delete/etc are features that people will want eventually.

I guess the key is to have a "good" release but not try to solve for every UI pattern out of the gate.

JG

301.785.6030 :: @moduscreate

:: sent from my mobile device ::

On Mar 11, 2015, at 20:07, Christopher Chedeau [email protected] wrote:

We thought about it (the first version was called TableView) but there's a couple of downsides:

It doesn't have the same api, and works best with immutable data structures, so it would confuse iOS engineers.
TableView is an horrible name since it's not a table but a list. Web developers would be confused. The equivalent on android is also called ListView
The implementation doesn't actually uses TableView but a scrollview behind the scenes.
It only implements out of view cell management, but doesn't have TableView features such as swipe to delete, reordering... We may want to have a component that wraps TableView more closely and have those features and call it TableViewIOS.
We're not 100% api with the component api and it'll likely receive more love in the future. Not set in stone yet

—
Reply to this email directly or view it on GitHub.

@nathanborror
Copy link
Author

Makes sense.

@benjamingr
Copy link

but doesn't have TableView features such as swipe to delete, reordering... We may want to have a component that wraps TableView more closely and have those features and call it TableViewIOS.

Are there any plans for such a component?

@gabro gabro mentioned this issue Mar 27, 2015
Closed
@jasongrishkoff jasongrishkoff mentioned this issue Feb 23, 2017
Closed
jasongrishkoff referenced this issue Feb 24, 2017
@sahrens @facebook-github-bot
Better ListView - FlatList
a345748 
Summary:
We really need a better list view - so here it is!

Main changes from existing `ListView`:

* Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window.
* No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible.
* Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`.
* Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props.
* Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive.
* Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>`
* Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior.
* Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable.

Demo:

https://www.facebook.com/groups/576288835853049/permalink/753923058089625/

Reviewed By: yungsters

Differential Revision: D4412469

fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
This was referenced Apr 7, 2017
Closed
Closed
@zhujianguo zhujianguo mentioned this issue Apr 26, 2018
Closed
@facebook facebook locked as resolved and limited conversation to collaborators May 29, 2018
@react-native-bot react-native-bot added the Resolution: Locked This issue was locked by the bot. label Jul 23, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
Resolution: Locked This issue was locked by the bot.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@nathanborror @jaygarcia @vjeux @benjamingr @react-native-bot