Kill unnecessary re-renders in ElementWrapper

[clintandrewhall]

Summary (fixes #29700)

This is a small change that creates a huge impact on UI performance in Canvas.

As the mouse moves over a workpad, several parts of the state of the workpad, (the element hovered, the element moved if one is being held, etc) change. These changes in state were causing every active Element to re-render in React.

In short, you may hover Element 10, but Elements 1-9 re-render because the state of the entire workpad changes. This would happen even if the mouse were moved a single pixel.

By short-circuiting that re-render with a fast comparison, we prevent any Elements that are not affected from re-rendering... freeing up the main thread. This performance impact intensifies as one adds Elements to the workpad.

Here is a performance shapshot before this change was made. Notice the React tree reconciliation encompasses the entire 280ms. This reflects a single state change flowing through all of the Elements on the workpad, (each orange "stalactite" descending downwards is an Element):

Here is a snapshot after. That reconciliation now completes in 50ms or less:

This is not the end of this problem. There are many other opportunities to prevent re-rendering, and we need to focus on killing the need for the comparison in the first place. @monfera and @w33ble will be instrumental in making these changes in the future... for now, though, this gets the job done.

Checklist

Use strikethroughs to remove checklist items you don't feel are applicable to this PR.

• This was checked for cross-browser compatibility, including a check against IE11
• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
• This was checked for keyboard-only and screenreader accessibility

For maintainers

• This was checked for breaking API changes and was labeled appropriately
• This includes a feature addition or change that requires a release note and was labeled appropriately

[elasticmachine]

Pinging @elastic/kibana-canvas

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[monfera]

LGTM, great change!

There's some minor yarn.lock conflicts due to earlier merges.

Apparently unrelated to this PR or your preceding PR (EventEmitters leak), but I saw this just now, after doing some crazyman drag&drop testing (15-20 shapes and one uploaded image being dragged and dropped prolifically): <= @w33ble just told me this warning has been around for a while when an image is present, so pls. ignore this from the angle of this PR

Warning: Can't perform a React state update on an unmounted component. This is a no-op, but it indicates a memory leak in your application. To fix, cancel all subscriptions and asynchronous tasks in the componentWillUnmount method.
    in withState(withState(lifecycle(Connect(branch(ArgFormComponent))))) (created by withState(withState(withState(lifecycle(Connect(branch(ArgFormComponent)))))))
    in withState(withState(withState(lifecycle(Connect(branch(ArgFormComponent)))))) (created by FunctionFormComponent)
    in div (created by EuiPanel)
    in EuiPanel (created by SidebarSection)
    in SidebarSection (created by FunctionFormComponent)
    in div (created by FunctionFormComponent)
    in FunctionFormComponent (created by branch(FunctionFormComponent))
    in branch(FunctionFormComponent) (created by branch(branch(FunctionFormComponent)))
    in branch(branch(FunctionFormComponent)) (created by branch(branch(branch(FunctionFormComponent))))
    in branch(branch(branch(FunctionFormComponent))) (created by Connect(branch(branch(branch(FunctionFormComponent)))))
    in Connect(branch(branch(branch(FunctionFormComponent)))) (created by FunctionFormList)

[w33ble]

FYI, when I try to merge master and bootstrap to fix the yarn conflict, I get a build error on some types in the i18n package. No idea what's up with that, but the conflict might be tricky to fix because of it...

[monfera]

Wondering how it can happen as this PR seems to have no i18n aspect on a superficial look. Maybe rebasing it on current master would fix whatever glitch is preventing it. Btw. I saw it in full green (no merge conflict, and CI passed), no idea if me merging Clint's other PR caused the merge conflict or build issue, or something unrelated that went in during that approx. one hour (other folks merged to master too).

[w33ble]

Can confirm that the re-renders on mouse move is no longer an issue. There's still seemingly still a lot of re-renders happening when you move things around, but this is an awesome start!

[w33ble]

One question, but this looks good. The app seems to load a big faster, and interactions seem smoother too. I'm not sure how much of that is placebo, but I'll take it 😉.

I was hoping that this might fix #25070, but no dice, it's still really laggy. All the same, this is a win.

   __    ___  _____           _ 
  / /   / _ \/__   \/\/\     / \
 / /   / /_\/  / /\/    \   /  /
/ /___/ /_\\  / / / /\/\ \ /\_/ 
\____/\____/  \/  \/    \/ \/   
                                

[w33ble]

Do we need this in the package? You're not using it anywhere, and it seems easy enough to only pull it in locally when you want to diagnose re-renders.

[monfera]

@clintandrewhall @w33ble since it's a personal feature branch, I can't push a commit to it (I contemplated merging it haha), but here's what I did:

1. Remove why-did-you-update from package.json (though it's a devDependency and seems useful enough to have it around)
2. Restore yarn.lock to what it was before - the yarn.lock diff in this PR has all kinds of version number differences
3. Rebase on current master - might not be necessary
4. Run yarn kbn bootstrap, it completes nicely and yarn.lock is good

[monfera]

... looks like we have this perf enhancement opportunity in 24 other components that use connect in Canvas and maybe more that don't - as you said, the real solution is flattening out state and props to more closely tie viewModels to views and I guess to avoid somewhat expensive equality checks

[w33ble]

Most of the connect use probably isn't an issue, but where it is, or where the selector is the issue (as in this PR), I agree, there's big opportunity for performance gains.

[clintandrewhall]

I'm already investigating more improvements... I'll keep shipping them as I find them! See #31779.

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request