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
Is your feature request related to a problem? Please describe.
Layout thrashing is when someone modifies or accesses (!) some layout properties of a DOM node that triggers the browser layout calculations. Something as simple as
consttop=element.offsetTop
can generate more work for the browser. This kind of properties are commonly used in scroll/resize/mouse events and can lead to janky behavior.
Describe the solution you'd like
We can create a custom rule to check for member expressions with certain identifiers, such as offsetLeft, offsetTop, offsetWidth, offsetHeight, offsetParent, clientLeft, clientTop, clientWidth, clientHeight, getClientRects, getBoundingClientRect and much more. See this GIST for more examples: https://gist.github.com/paulirish/5d52fb081b3570c81e3a. The rule would be turned on as a warning and not an error and developers could choose to ignore it if they know what they're doing.
The first problem with this approach is that it can lead to some false positives:
consta={offsetTop: 20}a.offsetTop// would trigger a warning
I'm okay with these kind of false positives, since it's easy to add a ignore line. However, we could also try checking how the @typescript-eslint uses type information to only check for variables that are instance of HTMLElement or something like that.
I think the benefits of warning people about these kind of performance issues is way greater than expecting people without much experience on how the browser works to write performant code.
The text was updated successfully, but these errors were encountered:
I think we need to configure a rule for that, even if we have false positives as you say.
Just one real case that I recently identified on a screen on Indeva system to show that the impacts of this are too costly (just caching access to the clientWidth, in this case, increased the performance from 4.2s to 60ms)
Is your feature request related to a problem? Please describe.
Layout thrashing is when someone modifies or accesses (!) some layout properties of a DOM node that triggers the browser layout calculations. Something as simple as
can generate more work for the browser. This kind of properties are commonly used in
scroll
/resize
/mouse
events and can lead to janky behavior.Describe the solution you'd like
We can create a custom rule to check for member expressions with certain identifiers, such as
offsetLeft
,offsetTop
,offsetWidth
,offsetHeight
,offsetParent
,clientLeft
,clientTop
,clientWidth
,clientHeight
,getClientRects
,getBoundingClientRect
and much more. See this GIST for more examples: https://gist.github.com/paulirish/5d52fb081b3570c81e3a. The rule would be turned on as awarning
and not an error and developers could choose to ignore it if they know what they're doing.The first problem with this approach is that it can lead to some false positives:
I'm okay with these kind of false positives, since it's easy to add a
ignore
line. However, we could also try checking how the@typescript-eslint
uses type information to only check for variables that are instance ofHTMLElement
or something like that.I think the benefits of warning people about these kind of performance issues is way greater than expecting people without much experience on how the browser works to write performant code.
The text was updated successfully, but these errors were encountered: