Replies: 1 comment
-
I used virtual columns in the past as well for exactly this kind of use case. I think, a virtual search column is a totally valid approach here and it's actually quite clean and easy to implement, if you use column-visibility. Instead of adding custom code to remove the column, just set the initial state to hide the column and make sure to use getVisibleCells() or other helpers to check whether your column is actually displayed. If you have some requirement to also use toggleable visibility, you can use columnDef.meta to add a flag that your column shouldn't be displayed or shouldn't be toggleable. That way, you add a bit of custom code, but you don't lose the declarative column definition. |
Beta Was this translation helpful? Give feedback.
-
I'm not sure if I'm doing this properly, I have a table which shows for each row it's id, and then other infos
the "id" column has a filterFn which is "stringIncludes" so that when typing in a searchbar above the table, I can filter rows by id with a search string
I also want to add a feature where a user can copy-paste a list of ids, and I would filter only those ids
I guess one way would be to allow the "id" column to have a different behavior depending on whether the filter is a string (typed in the search bar) or a set of ids (sent when copy-pasting the list of ids)
to avoid this, I added a "virtual column", eg with
{ id: "_id_select", filterFn: some_function }
with a filter function which checks whether row.original.id is in the set given to the filterFnthis means that I also need to have custom code to remove the column from the display
I'm wondering if that's the best solution, or is there a more elegant solution which doesn't require adding a "virtual column" (and then ensuring it is not displayed, which adds extra work) when I just want to have two different ways of filtering the "id" column?
Beta Was this translation helpful? Give feedback.
All reactions