Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

Make Handsontable work with custom scrollbar plugins #6255

Closed
KingSora opened this issue Sep 9, 2019 · 4 comments
Closed

Make Handsontable work with custom scrollbar plugins #6255

KingSora opened this issue Sep 9, 2019 · 4 comments

Comments

@KingSora
Copy link

KingSora commented Sep 9, 2019

Description

Good day!

I'm the author of the library OverlayScrollbars and recently a user has opened a issue (#139) where he asks whether he can use my library in combination with Handsontable. I've investigated into this, and came to the conclusion that it is almost possible without any additional features from your side.

I've created a demo here, as you can see everything works pretty much okay except the headers arent scrolling properly. (maybe there are more things which arent't working properly, but I'm not aware of).
The only problem is, that I'm using the options viewportColumnRenderingOffset and viewportRowRenderingOffset with a static number to make it work. Without these, the table won't render properly after you scroll, as you can see here. This is obviously super bad for performance since you aren't using any virtualization and are rendering all elements in the DOM.

The reason for this is, OverlayScrollbars uses it's own viewport div, and thus the scroll event is never fired by the original viewport div which is used by Handsontable. In order to make it work, (with pretty much any scrollbar plugin, not just with mine) it would need additional feature(s):

  • A feature which makes it possible to change the viewport HTMLElement
  • A feature which which makes it possible to overwrite the current scroll position (x and y)

For my plugin just the first option would be enough, but other plugins which aren't using native scrolling would also need the second in order to pass their current generated scroll position.
I thought it could look something like this:

//init Handsontable
var hot = new Handsontable(container, {
  data: Handsontable.helper.createSpreadsheetData(50, 15),
  width: 500,
  height: 300,
  rowHeaders: true,
  colHeaders: true
});
//init OverlayScrollbars
var osInstance = OverlayScrollbars(document.querySelector('.ht_master .wtHolder'), { });

//new Method which makes it possible to change viewport
//the current scroll position is always .scrollLeft and .scrollTop of the viewport element
hot.setViewport(osInstance.getElements().viewport);

//or
//new Method which makes it possible to change viewport and provided scroll position
//the second parameter (the function which returns the current scroll position) would be optional)
hot.setViewport(osInstance.getElements().viewport, function() { 
  return { 
    x : osInstance.scroll().position.x, //same as osInstance.getElements().viewport.scrollLeft
    y : osInstance.scroll().position.y  //same as osInstance.getElements().viewport.scrollTop
  };
});

I hope you understand my proposal. Maybe you even have a better idea or this is already somehow possible. Thanks for your answer!

@AMBudnik
Copy link
Contributor

Thank you for sharing these tips, Rene.
The scrollbars are really adding a fresh look to Handsontable. That is something we'd definitely benefit from.
However, (unfortunately, there's one) we cannot allow ourselves to push anything more to our tightly-crafted Roadmap for the next 2 months.

@KingSora
Copy link
Author

Thats perfectly understandable, maybe it's possible for me to contribute to your codebase with this feature. With a little bit of guidance from your side (if you have time of course) this would be relatively easy. I would just need to know where you manage your scrolling and whether there are some special things related to scrolling / your viewport element which I should know / take care of.

@wojciechczerniak
Copy link
Contributor

I'm not sure if it's that easy.

It's not a single container you want to control. Handsontable has 6 layers to sync scroll: master, topFixedRows, leftFixedColumns, bottomFixedRows, and 2 corners. Which handle scrollbars, mouse, touch and momentum scroll. They also depend on scrollbars to calculate their size and position.

Our virtual rendering is based on the viewport and scrollbars size. There are multiple methods and tests that rely on scrollbars and their widths scrollViewportTo, getFirstVisibleRow, getLastVisibleRow, getFirstVisibleColumn, getLastVisibleColumn, countVisibleCols, countVisibleRows. With overlay scrollbars, are they visible or not? What if they are no longer transparent?

Some editors are based on Handsontable: HandsontableInHandsontable, Autocomplete and UI plugins: ContextMenu, DropdownMenu. You need to take under consideration also those scroll containers.

@AMBudnik
Copy link
Contributor

Thank you for sharing this proposition.

I'm moving this topic to Github Discussions. And I welcome everyone to discuss this functionality and share your feedback.
See you there!

@handsontable handsontable locked and limited conversation to collaborators Apr 15, 2021

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Projects
None yet
Development

No branches or pull requests

3 participants