All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.
Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.
elem.offsetLeft, elem.offsetTop, elem.offsetWidth, elem.offsetHeight, elem.offsetParent
| // Demo: http://jsfiddle.net/pFaSx/ | |
| // Create an invisible iframe | |
| var iframe = document.createElement('iframe'); | |
| iframe.id = "hacky-scrollbar-resize-listener"; | |
| iframe.style.cssText = 'height: 0; background-color: transparent; margin: 0; padding: 0; overflow: hidden; border-width: 0; position: absolute; width: 100%;'; | |
| // Register our event when the iframe loads | |
| iframe.onload = function() { | |
| // The trick here is that because this iframe has 100% width |
(by @andrestaltz)
If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.
| My thoughts on writing tiny reusable modules that each do just one | |
| thing. These notes were adapted from an email I recently sent. | |
| *** | |
| If some component is reusable enough to be a module then the | |
| maintenance gains are really worth the overhead of making a new | |
| project with separate tests and docs. Splitting out a reusable | |
| component might take 5 or 10 minutes to set up all the package | |
| overhead but it's much easier to test and document a piece that is |