I just discovered the new Table's search capability (Query JSON with SQL on API data returns no results - #2 by stefancvrkotic). That might deprecate 1/3 of my JSON SQL queries!
One important change I would like to it, is only search visible columns - it currently search the entire data source. Or have that option. If the user finds a result that has no match in it because it is a field that I have not chosen to display, it will cause confusion. I don't think I can use it for around half its potential use cases for that reason.
Another improvement that would deprecate another 1/3 of my JSON SQL queries would be to have a list of columns to search and assign which component is used to search that column.
To chime in on this it would be cool to have a multiselect component generated from visible columns to pick what search logic is applied to.
Thanks @bradlymathews and @stefancvrkotic for the feedback! Being able to configure the columns involved in search is definitely something the team has discussed and is in our backlog. We are currently working on building out the Filtering capabilities to handle more granular searching and filtering, which will also unlock a lot more use cases here.
For the hidden column issue in particular, is there a reason the columns are hidden and not deleted? Deleting a column instead of hiding it is the new recommended pattern in table v2 if you don't plan to use the column (unless it is used as a primary key), and the column will not be used in search if it is deleted.
Ahh, I did not realize I could delete them - a different pattern over the previous version that had not been pointed out to me before. Is table performance better when they are deleted, are the hidden columns still in the DOM, just invisible or something?
I was worried that deleting a column removed it from
.selectedRow (I had written a whole section on this post basically complaining about that) but testing reveals that not to be the case, sort of - you use
selectedSourceRow to get the entire row,
.selectedRow shows the non-deleted columns.
Ok, so the real change is that you now delete a column if you don't want it to ever display. Use the Hidden property for dynamically showing/hiding a column. Getting a deleted column back if you change your mind is done with the + and new columns you add to your query do not automatically show up (that is both bad and good) you either have to regenerate columns or add them manually. I got that all right?
You know what we need? A full explanation and guided tour of the changes in the new Table (including new dev patterns) for those of us that have developed a ton of muscle memory with the old one. I thought I had it mostly figured out, but now I wonder how much I am still missing.
@bradlymathews Exactly! Table performance is slightly better when columns are deleted instead of hidden since there are underlying references to the hidden columns that can be removed when they are deleted entirely.
There are some migration docs comparing the legacy and new Table here, but definitely still some room for improvement. Stay tuned for more here