React-window: Changing props of one item will update the whole list

I have the exact same use case and problem, and have not been able to find a solution...

That's because changing an item creates a new items array which creates a new itemData object. It's important that memoization techniques are invalidated then their data changes.

If you want the items to be more robust to this sort of change, you could implement your own areEqual function (or shouldComponentUpdate).

The demo's purpose is just to show how itemData and memoization can work together to pass complex values.

I had testest it with my own shouldComponentUpdate function but this function won't be executed, if the component will gets umounted again and again

if the component will gets umounted again and again

There's no way to memoize a component that gets unmounted. That's not what happens in my demo though. If it's what happens in your app, there's something else going on– and I can't speculate about what.

@BertelBB Did you find a solution?

@ffjanhoeck Not really, no. I realised that my use case is actually a little bit different in the sense that my list can also be sorted/filtered. What I did is I pass in the itemData and itemKey props so that I manually set the key prop for every item. The whole list still updates but it is not as laggy as before.
https://react-window.now.sh/#/api/FixedSizeList here you can read about the props I am referring.

@BertelBB I already implemented that function yesterday, thank you :)
But the problem is not fixed :(
Here is an GIF what is laggy - as you can see is took some milliseconds to check an item.
Everything is memoized or have a implemented shouldComponentUpdate.

@ffjanhoeck Yes, have the same issue. I unfortunately do not have time to look further into this as of now. But I will let you know if I find a better solution :)

@ffjanhoeck Any chance I could take a look at the app you showed in the GIF above? I'd be curious to run a profiler and see where the slowness is coming from.

@bvaughn Yes sure - I have send you the credentials on your email! :)

I think the slowness comes from the short preview of an item (The picture and the blue text with the secondary text represents the EntityShortPreview Component). But it is not a problem for one item. The problem is that all items get unmounted and mounted on select and if you sum up this, then it is slow.

Thats my current feeling :D But maybe you can find some other issues :)

This happens if a user select one item

@ffjanhoeck I ran into the exact same issue, and after some investigation, I managed to figure out the cause: it's because we're using anonymous functions as item renderers, instead of named components. I'm no React guru, but I believe this messes up React's reconciliation, since the components aren't recognizably the same between renders.

I made a CodeSandbox example illustrating the problem here: https://codesandbox.io/s/qx4088mn36

I believe this is also related to the conversation here: https://github.com/bvaughn/react-window/issues/85#issuecomment-436329610

That's what I'm seeing too after a quick look this morning. (Was writing an email but got interrupted.) Moving the inline function to an instance prop sped things up, (but also broke a few other things that I didn't have time to track down due to the size of the repro case).

I believe this messes up React's reconciliation, since the components aren't recognizably the same between renders.

This is correct. 👍

Hmm. This is unfortunate, because I'm writing my project using ReasonReact, which (currently) lacks the necessary props spreading/functional component features to avoid this problem. I recognize that this is not in any way a problem with react-window, just a limitation of ReasonML's type system, but I suppose it's worth mentioning in case anybody else stumbles upon this thread.

To be clear, this is why all of the docs examples show the item render being defined outside of the parent component, and the memoization example shows how to share data between the two. (Basically it's like a lighter weight, built-in context.)

Great, I will take a look! :)

Your solution fixed the Issue! Thank you and have a nice day