Why doesn't keyExtractor return an index anymore?

[fax1ty]

I'm not sure if JSON.stringify is a better option for large JavaScript objects than simple string concatenation.

[After repo quick search...]
inefficient for large objects, custom implementation recommended
As I can see, as you too

keyExtractor before:

  const keyExtractor = (item: Item, index: number) => {
    switch (item.type) {
      case "uno":
        return item.type;
      case "dos":
        return item.type + index;
      case "tres":
        return item.content.id.toString();
    }
  };

keyExtractor after:

  const keyExtractor = (item: Item) => {
  switch (item.type) {
    case "uno":
      return item.type;
    case "dos":
      return JSON.stringify(item);
    case "tres":
      return item.content.id.toString();
  }
};

Date.now() is not an option, is it? Will the keyExtractor be executed later?

[MatiPl01]

Why doesn't keyExtractor return an index anymore?

It doesn't because of problems that it introduced. In general, items were incorrectly positioned after a new data array was provided containing items in a different order than before. Because keys were assigned based on index, thus they weren't related to the item itself, we could observer incorrect animations e.g. during view addition/removal - see the example below:

key related to item (e.g. id prop) (correct)	index key (incorrect)
Screen.Recording.2025-03-25.at.00.39.51.mp4	Screen.Recording.2025-03-25.at.00.39.24.mp4

You included comparison of 2 keyExtractor implementations. Did you use the first one with the index argument? If yes, did you change the data array passed to the Sortable.Grid component and observed similar problems to mine?

Date.now() is not an option, is it?

No, you shouldn't use anything that is not related to the item, so Date.now() will be invalid. What is more, it will result in producing the same keys for multiple items as keyExtractor is called for each item, which is also invalid, because every item must have an unique key.

Will the keyExtractor be executed later?

What do you mean by asking if it will be executed later?

[fax1ty]

You included comparison of 2 keyExtractor implementations. Did you use the first one with the index argument? If yes, did you change the data array passed to the Sortable.Grid component and observed similar problems to mine?

Yes, I am actively adding, deleting, and repositioning elements. So far, I have not observed any similar behavior.

What do you mean by asking if it will be executed later?

If we call the keyExtractor function twice for the same item, using the Date.now method, we will get two different IDs.

Okay, more or less, I understand. I'll try to find a way to pass the ID for the item, just like in case 3.

[fax1ty]

I'm not sure if notifications are sent for closed discussions. I mention this here, just in case.
Portals are not working for me.

[MatiPl01]

If we call the keyExtractor function twice for the same item, using the Date.now method, we will get two different IDs.

Yeah, you will get different keys after each render when the new array of items is provided. What is more, you will get the same key for every item in the array, as keyExtractor will be called for all items at the same time. That's why you shouldn't use Date.now() to generate item keys.

I'm not sure if notifications are sent for closed discussions. I mention this here, just in case.

I have seen this comment but didn't have time to prepare the app with reanimated 3.15 and test it out. I tested on my example app with latest versions of dependencies and I haven't seen this issue. It should not be related to the reanimated version, though, more likely to react-native version or something else.

Maybe you can prepare a repository with reproduction and share it with me or tell me which version of react-native you use and share the code snippet that is problematic?

[fax1ty]

I will prepare a reproduction with bare React Native.
I'm on 0.74.2, BTW

[MatiPl01]

Hey @fax1ty!
I've tested my example app and it seems that the implementation was invalid. I added collapsable={false} to the portal outlet and released a new version that should work fine. You can test it out and let me know if the problem is gone now.