First sticky header is not updated when data is changed

[todorone]

Current behavior

When we update data of list with sticky headers, the first one(that is currently sticky) is not updated, while the rest is updated.

Expected behavior

Items are updated when data is changed

To Reproduce

https://snack.expo.dev/@todorone/flashlist-sticky-headers-bug

• We have 2 header items A and D.
• Pressing "SWAP"
• Headers items should be B and C, instead we see A and C
• When scrolled up/down, items are rendered correctly and we see B and C

Platform:

• iOS
• Android

Environment

1.3.1

[radko93]

We can reproduce the same behaviour.

[j-duggirala]

Any work around to fix this issue?

[todorone]

@naqvitalha any chance to provide at least temporary workaround?

[MaxFedak]

have same issue.

P.S.: If you add an element to array (even if it's not rendered), and add his index to sticky headers, it will update your first sticky header.

[LinusU]

This still happens in version 1.4.3

I've currently worked around it by updating the key prop every time we change the headers. Unfortunately this causes the list to briefly flash as the entire list is re-rendered...

[BuqiLiao]

A better way to fix this rather than updating the key prop to cause flashing is to add a fake header and increase the stickyHeaderIndices:

  const renderItem = ({ item }) => {
    if(item === "FAKE_HEADER") return null;
    if (typeof item === "string") {
      return <MyChatSectionHeader title={item} />;
    }
      return <MyChatItem
        item={item}
        navigation={navigation}
      />
    };
  const stickyHeaderIndices = myChats
    .map((item, index) => (typeof item === "string" ? index+1 : null))
    .filter(index => index !== null);

  <FlashList
    data={["FAKE_HEADER", ...myChats]}
    renderItem={renderItem}
    keyExtractor={item => typeof item === "string" ? item : item._id}
    onEndReached={loadMoreChatsHandler}
    onEndReachedThreshold={0.05}
    ListFooterComponent={<LoadingMoreFooter isLoadingMore={isLoadingMore} />}
    stickyHeaderIndices={stickyHeaderIndices}
    getItemType={item => typeof item === "string" ? "sectionHeader" : "row"}
    estimatedItemSize={70}
  />

However, there will be a slight shake if you scroll up the list since the fake header's indices is counted

[BuqiLiao]

I just found a ever better solution without even slight shaking:
Try to increase the indices once and immediately change back to origin:

  const [stickyIndices, setStickyIndices] = useState([]);
  useEffect(() => {
    const getStickyIndices = (number=0) => {
      return myChats
      .map((item, index) => (typeof item === "string" ? index+number : null))
      .filter(index => index !== null);
    }
    setStickyIndices(getStickyIndices(1));
    setTimeout(() => {
      setStickyIndices(getStickyIndices(0));
    }, 100);
  }, [myChats.length]);
  <FlashList
    data={myChats}
    renderItem={renderItem}
    keyExtractor={item => typeof item === "string" ? item : item._id}
    onEndReached={loadMoreChatsHandler}
    onEndReachedThreshold={0.05}
    ListFooterComponent={<LoadingMoreFooter isLoadingMore={isLoadingMore} />}
    stickyHeaderIndices={stickyIndices}
    getItemType={item => typeof item === "string" ? "sectionHeader" : "row"}
    estimatedItemSize={70}
  />

After all, those are temporary solutions, hope someone could make a PR for this

[itajenglish]

+1

[Himanshu0230]

+1

[bryanprimus]

this issue is still exist

[domenvilar]

I have the same problem. First sticky header is not updated when the data changes.

[dpatterson414]

+1

[MoeKanan]

+1

[pmj100]

+1

[switz]

Yeah, honestly seeing a lot of bugs tied directly to stickyHeaderIndices unfortunately

[MikeKovarik]

+1

[victorlucss]

+1

[GollyJer]

I can't believe how much time I wasted before finding this bug report. 🥲
Thanks for the workaround @BuqiLiao

[jianxinzhoutiti]

+1

[pehagg]

As a simpler workaround, use Array for the sticky headers, e.g.

  const stickyHeaderIndices = new Array(...);

This will force the FlashList to detect the change. No need for useState hooks or setTimeOut.

edit: posted this solution a little too prematurely. This will re-render the first item, but the item is no longer sticky. Sigh.
edit2: this seems to work after all, I had a bug in my code that didn't set the first item as a sticky header

[GollyJer]

Does this have an official fix in the works?

[DominicWrege]

Any updates on that ? 🥺

[DTupalov]

What is the status of this issue? I see that the PR is ready. When do you plan to release it?

[charlie-nis]

@pehagg

As a simpler workaround, use Array for the sticky headers, e.g.

const stickyHeaderIndices = new Array(...);
This will force the FlashList to detect the change. No need for useState hooks or setTimeOut.

edit: posted this solution a little too prematurely. This will re-render the first item, but the item is no longer sticky. Sigh. edit2: this seems to work after all, I had a bug in my code that didn't set the first item as a sticky header

your solution works beautifully

 const stickyIndices: number[] = new Array(
    ...resultsItems
      .map((item, index) => {
        if (typeof item === "string") {
          return index;
        } else {
          return null;
        }
      })
      .filter((item) => item !== null)
  );

[DTupalov]

I see that PR #1267 has been merged into the main branch, and that’s awesome! :)
When do you plan to release this fix?

Thanks for the response.

[dkumar-carfax]

Still facing this issue in Android, Is there any update on this to be released?

[cam-shaw]

@DTupalov @dkumar-carfax have you both tested on version 1.7.2?

[peterjskaltsis]

This seems fixed on 1.7.2 for me

[pehagg]

This is not fixed in 1.7.2.

edit: additional info: the header is updated in case it's not in the "sticky mode", but if it is, it doesn't update. See attached video clip.

ScreenRecording_12-03-2024.15-58-48_1.mov

[anhkieet]

Facing the same issue, has anyone had any solutions?

[amerdiglisic-aily]

This is not fixed in 1.7.2.

edit: additional info: the header is updated in case it's not in the "sticky mode", but if it is, it doesn't update. See attached video clip.

ScreenRecording_12-03-2024.15-58-48_1.mov

I have the same behavior still.