The this.isSticky !== newIsSticky is resulting in the this.isSticky being toggled.
The newIsSticky is being changed when the width changes because of several reasons, each being independent problems:
1) On systems where the parent has a height of 100%, the compareHeight is always the window height.
2) When this.isSticky is true and the height of the footer suddenly changes (such as a login button dropping below).
3) The calculation is (conditionally) subtracting the footer height from the window height.
4) The sticky height and the non-sticky height are different.
The solution is to:
1) Save the state of the total height of the parent for when the footer is not sticky (or best available dimensions).
2) Always calculate against the height as if it were not sticky, regardless of the state of this.isSticky.
3) What matters is the relationship between the window height and the total height, compare against that only.
4) Because this is potentially being called a lot, be pickier about boolean logic to reduce performance concerns.
5) The @debounce and a lock strategies have proven to be problematic in this case.*
6) I am unsure if I should use <= or >= (as opposed to < or >), I have opted to only change sticky when necessary (therefore using < and >).
*) In the case of a lock, the lock works except that it should not lock the clientWidth assignment.
As this change is outside the scope of this bug fix, I have withheld the lock approach.
I suggest future changes to consider a lock (but not a debounce) that does not include locking out the width adjustment.
The
this.isSticky !== newIsStickyis resulting in thethis.isStickybeing toggled. ThenewIsStickyis being changed when the width changes because of several reasons, each being independent problems: 1) On systems where the parent has a height of100%, thecompareHeightis always the window height. 2) Whenthis.isStickyis true and the height of the footer suddenly changes (such as a login button dropping below). 3) The calculation is (conditionally) subtracting the footer height from the window height. 4) The sticky height and the non-sticky height are different.The solution is to: 1) Save the state of the total height of the parent for when the footer is not sticky (or best available dimensions). 2) Always calculate against the height as if it were not sticky, regardless of the state of
this.isSticky. 3) What matters is the relationship between the window height and the total height, compare against that only. 4) Because this is potentially being called a lot, be pickier about boolean logic to reduce performance concerns. 5) The@debounceand a lock strategies have proven to be problematic in this case.* 6) I am unsure if I should use<=or>=(as opposed to<or>), I have opted to only change sticky when necessary (therefore using<and>).*) In the case of a lock, the lock works except that it should not lock the clientWidth assignment. As this change is outside the scope of this bug fix, I have withheld the lock approach. I suggest future changes to consider a lock (but not a debounce) that does not include locking out the width adjustment.
resolves: https://github.com/TAMULib/tamu-library-components/issues/369