amazing work !
but is this project support react-native ?
Thank you!
Hm. I think it _should_ although I'm not sure about getBoundingClientRect. I've actually not used React Native myself.
Want to give it a shot and let me know? :)
Finally got around to checking out react-native this morning and no, this project isn't compatible. Fails right away when react-virtualized tries to require react (instead of react-native).
I think supporting react-native would probably turn out to be a fair bit of work as I'd have to essentially replace all of the DOM elements with their native component counterparts, which would probably involve first breaking react-virtualized into react-virtualized-core and react-virtualized-browser and then adding a react-virtualized-native layer on top.
This would probably be fun to do but I don't have the resources to do it as a side project. If someone would like to sponsor the development effort, I'd be interested in talking more. Else I'm going to leave this as a "help wanted" issue.
Closing for now due to lack of interest (and resources).
Just a comment and suggestion on this: React-native has the ListView component out of the box that already supports virtualization. I think it makes sense to separate out the high-order components like InfiniteLoader out to a separate _"react neutral"_ package so they work with VirtualScroller or React-native's ListView. That should be a much smaller task.
@joewood Your comment relates to #182. In my branch for that issue I'm working on refactoring the windowing logic to be more decoupled from Grid in order to support windowing for non-checkerboard layouts.
Maybe the result of that could be, as you say, a new NPM package- but I'm not sure. I'll have to give it more thought. More packages means more complicated release process for me and this is a nights-and-weekends project. :)
Right, appreciate the time you've put into this.
I was more thinking about reusing the InfiniteLoader logic (basically on-demand data loading) in a react-native project. Although #182 is interesting (I'm personally using a flex-wrap style scrolling container in the VirtualScroller - but that's a separate issue). My point is that InfiniteLoader is definitely view technology agnostic and could be separated out. Appreciate that release management and dependencies don't make that any easier though.
Right, right. I realized a few minutes after responding that I had kind of responded to something a little orthogonal to what you were suggesting by talking about #182. My apologies. :)
I think the same concerns still apply in terms of package complexity. But I'll give it some thought!
Hey can you give me a quick overview of how virtualized list works? At a high level so I can potentially port this to react native? we are really in need of a listView that behaves in this manner.
From what I understand the core idea behind this is that you have a bounding rectangle, and you just do collusion detection and determine what is in view as soon as the cell goes out of the view you replace it and you keep a cache of cells ?This is just a guess at the technique after reading the code for like 30 seconds.
I don't know enough about react-native to know how easy it would be to port RV to native. I've been interested in doing just that for a while but I don't have the time to do it for fun. (If you'd be interested in talking about contractual work, let me know and we could discuss that possibility.)
Otherwise the core parts of the code you'll want to look at are:
@bvaughn hey yeah sorry I don't have the funds for contractual work haha, I am doing this to get stars on github =P, I know this is a huge pain point for me and other people.
Could you potentially break down the general ideas? or are you too busy for this ?
There's actually not all that much code if you set aside the Flow typings and comments- (the comments are, I think, pretty much the summary you're asking for?). There's also a lot of unit tests that (I think) should help clarify my intentions.
This method is probably a good starting point for you:
https://github.com/bvaughn/react-virtualized/blob/master/source/Grid/utils/CellSizeAndPositionManager.js#L130
@bvaughn Thanks ill have more clear questions after I actually run through the code !
I think virtualizing the ListView in React Native may be a lot easier than re-implementing the browser based version for a couple of reasons:
onChangeVisibleRows. Do no row indicators are needed.So, I think all that's really needed is those first two events tied together with some batch loading callback logic.
Since react-native is not really good out of the box with infinite lists, I would still like to register interest in a RN version. Preferably one that doesn't require fixed heights.
This is something I have an interest in too. And I plan to work on it in the next few months, but likely as a separate effort- (not as react-virtualized but something new). :smile:
Would be great to post this to react-native world too.
@adaptabi (and everyone else interested) you might want to check out FlatList and VirtualizedList, if you haven't already. Lot's of progress has been made towards a better, virtualized List/Grid component in React Native 馃帀
Clauderic beat me to it :smile:
Lots of movement on this in the RN world lately.
need this in react-native +1
react-native +1
still not support react-native yet?
I too am looking for a high-performance list view for large lists in RN.
@BergQuester check out https://github.com/bolan9999/react-native-largelist
Hi @bvaughn . Is this available for react-native now. Or, is it practically possible to convert your source code to work for react-native. Is this a good idea or is it better to start a component from scratch in react native?
Most helpful comment
This is something I have an interest in too. And I plan to work on it in the next few months, but likely as a separate effort- (not as react-virtualized but something new). :smile: