react-sticky: 'getBoundingClientRect' of null error when using together with react-router

I have nested StickyContainers. One global (that is available all the time) and two containers that are inside routes. When switching those two routes back and forth quickly, I will get the following error:

Uncaught TypeError: Cannot read property 'getBoundingClientRect' of null

in the following line: https://github.com/captivationsoftware/react-sticky/blob/43a370d2810215de1b7d9c7a5986d860c52206e1/src/Container.js#L47

Seems like react-sticky is trying to access an unmounted(?) container and therefore is not getting the node.

The StickyContainer inside the routes is wrapped inside a div (that is inside the route component):

<Router render={() => (
  <div>
    <StickyContainer>
       // ...
     </StickyContainer>
  </div>
)}>

I guess the easiest solution for this is to wrap the code that throws the error with:

if (this.node) {
  // ...
}

So this error doesn’t happen anymore. For me it doesn’t break the functionality, It just throws the error.

Or maybe I have done something wrong with using the StickyContainer.

Can you give me any feedback on this?

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Reactions: 8
  • Comments: 16 (6 by maintainers)

Most upvoted comments

Please, merge a fix for this!

I did a fix for this (for the node being null), that we use in our code. Because currently this repo is not active developed anymore I would suggest to use my fork. I created a runnable version, that you can install with changing the version reference of react-sticky in the package.json file to:

"react-sticky": "tchock/react-sticky#6.0.1-1",

After that you need to do npm install or yarn install.

this fixes my issue.

screen shot 2018-05-27 at 8 52 51 pm

Ah sure, I see. If you unmount the node in the time between when rAF is scheduled and when it executes, the ref will be null when it runs. I’m going to see about getting a failing test case for this and explore @evan-scott-zocdoc’s comment on #207. I prefer to cancel async behavior over adding a null check.