Visible Time Start/End calling onTimeChange on mount when page is intially loaded

[Zanoro9000]

Describe the bug I've spent a decent amount of time tracking this down and it may not be a bug, I just may need more clarification. What I understand to be happening is I am manually setting visibleTimeStart/End on my timeline.

• On mount of the timeline, it calls this.resize()
• resize sets the scrollLeft to a value outside its .scrollLeftMax and is essentially ignored (because the width of the scroll container isn't known at this point on the initial load)
• This triggers the following code in componentDidUpdate due to the prevState.width being the default 1000 not the true width

if (componentScrollLeft !== scrollLeft) { this.scrollComponent.scrollLeft = scrollLeft this.scrollHeaderRef.scrollLeft = scrollLeft }

• This now sets the scroll to a valid value now that the container is properly sized
• This then triggers the onScroll event for the container and those calculations end up triggering an onTimeChange call due to the scrollContainer 'scrolling' to a new location and not showing the intended date range

To Reproduce

I cannot get the example with provided visibleTimeStart/End working for me, but if there's a response and needs further clarification I can try to cobble together something.

Expected behavior I expect the scroll event to not trigger or to somehow have the widths figured out so that it doesn't call onTimeChange on the initial render.

Screenshots This is the expected range - this can be gotten from navigating to the page from another page

This is the range after it jitters from the initial (ex. when loading the page from refresh)

Library Version 0.27.0

Desktop (please complete the following information):

• OS: Windows
• Browser: Firefox/Chrome
• Version: Latest

Additional context Add any other context about the problem here.

Love the package so far! Thanks for making this available.

[stahlmanDesign]

I don't know if my issue is related or not, but I also have "jitter" or "snapping" that I believe is caused by scroll events calling onTimeChange internally or unpredictably with a controlled timeline (visibleTimeStart/End). I also had trouble building a simplified example to reproduce.