@gabrieldutra widget drag tests fail cause the placeholder now animates and also doesn't react as expected. Fiddling with it I realized there are 2 better ways to go about determining widget position delta:

1. Disable animations when testing.
2. Utilize the built-in retry mechanism of cyElement.should to wait until animation settles.
   I like this better. This would require sth like this:

// original
it('moves one column when dragged over snap threshold', () => {
  dragBy(cy.get('@textboxEl'), 110).then((delta) => {
    expect(delta.left).to.eq(200);
  });
});

// suggested
it('moves one column when dragged over snap threshold', () => {
  const drag = () => cy.get('@textboxEl').dragBy(110);
  const getLeft = () => cy.get('@textboxEl').invoke('offset').its('left');

  cy.get('@textboxEl').should(($el) => {
    expect(drag).to.increase(getLeft).by(200);
  });
});

But, it's not possible cause for some reason Cypress doesn't expect increase() argument to be a function, only an object, although Chai API does allow it (introduced long ago).

What am I doing wrong?
Also, did we already talk about this? 🤔

What am I doing wrong?

Isn't this getLeft async? (as it uses cy.get) Perhaps if you turn this spec into a jQuery style by getting the element first cy.get().then(($el) => {...}). Then you should be able to run functions and assert with $el (there is a chance that the element in the variable doesn't get updated, if so, assertions won't work).

Also, did we already talk about this?

Kind of, I wanted before to use Chai with elements directly (it doesn't work at all), this is a bit different 🙂.

I've noticed this one while playing:

I've noticed this one while playing:

10x @gabrieldutra, that's a grid feature I don't care for either.
Fixed in react-grid-layout/react-grid-layout#549 but not merged yet :/

It's possible we'll have to have our own fork, since the original repo is not very responsive.

I played around a bit with the migrated features, didn't find any new issues 🙂.

10x!

+367 −727 LOC? 😮

There's still 2 upcoming PRs so don't believe it yet!

BTW, Why dashboard-grid.jsx and not DashboardGrid.jsx?

Right - I started work on this PR quite long ago before we had definitive standards.

While trying it with the deploy preview Viz demo dashboard I noticed there is considerable lag when going into edit mode and when exiting edit mode (even when not doing any changes).

Any idea why is this?

While trying it with the deploy preview Viz demo dashboard I noticed there is considerable lag when going into edit mode and when exiting edit mode (even when not doing any changes).

Any idea why is this?

@arikfr when clicking "Edit", all grid item's isDraggable and isResizable props are set to true, which renders each with a react-draggable wrapper and a react-resizable wrapper. It makes sense that the more grid items, the more time it would take to init them.

Tested these props with persistent false and lag disappeared.
Didn't find related open issue in repo.
I have no simple solution in mind.

One way is to introduce lazy loaded grid items according to viewport (using the Intersection Observer API).
@kravets-levko @gabrieldutra any suggestions?

I just opened the last version on Netlify, and:

1. The delete ('X') button is always visible.
2. Considering you can only resize from the bottom-right corner, maybe the indicator there should be more prominent?

(2 is NTH, but 1 is a blocker of course)

Also the performance on huge dashboards isn't great, but I guess there isn't much we can do aside from pushing forward with converting widgets and visualizations to React?

Few more things:

1. The widget dropdown menu isn't seen if the widget is too short, see the text box here: https://redash-preview.netlify.com/dashboard/short-widget.
2. When the widget is too high, it overlaps with the bottom help box and you can't resize it. See the Albums widget on the dashboard above.
3. The trigger to open the widget menu is vertical on widgets and horizontal on text boxes. We should pick one :)

@arikfr I tested it on our React migration dashboard (which I think is pretty large): it is a bit slower when moving/resizing widgets comparing to gridster-based variant, but not too slow. I think we should migrate everything to React first, and only then test it again to decide what to do with it. Issue with lag when entering/leaving editing mode is completely fixed.

For "X" button - yeah, don't know how did I miss that. Will fix now.

Ignore 2 in my last comment -- it's actually fixed in this PR :)

@kravets-levko can you rebase with master?

@ranbena Done

@kravets-levko I thought it wasn't cause it's missing the grid markings #3656 but it's actually a bug.
I can work on it and push to this branch.

@kravets-levko I pushed the fix. Tested on Chrome/FF/Safari on Mac. Tested public dashboard.
Added one change: markings now appear also when there are no widgets in dashboard yet 🤟

@arikfr

Before	After

Merged 🚀