$30 off During Our Annual Pro Sale. View Details »

Breaking React apart Fiber by Fiber

r31gN_
October 14, 2017

Breaking React apart Fiber by Fiber

React still continues to dominate a decent chunk of the frontend frameworks space. The team behind it is relentless in moving React forward, thus a new (currently in beta) implementation (complete, fully backwards compatible re-write) of the core algorithm was the next logical step. Fiber is what makes React faster and more powerful. In this talk we are going to take a dive into how Fiber works, how is it different and what can you do to use it and take advantage of the improvements it brings.

r31gN_

October 14, 2017
Tweet

More Decks by r31gN_

Other Decks in Technology

Transcript

  1. Breaking React apart
    Fiber by Fiber

    View Slide

  2. @r31gN_
    Consultant, JS Instructor, GDE
    https://krak3n.co

    View Slide

  3. What is React Fiber?

    View Slide

  4. Old Reconciler Rendering

    View Slide

  5. Fiber Rendering

    View Slide

  6. What’s new in React Fiber?
    ● Perceived performance improvements
    ● Error boundaries
    ● Support for custom DOM attributes
    ● Render can return multiple children
    ● Streaming support for SSR
    ● Others?

    View Slide

  7. Perceived performance
    improvements

    View Slide

  8. Work Queue
    UI Thread
    (each frame ~ 16ms)
    Old Reconcilier

    View Slide

  9. Work Queue
    UI Thread
    1
    Old Reconcilier
    (each frame ~ 16ms)

    View Slide

  10. Work Queue
    UI Thread
    1
    1
    (takes more than one frame)
    Old Reconcilier
    (each frame ~ 16ms)

    View Slide

  11. Work Queue
    UI Thread 1
    (junky UI)
    2
    2
    3
    3
    Old Reconcilier
    (each frame ~ 16ms)

    View Slide

  12. In its current implementation React walks the tree recursively and calls render functions of
    the whole updated tree during a single tick. However in the future it might start delaying
    some updates to avoid dropping frames.
    [...]
    If something is offscreen, we can delay any logic related to it. If data is arriving faster than the
    frame rate, we can coalesce and batch updates. We can prioritize work coming from user
    interactions (such as an animation caused by a button click) over less important background
    work (such as rendering new content just loaded from the network) to avoid dropping
    frames.
    React’s Design Principles

    View Slide

  13. What’s different about React Fiber?

    View Slide

  14. React Fiber
    ● Completely backwards* compatible re-write of the reconciliation
    algorithm
    ● Promotes incremental rendering (splitting work)
    ● Has the ability to pause, resume, abort, reuse work and assign priorities
    to updates
    ● Achieves all that by declaring and using a new entity - fiber

    View Slide

  15. What’s a fiber?

    View Slide

  16. Defining a fiber
    ● A unit of work
    ● React Fiber is a React specialized reimplementation of the stack, so a fiber
    is a virtual stack frame
    ● A JS object containing information about a component, its input and
    output

    View Slide

  17. {
    type,
    key,
    child,
    sibling,
    return,
    pendingProps,
    memoizedProps,
    pendingWorkPriority,
    output,
    ...
    }

    View Slide

  18. {
    type,
    key,
    child,
    sibling,
    return,
    pendingProps,
    memoizedProps,
    pendingWorkPriority,
    output,
    ...
    }
    The type of a fiber describes the
    component that it corresponds to (e.g.:
    MyComponent, “div”)
    The key is used during reconciliation to
    determine whether the fiber can be
    reused (same as in the old algorithm).

    View Slide

  19. {
    type,
    key,
    child,
    sibling,
    return,
    pendingProps,
    memoizedProps,
    pendingWorkPriority,
    output,
    ...
    }
    These fields point to other fibers,
    describing the recursive tree structure of
    a fiber.

    View Slide

  20. {
    type,
    key,
    child,
    sibling,
    return,
    pendingProps,
    memoizedProps,
    pendingWorkPriority,
    output,
    ...
    }
    The return fiber is the fiber to which the
    program should return after processing
    the current one. It is conceptually the
    same as the return address of a stack
    frame.

    View Slide

  21. {
    type,
    key,
    child,
    sibling,
    return,
    pendingProps,
    memoizedProps,
    pendingWorkPriority,
    output,
    ...
    }
    Conceptually, props are the arguments
    of a function. A fiber's pendingProps are
    set at the beginning of its execution, and
    memoizedProps are set at the end.
    When the incoming pendingProps are
    equal to memoizedProps, it signals that
    the fiber's previous output can be
    reused, preventing unnecessary work.

    View Slide

  22. {
    type,
    key,
    child,
    sibling,
    return,
    pendingProps,
    memoizedProps,
    pendingWorkPriority,
    output,
    ...
    }
    A number indicating the priority of the
    work represented by the fiber.

    View Slide

  23. {
    type,
    key,
    child,
    sibling,
    return,
    pendingProps,
    memoizedProps,
    pendingWorkPriority,
    output,
    ...
    }
    Output is created only at the leaf nodes
    by host components (e.g.: div, span, etc.).
    The output is then transferred up the
    tree.

    View Slide

  24. Work Queue
    UI Thread
    (each frame ~ 16ms)
    1
    Fiber

    View Slide

  25. Work Queue
    UI Thread
    1
    Fiber
    (each frame ~ 16ms)

    View Slide

  26. Work Queue
    UI Thread
    1
    Fiber
    (each frame ~ 16ms)

    View Slide

  27. Work Queue
    UI Thread
    1
    (work gets split over multiple frames)
    Fiber
    (each frame ~ 16ms)

    View Slide

  28. Work Queue
    UI Thread
    2
    Fiber
    (each frame ~ 16ms)

    View Slide

  29. Work Queue
    UI Thread
    2
    Fiber
    3
    (each frame ~ 16ms)

    View Slide

  30. Work Queue
    UI Thread
    2
    Fiber
    3
    (each frame ~ 16ms)

    View Slide

  31. Work Queue
    UI Thread
    2
    Fiber
    3
    (each frame ~ 16ms)

    View Slide

  32. Work Queue
    UI Thread
    2
    Fiber
    3
    (each frame ~ 16ms)

    View Slide

  33. Work Queue
    UI Thread
    2
    (no more janky UI, < 16ms)
    Fiber
    3
    (each frame ~ 16ms)

    View Slide

  34. Performance demo

    View Slide

  35. Error boundaries demo

    View Slide

  36. DOM changes demo

    View Slide

  37. Is Fiber ready to be used?

    View Slide

  38. Resources
    ● Andrew Clark’s Fiber architecture guide
    ● Lin Clark’s presentation (A cartoon intro to Fiber)
    ● Deep dive in Fiber
    ● Error handling in React 16
    ● DOM attributes in React 16

    View Slide

  39. Keep on smiling because you are the
    most beautiful people when you do

    View Slide

  40. Thank you!
    @r31gN_

    View Slide