Toggleable search fields in header

Tags: #<Tag:0x00007efc6e2e1e60> #<Tag:0x00007efc6e2e0790>
#1

Hi,
I want to implement search bars inside each column header where I can type to search. Thanks to this forum I got the implementation of the search fields and the search functionality itself to work perfectly (unfortunately I can’t find the reply that gave the instructions anymore but it was highly appreciated).

However, I also want to be able to toggle these search fields via double clicking of the header row and adjust the header row height accordingly (ideally with CSS animation but that is optional).
So:

  • double click: show search field + expand header row height.
  • double click again: hide or remove search fields and restore original header row height
    I got the toggle to kind of work but I just can’t get the header row height adjusted. Here is a simple example of my current progress:

https://jsfiddle.net/41fpLosy/
(comment-in line 70 for a naive approach at changing header height)

Now I understand that the table consists of a master table and a clone that sits on top. My impression so far from fiddling with my actual project and different approaches of manipulating CSS (adding classes, using querySelector, …) is that I can get the master to adjust its header row height but I can’t get the clone to follow suit, so it stays stuck at the increased width, even after the search bar is set to display: ‘none’.

I usually figure these things out on my own sooner or later but since I don’t know the inner workings of handsontable well enough I feel stuck at this problem right now.

Can you think of a good way to solve this? Any ideas or pointers will be greatly appreciated. :slight_smile:

Best regards

#2

Hi @jaytug

We had a similar demo (search inputs in column headers) in the documentation. It was a simple example with around six columns and no additional features. Users often used that example to build wider tables with more columns, but it became clear that it wasn’t the best idea to provide the example in that form. The functionality only worked properly for the columns visible in the viewport.

Why does this happen? When the table needs to rerender, the inputs are erased because they are generated again from the colHeaders or afterGetColHeader hook. So to make it keep those values we needed to enable renderAllColumns functionality. Only then scrolling horizontally would not trigger the cell renderer. Otherwise you’d need to save the new input value within the header each time someone types it in (and that requires another render() method to be called).

When it comes to the height of the colHeaders section, I recommend using the official API and the columnHeaderHeight option. You can adjust this value by calling the instance.updateSettings() method. This ensures that you’re using a tested solution that will be maintained and fixed if any issues arise.

ps. if you’d need a code review please contact us at support@handsontable.com to confirm your support plan. Thank you.

#3

Thanks you for your reply, it was certainly helpful. While waiting I actually made some tangible progress and almost got it to work the way I want, although I am running into some unexpected behaviour and your explanations might explain why.
For example, I can now activate and deactivate the search bar via double click and I also got the header height to change, but triggering the cell rendering in any capacity while the search bar is active causes the latter to bug out (can’t hide the input field anymore).

I will test some more and also try your suggestion for using updateSettings(). I will update here if I find a satisfactory solution in case anyone else is interested.

#4

I’m happy that I was able to help.

Please keep us updated here om forum.

#5

Okay here’s my update.
Using updateSettings() to change the header height worked as expected, though it prevented me from using CSS transitions. Not a deal breaker but I’d like to have them.
But in the end it didn’t matter, because as you described, putting the input fields inside the header (or the table for that matter) always clashed with table rendering and trying to make it work seemed very hacky. That is, having static input fields inside the header actually worked perfectly fine but trying to make them dynamic/hideable caused issues. So I decided to just create a separate search bar outside the table and have it appear on top.

See my fiddle (press ‘run’ once to make it work, then double click the table header).
It’s not polished yet (e.g. total width of the bar is set manually in the CSS) but it works as intended.

#6

That looks and work great @jaytug

Based on the contextMenu options, it seems you do not intend to allow users to alter the number of columns. Therefore, you do not need to conduct tests that load more than four columns in the viewport. I mention this because such a scenario could potentially cause scrolling glitches. If you do not plan to load more columns, I believe the solution is production-ready.

Oh and maybe one more thing. Helpers in Handsontable (I saw you use debounce()) are not a part of the official API so they might be changed/removed in any future version. I recommend creating your own function here. Otherwise something might be broken while updating the library.

#7

Those are good remarks, thank you. Some of my actual tables have a higher number of columns but that number won’t change per table.

So far I had no issues with my solution except a minor inconvenience with the .focus() of the input field after having it appear. That is, I can type away perfectly fine (thanks to this.deselectCell() in the afterGetColHeader hook) but when I then press ctrl+a it selects the table body instead of the content of the input field. This does not happen though, if I first click into the input field instead of relying on the .focus(). Only physically clicking the input field seems to properly take away any focus/selected state from the table. It’s a detail I can live with, but I thought I’d mention it.

Also thanks for the remark regarding the debounce. I’ll make sure to replace it before the next update.

P.S.: handsontable’s flexibility really sets it apart from other libraries. Keep up the great work :slight_smile:

#8

Thank you for the feedback :hearts:. I will make sure to share it with the team!

Also I have to admit that your solution is impressive. I love to see when developers aren’t afraid to extend what’s already available with their own ideas.

ps. you can also check our Shortcut Manager - it allows you to push your own logic into key combinations. Maybe that’s the missing puzzle.