Replace gridster with react-grid-layout

[stacey-gammon]

Replaces gridster with react-grid-layout and and reactifies the dashboard panels and headers.

Makes some UI changes that are nearer inline with k7:

Also allows moving the panel on the entire panel header, no longer just on a move icon, which has been something requested for awhile (#7927)

As for placing panels, I had to manually come up with an algorithm to find the best spot because the default that react-grid-layout gives isn't great, and doesn't match prior functionality. It will find the first spot that fits the new panel with first the lowest y value then the lowest x.

[stacey-gammon]

s3 upload error

Jenkins, test this

[stacey-gammon]

s3 error again, technically all the tests passed.

[kobelb]

This is great work, all of the additional tests are just great.

The following error is being logged in the Browser console:

warning.js:36 Warning: Failed prop type: The prop `onPanelUpdated` is marked as required in `DashboardGrid`, but its value is `undefined`.
    in DashboardGrid

angular.js:14642 TypeError: onPanelUpdated is not a function
    at dashboard_grid.js:103
    at Array.forEach (<anonymous>)
    at Object.DashboardGrid._this.onLayoutChange (dashboard_grid.js:91)
    at ReactGridLayout.onLayoutMaybeChanged (ReactGridLayout.js:204)
    at ReactGridLayout.componentDidMount (ReactGridLayout.js:66)
    at ReactCompositeComponent.js:264
    at measureLifeCyclePerf (ReactCompositeComponent.js:75)
    at ReactCompositeComponent.js:263
    at CallbackQueue.notifyAll (CallbackQueue.js:76)
    at ReactReconcileTransaction.close (ReactReconcileTransaction.js:80)

Apparently unrelated, the batched requests that courier does are behaving weirdly on master and I'm seeing 2 _msearch calls for a dashboard with 2 of the same visualization. I noticed the behavior initially with this PR and thought that the asynchronous manner that we were called this.embeddableHandler.render was the culprit, but the behavior is present before these changes. Definitely something we should keep an eye on, to ensure this PR doesn't have any impact as well.

[kobelb]

If we were to change this code to:

this.embeddableHandler.getEditPath(panel.id).then(editUrl => this.setState({ editUrl }));
this.embeddableHandler.getTitleFor(panel.id).then(title => this.setState({ title }));

it'd be roughly in-line with the first "not a warning" case outline here, with the sole difference being they're using callbacks instead of Promise.

Even with Redux, we'll still be using actions to queue off async actions in ComponentDidMount, but the updated data will be coming through via our props as opposed to the state.

[kobelb]

Why are we waiting for the title/editUrl to be available before calling this.embeddableHandler.render they don't seem to be dependent on each other? If we did the above suggestion, and queued off this async request immediately, I'm not seeing the reason for us to track the _isMounted, but we could just use the this.destroyEmbeddable !== null) check directly in the componentDidUnmount call.

[stacey-gammon]

I need isMounted check before the setStates or I can get:
Warning: setState(...): Can only update a mounted or mounting component. This usually means you called setState() on an unmounted component. This is a no-op. Please check the code for the DashboardPanel component.

I can still use your above suggestion but I don't think I can get rid of isMounted. Instead it will look like this:

    this.embeddableHandler.getEditPath(panel.id).then(editUrl => {
      if (this._isMounted) { this.setState({ editUrl }); }
    });

    /* eslint-disable react/no-did-mount-set-state */
    this.embeddableHandler.getTitleFor(panel.id).then(title => {
      if (this._isMounted) { this.setState({ title }); }
    });

    this.destroyEmbeddable = await this.embeddableHandler.render(
      this.panelElement,
      panel,
      this.containerApi);

fwiw, the redux variation gets rid of all this. I actually changed this.embeddableHandler.render to return an Embeddable, which contains state for the rendered embeddable, including title and editUrl - so there is only one async call, not three - https://github.com/elastic/kibana/pull/14103/files#diff-a18d16d17e2c646a166a4d5523608fbfR86/

Why are we waiting for the title/editUrl to be available before calling this.embeddableHandler.render

Wasn't intentional, I just liked the await syntax. Updated to your suggestion.

[kobelb]

Ah, gotcha. Pretty excited about the redux changes coming, that makes sense.

[stacey-gammon]

@kobelb -Good catch on the onUpdatedPanel warning. That code was actually part of the Redux PR that snuck in. I reverted it back.

I filed an issue for the msearch concerns so that can be looked into separately: #14128

[kobelb]

All my concerns have been addressed, once CI goes green you'll have my LGTM!

[stacey-gammon]

I discovered an issue with the panels being unmounted/mounted too frequently and causing slow dashboard refreshes on edit/view mode change, due to this bug: react-grid-layout/react-grid-layout#240.

Found another bug where the grid was being rendered with width 0, then not rerendered, showing all the panels shoved to one side.

[nreese]

LGTM