Performance implications with Carousel as an indirect child of ScrollView

Is this a bug report or a feature request?

General question

Have you read the guidelines regarding bug report?

Yes

Have you read the documentation in its entirety?

Yes

Have you made sure that your issue hasn’t already been reported/solved?

Yes

Is the bug specific to iOS or Android? Or can it be reproduced on both platforms?

Both

Is the bug reproductible in a production environment (not a debug one)?

N/A

Have you been able to reproduce the bug in the provided example?

N/A

Environment

Environment: React: 16.0.0 React native: 0.50 react-native-snap-carousel: 3.5.0

Target Platform: Android (8.1) iOS (11.2.2)

Steps to Reproduce

In the Performance Tips section of the docs there’s a note that says:

1. Make sure the carousel isn’t a child of a ScrollView (this includes FlatList, VirtualizedList and many plugins). Apparently, it would render all child components, even those currently off-screen.

Does this mean that Carousel shouldn’t be a direct child of ScrollView, or a child at all?

In your example implementation, I noticed that you had ScrollView --> View --> Carousel, so I’m curious if this is conforming to the performance tip, or ignoring it since it’s a just an example with a few items.

As an aside, I’m really loving this component/library, so thanks for the great work ! I recently noticed some performance bottlenecks during the initial render, so I want to make sure I’m going about everything correctly. My current setup is a ScrollView with about 12 Carousel children (wrapped in View’s), that each have 5-20 items. I have a feeling items off the screen are getting rendered, so I might switch the parent component from a ScrollView to a SectionList or a FlatList instead.

[pcooney10]

Hey @bd-arc,

Thank you for the quick reply.

I was able to put a quick bandaid on my app and increase performance by doing some of the pretty basic stuff. Namely:

• make sure there aren’t any excessive calls to this.setState in the component that renders the Carousel’s and their parents
• utilize shouldComponentUpdate / PureComponent for my Carousel items - I’m using shouldComponentUpdate since there’s only prop that I know will change
• properly leverage the initialNumToRender and maxToRenderPerBatch props inherited from FlatList, and windowSize inherited from VirtualizedList
• leverage onEndReached & onEndReachedThreshold so I can keep my lists short & only add new data when the user actually wants it
• utilize InteractionManager to render my Carousels that are “below the fold”
• avoid using functions & object literals for props declared on components - this apparently results in “new props” during a re-render
• use babel-plugin-transform-remove-console (documented here) to remove all console.log statements in production. This is not really related to this lib, but is good to know about / use.

I still plan to test nesting the Carousel’s in a FlatList, but as you said it’s quite a nebulous world, so most of my efforts have been focused on researching. Learning how to properly test performance in a RN app is also an animal in itself, but this article was very helpful.

My thoughts on why FlatList and SectionList extending ScrollView might be irrelevant are based on what’s said in this article. FlatList and SectionList are extensions of VirtualizedList (which I realize is still an extension of ScrollView), and the VirtualizedList component claims to:

“virtualize” elements that are outside of the render window by completely unmounting them from the component hierarchy and reclaiming the JS memory from the react components, along with the native memory from the shadow tree and the UI views.

To aid in my testing efforts, I have a question that you might be able to answer - does a component that’s currently “Virtualized” fire the render() method? If so, it might be difficult to tell what’s virtualized and what’s not. If not, then this should be pretty easy to test.

Thanks again for the great repo !

[bd-arc]

So far, the React doc was my reference on this matter. This means I’ve been using the Chrome Dev Tools, just like you.

But I’ve just re-read the “Performance” part of the RN doc, and my conclusion is that I should definitely read it more often. The “Profiling” section contains a lot of insights and introduces very useful tools.

I need to try this all!