{"id":1607,"date":"2016-09-21T20:05:25","date_gmt":"2016-09-22T03:05:25","guid":{"rendered":"http:\/\/engineering.siftscience.com\/?p=1607"},"modified":"2023-01-06T13:14:14","modified_gmt":"2023-01-06T21:14:14","slug":"browser-dgaf-use-react-pt-2-flipping-react","status":"publish","type":"post","link":"https:\/\/engineering.sift.com\/browser-dgaf-use-react-pt-2-flipping-react\/","title":{"rendered":"Browser DGAF (that you use React) Pt. 2: FLIPping in React"},"content":{"rendered":"

In the first post in this series<\/a><\/span>, we looked at how coding within the React paradigm could lead to poor browser performance. We fixed a couple of those issues in the context of an auto-height, slide-down animation, but let\u2019s look at the timeline we finished with:<\/span><\/p>\n

\"post-slidable-update-prod\"<\/p>\n

As you can see, we\u2019re busting a lot of frames with some heavy style recalculations and layouts, and we\u2019re definitely not hitting 60fps. The reason for this is that we\u2019re still animating the height property, and the height property changes the position of all of its neighbors. This means that in <\/span>every frame<\/span><\/i>, the browser has to recalculate styles and positioning for all surrounding elements (and, in reality, every element on the page\u2014until we have CSS containment<\/a><\/span>). \u00a0Hence we\u2019re not making 60fps\u2014our work per frame is just too much. You can see an example of the janky animation in this Codepen<\/a>:<\/span><\/p>\n

See the Pen Slidable, no-FLIP, React<\/a> by Noah Grant (@noahgrant<\/a>) on CodePen<\/a>.<\/p>\n