[sql lab] Make sql editor resizable

[dmigo]

Implements #2237

The idea of this PR is to be able to resize the editor of the sql lab.

[coveralls]

Coverage remained the same at 69.34% when pulling 8c9a8311f5b4909e6fcbd8bffe8b6df917ec8c2f on dmigo:master into 4c3313b on apache:master.

[coveralls]

Coverage remained the same at 69.34% when pulling a4079c3391b884badb32886371fb9f3ad1007e67 on dmigo:master into 4c3313b on apache:master.

[coveralls]

Coverage remained the same at 69.34% when pulling 78c00e3fbfcb15c1269f845c2e8be9d4341b5e88 on dmigo:master into 4c3313b on apache:master.

[coveralls]

Coverage remained the same at 69.34% when pulling 78c00e3fbfcb15c1269f845c2e8be9d4341b5e88 on dmigo:master into 4c3313b on apache:master.

[mistercrunch]

Glad to see you're working on this. There was some issues in SQL Lab around resizing the window where the height of some components wouldn't be altered as they should. Please make sure resizing the window work well along with this set of changes.

[dmigo]

@mistercrunch I encountered 2 problems with resizing while working on this PR.
First: it wasn't possible to resize react-ace properly it had some issues. This one is solved by updating to the version 5.1.2.
Second: Sql Lab has one hack in it. This hack adjusts sizes of some parts of the page. I didn't fix it, since it is out of scope of the PR, however I have a couple of ideas about it.

Update: tried to resize the browser's window in different ways - seems to work.

[coveralls]

Coverage increased (+0.2%) to 69.311% when pulling ab0e0165e7e51cde05f5ee5dcf8a7d34ce2084f8 on dmigo:master into ef7e9dd on apache:master.

[coveralls]

Coverage remained the same at 69.311% when pulling ab0e0165e7e51cde05f5ee5dcf8a7d34ce2084f8 on dmigo:master into ef7e9dd on apache:master.

[coveralls]

Coverage remained the same at 69.311% when pulling ab0e0165e7e51cde05f5ee5dcf8a7d34ce2084f8 on dmigo:master into ef7e9dd on apache:master.

[coveralls]

Coverage remained the same at 69.311% when pulling 6f07444157cb45e7bce5148f6a89400979672b7e on dmigo:master into ef7e9dd on apache:master.

[coveralls]

Coverage remained the same at 69.311% when pulling 6f07444157cb45e7bce5148f6a89400979672b7e on dmigo:master into ef7e9dd on apache:master.

[coveralls]

Coverage remained the same at 69.311% when pulling 6f07444157cb45e7bce5148f6a89400979672b7e on dmigo:master into ef7e9dd on apache:master.

[mistercrunch]

I pulled the branch and tried it. It mostly works but it's a little funky. We went from single-page app to no-quite that where there's one too many scrollbars on the lower right panel.

I don't think the lower-right panel should have a fixed height anymore. Meaning if/when you scroll down to look at the data in the result pane the SQL Editor would flow out of the screen, leaving more place for to browse the results.

[mistercrunch]

I'd also like to have a minimum height constraint on the SQL editor, so that users can't get confused as to it completely disappearing.

[mistercrunch]

no scroll on the lower right and minimum height on SQL editor

[dmigo]

@mistercrunch got it 👍

[dmigo]

@mistercrunch
It is going to be hard with

no scroll on the lower right

On the lower right many tabs have react-virtualized which doesn't support scroller on the nesting element out of the box.
We could create our own component for that, or try to extend react-virtualized.
Either way it seems to be a separate big task.

Another one possible solution would be to have one common scroller for the page. Instead of two separate scrollers for the two columns we have.

We could also go the jsfiddle way. it is simply not possible to extend anything there so, that some part of the page goes beyond the screen.

[coveralls]

Coverage remained the same at 69.311% when pulling b91e95a on dmigo:master into 0429e84 on apache:master.

[coveralls]

Coverage remained the same at 69.311% when pulling b91e95a on dmigo:master into 0429e84 on apache:master.

[coveralls]

Coverage decreased (-0.08%) to 69.234% when pulling 1b3430f on dmigo:master into 0429e84 on apache:master.

[coveralls]

Coverage decreased (-0.08%) to 69.234% when pulling 1b3430f on dmigo:master into 0429e84 on apache:master.

[coveralls]

Coverage decreased (-0.08%) to 69.234% when pulling 1b3430f on dmigo:master into 0429e84 on apache:master.

[mistercrunch]

Right, sorry I didn't think that through. Then it should probably just be a full-page app, same as jsfiddle works for me.

[dmigo]

@mistercrunch
That wasn't easy, but currently this PR seems to consider all that there is on the page.
The functionality is ready for a usability test. However I would like to put some more work into this PR. I'll list the todos in the main commit.

[coveralls]

Coverage remained the same at 69.388% when pulling 90d0dc8 on dmigo:master into e31ad22 on apache:master.

[coveralls]

Coverage remained the same at 69.388% when pulling 90d0dc8 on dmigo:master into e31ad22 on apache:master.

[dmigo]

@mistercrunch it is ready in terms of code. Should I squash all the changes into one commit?

[coveralls]

Coverage remained the same at 69.388% when pulling 20bbb07 on dmigo:master into e31ad22 on apache:master.

[coveralls]

Coverage remained the same at 69.388% when pulling 20bbb07 on dmigo:master into e31ad22 on apache:master.

[coveralls]

Coverage remained the same at 69.388% when pulling 20bbb07 on dmigo:master into e31ad22 on apache:master.

[mistercrunch]

Not need to squash, we use the Github "Squash and merge" button. Let me try it out!

[mistercrunch]

[mistercrunch]

@dmigo found a bug related to this, when popping a new tab things don't init right:

[dmigo]

@mistercrunch sorry, didn't notice the comment in time. Did #3363 solved all the problems?

[mistercrunch]

Everything is good now, leveraging react-split-panes abstracted a lot of the complexities