fix: account for headerHeight when restoring state

[phazei]

RE: #1081

[petyosi]

Thanks, I will test and merge if no issues.

[github-actions]

🎉 This PR is included in version 4.7.13 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[phazei]

So, it looks like my original change was modified and moved into the stateLoadSystem.ts where it does the scrollTop -= headerHeight.

The issue with that is headerHeight isn't loaded at that point yet, it's value is always 0, so it doesn't seem to fix the issue.

In the original PR it was in the initialTopMostItemIndexSystem.ts.

        skipFrames(4, () => {
          u.handleNext(scrollTop, () => {
            u.publish(scrolledToInitialItem, true)
          })

          //by this frame the values have loaded if they exist
          const currentHeaderHeight = u.getValue(headerHeight)
          if (typeof initialTopMostItemIndex === 'object' && typeof initialTopMostItemIndex.offset === 'number') {
            initialTopMostItemIndex.offset -= currentHeaderHeight
          }

          u.publish(scrollToIndex, initialTopMostItemIndex)
        })

Those skipFrames is very important. I did test different skipFrames, and unless it's at least 3, the value of headerHeight isn't yet available. I don't know where or when it's calculated, but it needs to be sooner if it's going to be inside stateLoadSystem, because header isn't available as it is now.

[petyosi]

@phazei - the commit I pushed includes an example. As far as I remember, it works as expected. Can you elaborate? Perhaps a sandbox would help me understand the problem better.

[phazei]

I'm currently investigating, things might be pointing to something changing in our codebase, I haven't figured out why it's ignoring the height currently. Will update when I do!

[phazei]

Seems to have gone away, phantom issue 🤷 working fine now