You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Due to the asynchronous nature of rendering in React, there's a window in time where one might have mutated an element's scrollLeft property and where the page still appear to be rendering elements based on the previous value. This is insignificantly small to affect the user experience, but it does affect attempts to automate interaction.
We have an unsorted, virtualized table, which we test. Our tests mimics user behavior and "searches" the table by resetting scrollTop and scrolling iteratively until the target can be found. However, when resetting scrollTop or increasing it, we have to wait a fixed amount of time to "be sure" that the table has in fact re-rendered, otherwise we risk re-querying the same values and scrolling past the target. The browser can be quite busy in our case, so this becomes significant.
By exposing scrollOffset and rendering it as part of the DOM (think data-scroll-offset={scrollOfset}), we can mutate scrollTop and simply wait for the attribute to change. This time is almost always insignificant and the approach much more preferable than adding default, static waits to every test and slowing the entire suite.
We solved this in 2.4.10 with patch-package and the following patch, and this works well.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Hi,
Due to the asynchronous nature of rendering in React, there's a window in time where one might have mutated an element's
scrollLeft
property and where the page still appear to be rendering elements based on the previous value. This is insignificantly small to affect the user experience, but it does affect attempts to automate interaction.We have an unsorted, virtualized table, which we test. Our tests mimics user behavior and "searches" the table by resetting
scrollTop
and scrolling iteratively until the target can be found. However, when resettingscrollTop
or increasing it, we have to wait a fixed amount of time to "be sure" that the table has in fact re-rendered, otherwise we risk re-querying the same values and scrolling past the target. The browser can be quite busy in our case, so this becomes significant.By exposing
scrollOffset
and rendering it as part of the DOM (thinkdata-scroll-offset={scrollOfset}
), we can mutatescrollTop
and simply wait for the attribute to change. This time is almost always insignificant and the approach much more preferable than adding default, static waits to every test and slowing the entire suite.We solved this in 2.4.10 with patch-package and the following patch, and this works well.
My question is, can you expose this state?
Beta Was this translation helpful? Give feedback.
All reactions