Problem with Searchpanes on columns that are not searchable (since 1.2.0)

Problem with Searchpanes on columns that are not searchable (since 1.2.0)

tkainradtkainrad Posts: 5Questions: 1Answers: 0

Link to test case: http://live.datatables.net/gukifequ/1/edit

Description of problem:
I recently encountered a problem with rebuilding individual Searchpanes. As is often the case with this amazing project, the problem was already pointed out in the forums and fixed in newer versions (>1.2.0).

However, with Version 1.2.0 I have a different problem. Using searchpanes with columns that are not searchable does no longer work. The table is always empty when selecting an item in the pane. This is not the case with Searchpanes version 1.1.1.

If anyone else has the same problem: My workaround, for now, is to stay with 1.1.1 and rebuild all searchpanes, to mitigate the problem with unresponsive panes.

Please let me know if you need any additional information. And thanks for maintaining this project. It is probably my favorite open-source project - amazing how you maintaining repositories, documentation, forums, etc.

This question has an accepted answers - jump to answer

Answers

  • sandysandy Posts: 913Questions: 0Answers: 236

    Hi @tkainrad ,

    Thanks for the feedback, glad you are finding it useful :)

    As for your problem, what is the use case for this? If you don't want the column to be searchable then why would you have SearchPanes work on it? If anything I would be tempted to say that in this case SearchPanes should hide the pane for the non searchable column...

    Thanks,
    Sandy

  • tkainradtkainrad Posts: 5Questions: 1Answers: 0

    Thanks for the quick response!

    I suppose not showing the Pane would be better than the current situation. It took me a few days until the problem was reported because I did not check all the panes after upgrading to the newest version.

    However, I think there are good use cases for having a search pane on a non-searchable column. I use SearchPanes to enable quick (single-click) filtering on category-like columns.
    But these category columns might clutter search results. Especially when the category names are also included in other columns. I could come up with a number of theoretical use cases, but here is my actual one:

    My project KeyCombiner has tables of keyboard shortcuts, e.g for VSCode
    There is a (by default) hidden column with a shortcut's modifiers. I don't want this column to be included in the search because the modifier keys are also present in the actual keys column. However, it is a great column for filtering via SearchPanes.

    Considering that the Pane does show the correct number of rows for each item, I would assume that the pane can filter for the respective set of rows without the column being searchable, or is there an architectural problem with allowing SearchPanes on non-searchable columns?

  • sandysandy Posts: 913Questions: 0Answers: 236

    Hi @tkainrad ,

    Thanks for explaining your use case. I agree it would be useful for SearchPanes to allow this. I've raised an issue internally (DD-1814 for my reference) to look into this and will report back here when there is an update.

    Thanks,
    Sandy

  • tkainradtkainrad Posts: 5Questions: 1Answers: 0
    edited January 2021

    That sounds great, thank you @sandy!

  • allanallan Posts: 63,214Questions: 1Answers: 10,415 Site admin
    Answer ✓

    Hi,

    I'm following up on this as Sandy and I have been having a chat about this. What is happening is that in DataTables core we have an optimisation which means the search strings for a column are not build if its searchable option is disabled. The result is that SearchPanes doesn't have the data it requires to work on.

    What we plan to do is have an API call that can either get the cached data, or trigger the data to get cached if there isn't some already. This would be more generic, but it does require a change in DataTables core. As such it probably isn't going to be addressed in the near future as I'm focusing our efforts elsewhere in the software that the moment. The workaround is to use 1.1.1 (which used a different mechanism for getting the data - which itself was the cause of a few issues, hence the reason for the change) or don't disable searchable on the column.

    Regards,
    Allan

  • tkainradtkainrad Posts: 5Questions: 1Answers: 0

    Hi,

    I see, that makes perfect sense. For my specific use case, both workarounds are viable.

    Thanks for the quick response, appreciate the explanation, and highlighted code location.

    Best,
    Thomas

This discussion has been closed.