Responsive Views? Filtering & Sorting for tables

[OscarAblinger]

I love dataview so far – the only thing I'm really missing is being able to filter and sort tables. I've seen this feature on your road map, so naturally, I thought I could contribute a bit.

But before I think too much about how I would do it, I wanted to spark a conversation about certain aspect that should be discussed first:

• Should this be solved by a separate plugin?

  • + I generally want this for every table, not just tables – a separate plugin could do that
  • + Separation of concerns
  • + dataview would only have to implement a few interactions:
  • A way to connect a html table with a dataview object
  • An event when the data changes (so the table can be updated)
  • Potentially functions on what should happen when you try to add data to the table
  • - More work to synchronise
  • - Users would need to vet & install two plugins (and afaik obsidian does not support "dependencies" in it's plugin page)
  • - If the other plugin becomes unmaintained then suddenly the dataview community would either have to switch or maintain a second project with features that are potentially not used in dataview (like automatically detecting & replacing tables)

• Should it have a specific look or look as vanilla as possible? In that lane: there are already a lot of js-libraries that implemented anything you might want to have in a table. I've not looked enough into all of them to see which ones are suitable for this use-case, but here are a few:

  • tabulator MIT
  • tablefilter MIT
  • datatables MIT

  Pro & Cons that I could think of:

  • + Less work to implement
  • + niche-features that nobody would implement otherwise, might exist through that library
  • + Well-tested & used libraries exist
  • - API is limited by the underlying library
  • - Almost all of them provide a unique look out-of-the-box. That means that they will look widely different to the normal HTML tables (idk if that is unwanted, wanted or if you don't care)
  • - Some of them will likely make styling them through CSS a bit tedious (which is not nice for themes)

• What features are you interested in? I'd like to have:

  • All of these features optional & configurable via the plugin options
  • Filtering (exact & fuzzy & tags (see below))
  • Sorting
  • Recognition of tag-like columns (e.g. a ,-separated list -> you can filter by which tags have to be there)
  • Mobile-friendliness
  • Temporary hiding of columns
  • Adding of columns (which might create a new page for dataview tables)
  • Probably easiest implemented through a modal – some libraries already support inline adding and their apis could be used
  • Removal of columns (which probably shouldn't just delete a page in the dataview tables?)

  Other things I could think of:

  • Auto-configure sorting based on the dataview query (e.g. sort name asc will show that the name column is sorted ascending)
  • Change the query through the table (adding/removing fields, adding/removing filters)
  • Allow pre-configured views (that have certain filters/sorting pre-set, might switch between list, table etc. – kinda like what notion offers)
  • Filter for non-columns (e.g. filtering by mtime even though it's not shown in the table itself) Maybe through a free text field that allows to add dataview-query like conditions

[blacksmithgu]

Thanks for the interest! I've thought about this before but haven't made much movement on it because "dataview as a responsive table view" and "dataview as a query language" are fundamentally two different approaches to handling data. In "dataview as a query language", responsiveness is difficult, since you have to map the changes the user makes onto the view back onto the query:

• If I sort by a view in the responsive view, I need to modify the query to also sort on that row.
• If I add a new column, I need to modify the query to also select on that column.
• If I add a filter condition, I need to add a corresponding filter condition to the query.
• etc.

This is doable for a simple dataview query though can quickly become difficult once grouping or complex-looking fields are involved; it is straight up impossible in general for DataviewJS queries. Which is a real shame, because being able to visually interact with your data is hugely useful.

In general, I've found that the query language sits in an unfortunate valley of how useful it is - it allows for some neat basic applications like basic filtering and grouping, but it lacks the full set of tools and customizability that allow for truly radical/interesting applications (that DataviewJS can provide). I'm thinking about just getting rid of the query language and replacing it with a WYSIWYG editor that emulates the same functionality as well as offering the niceties you suggest.

[OscarAblinger]

Ah I see, your interpretation is quite different from what I envisioned.

I wouldn't have linked it to the query language at all. So all changed that you make in the visual table would not be reflected in the query. Like you said, that would kind of open a can of worms with the complexity involved.

Plus, I will often just want to search for something. E.g. I currently aggregate all of the books that I read, so maybe I wanna have a look at all of the books that are currently unread, but bought. Sure I could make a separate query and look at that result, but I'd prefer to just filter it in the visual mode. But then I don't want my query to change. (That behaviour would actually be pretty unexpected to me)

The application of those filters/sorting etc. to the actual query could maybe be done as an additional feature via a button press. In that case you also wouldn't have to support everything, only those that the query language is capable of doing.

[blacksmithgu]

If it didn't matter whether the visual sorting/searching/etc actually persisted across opening and closing the page, then it would be possible to implement these features immediately by simply improving the table implementation + adding features.

[clotodex]

I fully agree that for now, just a visual, non-persistent across visits, way to interact with the data would be gorgeous. I also think that having dataview(js) as a query language can be a great opportunity. In the future, instead of just building a query to fetch data, you could include multiple choice filters in the query and maybe even determine what happens if you edit a field etc - then it would be WYSIWYG. This would then also no be a problem with dataviewjs, since the different interactions are part of one query. The only crux I can think of is that it will be very annoying to code all the different filter options etc in every query you write - however even this could be circumvented if dataview and dataviewjs share the same convenience functions that add e.g. basic filters on their own (e.g. a table view has the default functionality to have the columns sortable etc).

So overall I think, even though it will be complicated, that dataview(js) can offer a WYSIWYG way of interacting with data that is still highly customizable and thus offers far greater value than e.g. the limited notion tables.

[blacksmithgu]

Optimally, you could set up DataviewJS views which just set up basic filters and the filter options for you, and then it all gets rendered prettily along with a table for free; I think that much is achievable without making it horribly complicated.

It would be a huge step up in usability to embed a lot of functionality "for free" in all dataview tables, like sorting, per-column filtering, pagination, and so on. I will probably spend dedicated time to it after I've added dataview objects and per-section dataview queries.

[Creling]

Well, any progress? +1 for @OscarAblinger . A richer table header that provides with sorting/filtering is all I want. Either stateful or stateless is ok for me.

[AB1908]

Some other plugins like mentioned in #1015 have responsive views.

[pidgeon777]

Filtering tables would be great, hope it will be implemented.

[LePenseur13]

+1