-
Notifications
You must be signed in to change notification settings - Fork 8.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Dashboard] New layout engine #174132
[Dashboard] New layout engine #174132
Conversation
…ontents callback.
/ci |
/ci |
/ci |
Pinging @elastic/kibana-presentation (Team:Presentation) |
The grid layout feels really snappy and smooth. One negative thing I have noticed when comparing the new layout system to the old layout system is that the shadow element (green box) and real element are switched. In the old system, the real element is attached to your mouse movements and is on top of the shadow element (red box). This feels really natural and easy to track since the real element is opaque and the shadow element is mostly covered up. In the new system, the shadow element is attached to your mouse movements and is on top of the real element. I found this unnatural. The shadow element is translucent and its easy for your eye to get stuck on the real element underneath which is not attached to mouse movements. Moving the panel around feels less natural because your eye is focused on the real element which does not directly track mouse movement, making shadow element more distracting. Is there a reason for this change? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
examples/grid_example/README.md
Outdated
@@ -0,0 +1,3 @@ | |||
# Grid Example | |||
|
|||
This temporary example plugin will be used to build out the new layout engine for Dashboards. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lets not make this temporary. It would be nice to have a playground for the layout engine outside of dashboard. Plus, its a good learning resource without all the noise of dashboard implementation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Addressed in 75a4e51
developerExamples.register({ | ||
appId: GRID_EXAMPLE_APP_ID, | ||
title: gridExampleTitle, | ||
description: `This temporary example plugin will be used to build out the new layout engine for Dashboards.`, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
again, lets change wording to call it a playground for the layout engine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Addressed in 75a4e51
{gridLayout.map((rowData, rowIndex) => { | ||
return ( | ||
<GridRow | ||
key={rowIndex} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about using rowData.title as key since index is not a recommended key?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch! Addressed in 75a4e51
Good callout. This change was made mostly for its implementation simplicity. It's much more natural from a code perspective to move the actual element around in CSS grid coordinates and have the ghost follow the mouse position. I also felt like it gave a better preview of what the grid will look like on drop. That said, I can see how this could feel jarring. To fix this problem we could either:
@andreadelrio what do you think about this drawback?
Looks like this is a problem with the example plugin. I will look into propagating dark mode into it. Dark mode works great with the engine in Dashboard. |
This is a good place to start |
I would consider this a significant drawback of the new layout engine. I think the behavior should be as before: mouse movement attached to real element, shadow shown behind real element. This is also the behavior I've seen in all the references I've reviewed. I don't think design tweaks are going to get us very far here and would encourage the team to consider #2. cc @teresaalvarezsoler |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an excellent start to the layout engine. Really clean solution. We can work out details in follow on PRs since this PR does not merge any user facing features.
code review and tested in chrome
@elasticmachine merge upstream |
I've created two follow up issues: one for the strange scrolling behaviour and one for the swapping of the ghost and the actual element when dragging. |
💛 Build succeeded, but was flaky
Failed CI StepsTest FailuresMetrics [docs]Public APIs missing comments
Public APIs missing exports
Unknown metric groupsAPI count
ESLint disabled line counts
Total ESLint disabled count
History
To update your PR or re-run it, just comment with: |
Summary
This PR contains a new performant and simple drag & drop layout engine for Kibana which uses HTML5 and CSS and and has no external dependencies.
Closes #190372
Kbn grid layout
The new layout engine is isolated in its own package
@kbn/grid-layout
, and the PR also contains an example plugin showing its use.How to test
yarn start --run-examples
Analytics
->Developer examples
Grid example
.Known differences
There are a few differences when comparing
kbn grid layout
and our current layout enginereact grid layout
.No animations on subsequent panel moves
When a panel collides with another and pushes it out of the way,
kbn grid layout
animates this. Because of our direct usage of CSS grid, we are unable to animate these events. I.e.grid-column
andgrid-row
properties do not supporttransition
.react grid layout
kbn grid layout
This difference can make
kbn grid layout
appear snappier, but much less smooth. This would be a very difficult difference to overcome, as we would need to move away from css grid and calculate pixel locations and sizes on the fly.Difficulty moving a larger panel under a smaller one
react grid layout
has special code for handling a case where a panel is moved down onto another. This mostly manifests in an earlier swap when moving a large panel underneath a smaller one.kbn grid layout
does not have this code, which. means users must drag a panel actually below the panel underneath for the swap to happen.react grid layout
kbn grid layout
This is somewhat mitigated by the fact that the drag preview doesn't block visibility of the panel underneath. Fixing this difference would require adding a small edge case to our sorting algorithm, and wouldn't be too difficult of a change.
Events are canceled when moving outside the browser window
react grid layout
allows the user to drag outside the browser window. The panel will continue to be dragged as if it was still following the mouse.kbn grid layout
does not do allow this, and dragging outside of the browser window will cancel the drag operation.react grid layout
kbn grid layout
This may cause frustration as the user needs to be careful about where they drag the panels. This could be fixed by digging into the internals of React Grid Layout's event handling to find differences, and would not be too much trouble as React Grid Layout also uses HTML5 drag and drop.