{"id":299,"date":"2016-03-16T17:58:47","date_gmt":"2016-03-16T17:58:47","guid":{"rendered":"http:\/\/biz197.inmotionhosting.com\/~blogsi8\/2016\/03\/16\/2016browser-dgaf-that-you-use-react\/"},"modified":"2023-01-06T13:14:53","modified_gmt":"2023-01-06T21:14:53","slug":"browser-dgaf-that-you-use-react","status":"publish","type":"post","link":"https:\/\/engineering.sift.com\/browser-dgaf-that-you-use-react\/","title":{"rendered":"Browser DGAF (that you use React)"},"content":{"rendered":"

Adventures in React Performance Debugging<\/h2>\n

Recently I read Benchling\u2019s 2-part series<\/a> in debugging performance issues in React, and it really echoed the issues and solutions that I\u2019ve been working through on the Sift Science Console<\/a>. So I was inspired to chime in with some of my own React performance debugging experiences in what may become a short series itself. The first theme that I\u2019d like to touch on is that although we love using React for its one-way data flow, its easy architecture, and its ever-enlarging community, the browser really doesn\u2019t give a &^@# what you use. You still need to play nicely within it, even if that means not doing things the \u2018React way\u2019<\/a> in your components. In this post, I\u2019ll highlight how a previous version one of our components that was very clean and concise introduced some subtle performance issues, and how an uglier solution became, in fact, the better one. Because browsers DGAF<\/a>.<\/p>\n

Slidable<\/h2>\n

Our slidable component is responsible for taking content of unknown (auto) height and revealing it with a slide-down animation. As it gets new content, it slides to the new content\u2019s measured, but still auto, height. Here\u2019s a simplified version:<\/p>\n

\n
import<\/span> _<\/span> from<\/span> 'underscore'<\/span>;\r\nimport<\/span> React<\/span> from<\/span> 'react'<\/span>;\r\n\r\nconst<\/span> propTypes<\/span> =<\/span> {\r\n  \/** Function to be called after the slider finishes its animation *\/<\/span>\r\n  onChangeHeight<\/span>: React<\/span>.PropTypes<\/span>.func<\/span>,\r\n  \/**<\/span>\r\n   * Since Slidable takes in children, it's really hard to tell when the<\/span>\r\n   * children have changed. This prop helps determine when to update the <\/span>\r\n   * component<\/span>\r\n   *\/<\/span>\r\n   updateTriggerCondition<\/span>: React<\/span>.PropTypes<\/span>.any<\/span>,\r\n   \/** The duration the height change should take in ms. Default 200. *\/<\/span>\r\n   transitionDuration<\/span>: React<\/span>.PropTypes<\/span>.number<\/span>\r\n};\r\n\r\nexport<\/span> default<\/span> class<\/span> Slidable<\/span> extends<\/span> React<\/span>.Component<\/span> {\r\n  constructor<\/span>() {\r\n    super<\/span>();\r\n    \r\n    this<\/span>.state<\/span> =<\/span> {\r\n      \/** {number} - The pixel height of the container. Or `null` to set the height to auto. *\/<\/span>\r\n      height<\/span>: null<\/span>,\r\n      \/**<\/span>\r\n       * {React.Children} - reference to the previous children so that we can show them as the next transition occurs.<\/span>\r\n       *\/<\/span>\r\n      prevChildren<\/span>: null<\/span>,\r\n      \/**<\/span>\r\n        * {number} - The previous pixel height of the container, used to determine when to update.<\/span>\r\n        *    To minimize forced layouts, we saved the current height as the previous height after<\/span>\r\n        *    that height's animation.<\/span>\r\n        *\/<\/span>\r\n      prevHeight<\/span>: 0<\/span>,\r\n      \/** {boolean} - Whether or not the component is in the process of changing height. *\/<\/span>\r\n      transitioning<\/span>: false<\/span>\r\n    };\r\n  }\r\n\r\n  componentWillReceiveProps<\/span>(nextProps<\/span>) {\r\n    if<\/span> (this<\/span>.props<\/span>.updateTriggerCondition<\/span> !==<\/span> nextProps<\/span>.updateTriggerCondition<\/span>) {\r\n      this<\/span>.setState<\/span>({\r\n        prevChildren<\/span>: React<\/span>.cloneWithProps<\/span>(this<\/span>.props<\/span>.children<\/span>),\r\n        prevHeight<\/span>: React<\/span>.findDOMNode<\/span>(this<\/span>.refs<\/span>.content<\/span>).offsetHeight<\/span>,\r\n        transitioning<\/span>: false<\/span>\r\n      });\r\n    }\r\n  }\r\n\r\n  componentDidUpdate<\/span>() {\r\n    var<\/span> contentHeight<\/span> =<\/span> React<\/span>.findDOMNode<\/span>(this<\/span>.refs<\/span>.content<\/span>).offsetHeight<\/span>;\r\n\r\n    \/\/ first step in new animation: set height from 'auto' back to a number<\/span>\r\n    \/\/ so that we have a starting height.<\/span>\r\n    if<\/span> (contentHeight<\/span> !==<\/span> this<\/span>.state<\/span>.prevHeight<\/span> &&<\/span> !<\/span>this<\/span>.state<\/span>.transitioning<\/span>) {\r\n      this<\/span>.setState<\/span>({\r\n        height<\/span>: this<\/span>.state<\/span>.prevHeight<\/span>,\r\n        transitioning<\/span>: true<\/span>\r\n      }, () =><\/span> {\r\n        \/\/ we adjust height from old height (ie 0) to new height in next frame so that<\/span>\r\n        \/\/ the browser doesn't batch style changes--otherwise the animation wouldn't trigger<\/span>\r\n        window<\/span>.requestAnimationFrame<\/span>(() =><\/span> {\r\n          \/\/ use setTimeout because transitionend events fire inconsistently across browsers :(<\/span>\r\n          window<\/span>.setTimeout<\/span>(this<\/span>.onTransitionEnd<\/span>, this<\/span>.props<\/span>.transitionDuration<\/span>);\r\n          this<\/span>.setState<\/span>({height<\/span>: contentHeight<\/span>})\r\n        });\r\n      });\r\n    }\r\n  }\r\n\r\n  \/**<\/span>\r\n   * Called when the height transition ends on the container. It removes the<\/span>\r\n   * content from the DOM when the container is done sliding out, and sets<\/span>\r\n   * the height to 'auto' after the container is done sliding in.<\/span>\r\n   *\/<\/span>\r\n  onTransitionEnd<\/span>() {\r\n    this<\/span>.setState<\/span>({\r\n      height<\/span>: null<\/span>,\r\n      prevChildren<\/span>: null<\/span>\r\n    }, this<\/span>.props<\/span>.onChangeHeight<\/span>);\r\n  }\r\n\r\n  render<\/span>() {\r\n    var<\/span> contentStyle<\/span> =<\/span> {\r\n          position<\/span>: (this<\/span>.state<\/span>.height<\/span> ===<\/span> null<\/span>) ?<\/span> 'relative'<\/span> : 'absolute'<\/span>\r\n        },\r\n        containerStyle<\/span> =<\/span> {\r\n          height<\/span>: (this<\/span>.state<\/span>.height<\/span> ===<\/span> null<\/span>) ?<\/span> 'auto'<\/span> : this<\/span>.state<\/span>.height<\/span>,\r\n          transition<\/span>: `height ${<\/span>this<\/span>.props<\/span>.transitionDuration<\/span>}<\/span>ms`<\/span>\r\n        };\r\n\r\n    return<\/span> (\r\n      <<\/span>div<\/span> className<\/span>=<\/span>'Slidable'<\/span>><\/span>\r\n        <<\/span>div<\/span> ref<\/span>=<\/span>'container'<\/span> style<\/span>=<\/span>{containerStyle<\/span>} className<\/span>=<\/span>'slidable-container'<\/span>><\/span>\r\n          <<\/span>div<\/span> ref<\/span>=<\/span>'content'<\/span> style<\/span>=<\/span>{contentStyle<\/span>} className<\/span>=<\/span>'slidable-content'<\/span>><\/span>\r\n            {this<\/span>.props<\/span>.children<\/span>}\r\n            <<\/span>div<\/span> className<\/span>=<\/span>'previous-children'<\/span>><\/span>\r\n              {this<\/span>.state<\/span>.prevChildren<\/span>}\r\n            <<\/span>\/div><\/span>\r\n          <<\/span>\/div><\/span>\r\n        <<\/span>\/div><\/span>\r\n      <<\/span>\/div><\/span>\r\n    );\r\n  }\r\n}\r\n\r\nSlidable<\/span>.propTypes<\/span> =<\/span> propTypes<\/span>;\r\n\r\n\/\/ use like:<\/span>\r\n\/\/ <Slidable updateTriggerCondition={someCondition}><\/span>\r\n\/\/   <h1>Sift Science Slidables seem super slick!<\/h1><\/span>\r\n\/\/ <\/Slidable><\/span>\r\n<\/pre>\n<\/div>\n
Okay, that\u2019s not so bad! A couple notes:<\/p>\n
    \n
  1. It\u2019s really tough to determine when a component\u2019s children have changed, so we use the updateTriggerCondition<\/code> prop to explicitly tell our Slidable component that it should re-calculate the height of its new children. So every time a new updateTriggerCondition<\/code> is changed, we set the current children as our Slidable state\u2019s prevChildren<\/code> so that the previous children are still visible during the animation to the new children\u2019s height.<\/li>\n
  2. The real magic then happens in componentDidUpdate<\/code>: we calculate the new children\u2019s height, set the height state back to the previous children\u2019s height, wait a frame, and then set the new height state, triggering our sliding animation.<\/li>\n
  3. In our production component, Slidable optionally uses a CSS animation (default), a requestAnimationFrame javascript animation, or a FLIP<\/a>-style animation, but for simplicity, we\u2019ll just consider the CSS animation here.<\/li>\n<\/ol>\n
    And here it is in action as the core of our Accordion component, revealing a list of ML signals for a user:<\/p>\n
    \"Okay,
    \nOkay, it’s a gif, so…not the best quality and probably not at 60fps.<\/sub><\/p>\n
    This feels pretty React-y\u2014we\u2019re cycling through new children as they are passed in and are updating our height accordingly as state. Previous children are also kept ephemerally as state while the height adjusts. It seems to perform pretty well\u2026or does it?<\/p>\n
    Devtools gives it to you straight<\/h2>\n
    A timeline of closing the accordion above looks like this:<\/p>\n
    \"pre-slidable-update-dev\"<\/p>\n
    Huh. That\u2019s a lot of work going on after the initial click. For our users to have a good experience, we should be able to finish all our javascript within 100ms of the click (that\u2019s the R in RAIL<\/a>), and it looks like we\u2019re not close to meeting that right now. Part of the issue is that this is in development, and we\u2019re spending a lot of time validating propTypes – something we don\u2019t do in production<\/a>. But what about that animation frame stack trace after the click? And what\u2019s with those forced layouts<\/a>?<\/p>\n
    Well, the problem actually lies within our render method:<\/p>\n
    \n
    \/\/ ...<\/span>\r\n<<\/span>div<\/span> className<\/span>=<\/span>'Slidable'<\/span>><\/span>\r\n  <<\/span>div<\/span> ref<\/span>=<\/span>'container'<\/span> style<\/span>=<\/span>{containerStyle<\/span>} className<\/span>=<\/span>'slidable-container'<\/span>><\/span>\r\n    <<\/span>div<\/span> ref<\/span>=<\/span>'content'<\/span> style<\/span>=<\/span>{contentStyle<\/span>} className<\/span>=<\/span>'slidable-content'<\/span>><\/span>\r\n      {this<\/span>.props<\/span>.children<\/span>}\r\n       <<\/span>div<\/span> className<\/span>=<\/span>'previous-children'<\/span>><\/span>\r\n         {this<\/span>.state<\/span>.prevChildren<\/span>}\r\n       <<\/span>\/div><\/span>\r\n     <<\/span>\/div><\/span>\r\n   <<\/span>\/div><\/span>\r\n<<\/span>\/div><\/span>\r\n\/\/ ...<\/span><\/pre>\n<\/div>\n
    What I didn\u2019t realize was that by rendering this.props.children<\/code> and this.state.prevChildren<\/code> in different parts of the DOM, we actually unmount and then remount them<\/em> as one moves to the other\u2014even though prevChildren<\/code> is fleeting and is the exact same as the children<\/code> being unmounted. For simple children with no or light work in componentWillUnmount\/WillMount\/DidMount<\/code>, this isn\u2019t very noticeable. But in our example above, each ML signal in the list can be drag-and-dropped and thus is absolutely positioned by running a series of .getBoundingClientRect()<\/code>s after mounting. And now that work is being unnecessarily repeated.<\/p>\n
    The most apparent fix is to keep this.props.children<\/code> in the same DOM position even as it becomes this.state.prevChildren<\/code>, and simply alter the class of their containers (to adjust z-index and positioning). But to do that, we have to keep two sets of children in state as well as keep track of which one is current or which one is previous:<\/p>\n
    \n
    \/\/ ...<\/span>\r\nexport<\/span> default<\/span> class<\/span> Slidable<\/span> extends<\/span> React<\/span>.Component<\/span> {\r\n  constructor<\/span>(props<\/span>) {\r\n    \/\/ ...<\/span>\r\n\r\n    this<\/span>.state<\/span> =<\/span> {\r\n      height<\/span>: null<\/span>,\r\n      \/**<\/span>\r\n       * {React.Children} - We now cycle through two children, children0 and children1, and<\/span>\r\n       * update the classname of their container based on which one is currently the previous<\/span>\r\n       * children. Initially, children0 is current and children1 is previous, which is null.<\/span>\r\n       * After the transition, we set our previous children position to null.<\/span>\r\n       *\/<\/span>\r\n      children0<\/span>: props<\/span>.children<\/span>,\r\n      children1<\/span>: null<\/span>,\r\n      \/** {number} - reference to the which children set are the previous children *\/<\/span>\r\n      previousChildrenPosition<\/span>: 1<\/span>,\r\n      prevHeight<\/span>: 0<\/span>,\r\n      transitioning<\/span>: false<\/span>\r\n    };\r\n  }\r\n\r\n  componentWillReceiveProps<\/span>(nextProps<\/span>) {\r\n    var<\/span> newChildrenNumber<\/span> =<\/span> (this<\/span>._arePreviousChildrenPositionOne<\/span>()) ?<\/span> 1<\/span> : 0<\/span>,\r\n        newPreviousChildrenPosition<\/span> =<\/span> (this<\/span>._arePreviousChildrenPositionOne<\/span>()) ?<\/span> 0<\/span> : 1<\/span>;\r\n\r\n    if<\/span> (this<\/span>.props<\/span>.updateTriggerCondition<\/span> !==<\/span> nextProps<\/span>.updateTriggerCondition<\/span>) {\r\n      \/\/ if previous children is currently child number 2, replace it with new children<\/span>\r\n      \/\/ which would be `this.props` after update<\/span>\r\n      this<\/span>.setState<\/span>({\r\n        [`children${<\/span>newChildrenNumber<\/span>}<\/span>`<\/span>]: nextProps<\/span>.children<\/span>,\r\n        previousChildrenPosition<\/span>: newPreviousChildrenPosition<\/span>,\r\n        prevHeight<\/span>: React<\/span>.findDOMNode<\/span>(this<\/span>.refs<\/span>.content<\/span>).offsetHeight<\/span>,\r\n        transitioning<\/span>: false<\/span>\r\n      });\r\n    } else<\/span> {\r\n      \/\/ we have to update children props every time<\/span>\r\n      this<\/span>.setState<\/span>({\r\n        [`children${<\/span>newPreviousChildrenPosition<\/span>}<\/span>`<\/span>]: nextProps<\/span>.children<\/span>\r\n      });\r\n    }\r\n  }\r\n\r\n  \/\/ ...componentDidUpdate stays the same...<\/span>\r\n  \r\n  onTransitionEnd<\/span>() {\r\n    var<\/span> childrenNumberToRemove<\/span> =<\/span> (this<\/span>._arePreviousChildrenPositionOne<\/span>()) ?<\/span> 1<\/span> : 0<\/span>;\r\n\r\n    this<\/span>.setState<\/span>({\r\n      [`children${<\/span>childrenNumberToRemove<\/span>}<\/span>`<\/span>]: null<\/span>,\r\n      height<\/span>: null<\/span>\r\n    }, this<\/span>.props<\/span>.onChangeHeight<\/span>);\r\n  }\r\n\r\n  _arePreviousChildrenPositionOne<\/span>() {\r\n    return<\/span> this<\/span>.state<\/span>.previousChildrenPosition<\/span> ===<\/span> 1<\/span>;\r\n  }\r\n  \r\n  render<\/span>() {\r\n    \/\/ ...<\/span>\r\n\r\n    return<\/span> (\r\n      <<\/span>div<\/span> className<\/span>=<\/span>'Slidable'<\/span>><\/span>\r\n        <<\/span>div<\/span> ref<\/span>=<\/span>'container'<\/span> style<\/span>=<\/span>{containerStyle<\/span>} className<\/span>=<\/span>'slidable-container'<\/span>><\/span>\r\n          <<\/span>div<\/span> ref<\/span>=<\/span>'content'<\/span> style<\/span>=<\/span>{contentStyle<\/span>} className<\/span>=<\/span>'slidable-content'<\/span>><\/span>\r\n            {\/* treat each child set identically and only edit the classname for each *\/<\/span>}\r\n            <<\/span>div<\/span> className<\/span>=<\/span>{!<\/span>this<\/span>._arePreviousChildrenPositionOne<\/span>() ?<\/span> 'previous-children'<\/span> : ''<\/span>}><\/span>\r\n              {this<\/span>.state<\/span>.children0<\/span>}\r\n            <<\/span>\/div><\/span>\r\n            <<\/span>div<\/span> className<\/span>=<\/span>{this<\/span>._arePreviousChildrenPositionOne<\/span>() ?<\/span> 'previous-children'<\/span> : ''<\/span>}><\/span>\r\n              {this<\/span>.state<\/span>.children1<\/span>}\r\n            <<\/span>\/div><\/span>\r\n          <<\/span>\/div><\/span>\r\n        <<\/span>\/div><\/span>\r\n      <<\/span>\/div><\/span>\r\n    );\r\n  }\r\n}\r\n\/\/ ...<\/span><\/pre>\n<\/div>\n
    Not only is this component tougher to read, it feels much further from the React philosophy of minimizing state, since we are never actually using props.children<\/code> as props\u2014-we immediately set them as state. Additionally, and quite confusingly, children0<\/code> and children1<\/code> have no semantic notion about which is the current or previous set of children. But Browser DGAF that we want to use React best practices in our components.<\/p>\n
    Browser DGAF.<\/strong><\/p>\n
    Here is our new timeline:<\/p>\n
    \"post-slidable-update\"<\/p>\n
    No animation frame following the click handler. Beautiful!<\/p>\n
    Those red triangles, tho<\/h2>\n
    Okay, now how do we also get rid of those forced layouts (denoted by the blocks with the red triangles in the upper right)? This one is easier to debug, because we can see by zooming in that it\u2019s coming directly from the Slidable component itself:<\/p>\n
    \"layout-closeup\"<\/p>\n
    And that points to the first line in our original componentDidUpdate<\/code>:<\/p>\n
    \n
    var<\/span> contentHeight<\/span> =<\/span> React<\/span>.findDOMNode<\/span>(this<\/span>.refs<\/span>.content<\/span>).offsetHeight<\/span>;<\/pre>\n<\/div>\n
    which queries the height of the new content div on every update, causing a reflow. This brings me to my second piece of DGAF advice:<\/p>\n
    Browser DGAF about the DOM manipulation you want to put in your reusable components\u2019 componentDidMount\/Update<\/code> methods.<\/strong><\/p>\n
    So be careful! You\u2019re never totally sure of all the ways these components will be used, and they can cause significant lags in performance. This one above was only 5ms, but there are two of them, and we actually have 10 of these ML-signal accordions per page. All of a sudden that\u2019s an extra 100ms. Oops. What happens when the layout takes 20ms instead?<\/p>\n
    Wrapping that offsetHeight<\/code> call in a conditional that only executes when updateTriggerCondition<\/code> changes takes care of the second forced layout, and wrapping it in a requestAnimationFrame takes care of the first. Our very pyramid-y componentDidUpdate<\/code> now looks like this:<\/p>\n
    \n
      \/\/ ...<\/span>\r\n  componentDidUpdate<\/span>(prevProps<\/span>) {\r\n    var<\/span> contentHeight<\/span>;\r\n\r\n    if<\/span> (this<\/span>.props<\/span>.updateTriggerCondition<\/span> !==<\/span> prevProps<\/span>.updateTriggerCondition<\/span>) {\r\n      window<\/span>.requestAnimationFrame<\/span>(() =><\/span> {\r\n        contentHeight<\/span> =<\/span> React<\/span>.findDOMNode<\/span>(this<\/span>.refs<\/span>.content<\/span>).offsetHeight<\/span>;\r\n\r\n        if<\/span> (contentHeight<\/span> !==<\/span> this<\/span>.state<\/span>.prevHeight<\/span> &&<\/span> !<\/span>this<\/span>.state<\/span>.transitioning<\/span>) {\r\n          this<\/span>.setState<\/span>({\r\n            height<\/span>: this<\/span>.state<\/span>.prevHeight<\/span>,\r\n            transitioning<\/span>: true<\/span>\r\n          }, () =><\/span> {\r\n            window<\/span>.requestAnimationFrame<\/span>(() =><\/span> {\r\n              window<\/span>.setTimeout<\/span>(this<\/span>.onTransitionEnd<\/span>, this<\/span>.props<\/span>.transitionDuration<\/span>);\r\n              this<\/span>.setState<\/span>({height<\/span>: contentHeight<\/span>})\r\n            });\r\n          });\r\n        }\r\n      });\r\n    }\r\n  }\r\n  \/\/ ...<\/span><\/pre>\n<\/div>\n
    Here\u2019s our final timeline\u2014in a production build, just to prove what a difference leaving out prop validation makes:<\/p>\n
    \"post-slidable-update-prod\"<\/p>\n
    That click work takes less than 20ms!<\/p>\n
    By the way, astute readers may see that our frame rate during the animation is well under 60fps. This is partly because, as mentioned above, we\u2019re animating height with CSS, which means heavy repainting (and apparently style updating?) of everything below the expanding div. While not the point of this post, FLIP<\/a>-ing your height animations would easily make this run 60fps. FLIP-ing is also pretty messy in React, and would make a great follow-up post in this series, so stay tuned!<\/p>\n
    And remember: Browser DGAF.
    \n