Refine estimatedHeight requirement for RFL about flash-list HOT 10 CLOSED

I think pairing up will help. We can try different approaches and find some better way hopefully. Benchmark in this case is tricky because there are so many use cases and we can easily chose one where it matters and one where it won't.

Let's dive into this on Friday.

from flash-list.

Should we create an issue to make the field optional for the opensource milestone?

I think this issue captures that and it's already in opensource milestone, so I don't think there's anything we need to do here as of now.

from flash-list.

After the call with William, we got another indicator requiring this prop will most likely confuse users and will not give a good first impression.

What I propose instead:

• use initialNumToRender and make it mandatory. We can use this number for the initial render.
• After initial render, we can start refining the estimatedItemSize internally based on the already rendered elements

from flash-list.

I'm wondering how people will come up with that number too for e.g, that number will depend on screen size. Has to be different for mobile vs tablet. I worry that a lot of people will give a value larger than necessary.

from flash-list.

I'm wondering how people will come up with that number too for e.g, that number will depend on screen size.

Right, but I'd argue it's much easier to reason about than estimatedItemSize. Additionally, the fact that FlatList has this prop is a big plus imho.

Has to be different for mobile vs tablet.

estimatedItemSize will be often different for tablet as well to be fair.

from flash-list.

Putting this as another example of people pushing against this prop. We either have to explain this prop a whole lot better or change it as it seems to confuse and frustrate developers.

I think it would be worth doing some profiling to assess how having the value off because of a poor default can detriment the performance. Doing so could make it more obvious the importance of the prop (if we decide to keep it or rename it to initialNumToRender which still raise concerns regarding how to provide good value for it)

from flash-list.

I'll work on the doc today. Hopefully it'll clear things up.

Also, I've been thinking about initialNumToRender and wonder if we had to give a value for our twitter sample how would we do that and what value we'd use?

I've looked at median height on phone vs tablet (S6 lite) and value change by only 13px. I think that's because device pixel ratio is also changing and 13px difference is totally fine. This is just one example though.

How would we replace it with initialNumToRender? Thoughts?

from flash-list.

Also, I've been thinking about it initialNumToRender and wonder if we had to give a value for our twitter sample how would we do that and what value we'd use?

I'd say using a medium-sized device (I guess moto g 10 would work) and use the number of element we'd see on the initial screen as the base. The number needs to be a ballpark approximation anyway.

That being said, I suggest doing the benchmarking first - this will help us make a more informed decision about the necessity of this prop while also serving as a good documentation of the why it is necessary if we decide to keep estimatedItemSize as-is. Let me know if you want help with that @naqvitalha.

from flash-list.

Adding this ticket API parity. Let's compute average internally and discuss whether we can make it optional.

from flash-list.

Should we create an issue to make the field optional for the opensource milestone? I think this is the last issue we need to create regarding this, and we could close this one after we make it optional. Right?

from flash-list.