Provide API access to the results of Bases view

[Hellomynameis99]

Bases is a fantastic first‑party way for users to define cohorts of notes. Allowing plugins to get a list of notes from a Base without the plugin being implemented as a Base view would significantly expand what plugins can do with Bases.

Many plugins implement their own query language, search system, or filtering to compile lists of notes, which requires users to re-write their custom filters across plugins. If users could point such plugins to a Base#view, they could reuse a native feature of Obsidian instead.

Proposed Solution

I’d love to see a supported, headless way for plugins to evaluate a given Base and view to get its matching notes.

Not prescriptive about naming, but something like:

await app.bases.getViewFiles(baseFile: TFile, viewName: string): Promise<TFile[]>;

Use Case

How popular plugins could use this

Note that I don’t use all these plugins myself, I just browsed through a few most-downloaded and considered how they could use this API - these are just ideas based on my first impressions and not necessarily something the developers of these plugins would/should implement:

• Dataview could support Bases as another FROM source, e.g. LIST FROM "Books.base#To Read"
• Tasks could filter by tasks in a given Base
• Smart Connections could add additional filters (include and exclude rules)
• Spaced Repetition could create decks from a Base view (currently done by folders or tags).
• Projects could build projects from Bases (currently done by folders and Dataview queries).

How not-so-popular plugins could use this

My own plugin, Pairwise Elo Ranking, defines cohorts of notes you can compare against each other to easily rank them. One of the methods of creating cohorts of notes for comparison is to use a Base.

Current workaround

To accomplish this, I’m currently opening the Base in a new leaf and reading controller.results after it settles - which is more complex and fragile than it needs to be.

If there is already a better way to do this, please let me know!

[jeezycarry]

This would be so helpful!

[Azaol]

Yes please!

Plugins could also benefit from getting that list to provide a friendly and more integrated UX/UI that users are used to!

Real example use case: My grand mother wants to reset the ranking of all series she watched last year and rerank them one by one. She already know how to query that using base, but being able to provide her with a two lines of JS snippet in a Note toolbar button would be awesome!

That’s one use case from this week, but the other that I know I will be asked for sure is about running an API query for a selection of series. Giving a way to use a filtered view (Base) as input for a script loop would be so cool.

[Moy]

Hi, I raised a similar idea on Discord, and someone in the channel pointed me to this post. So I’d like to add a few related thoughts.

My vision for this API is similar to the OP’s, but I’d like it to be more flexible: rather than being limited to the results of a specific view, plugins could define query criteria directly in their settings and retrieve a list of notes that match those filters. This would let plugins configure the filters themselves, without requiring users to create a view in advance.

There’s also a slight variation of this use case: given a particular note, a plugin could determine whether it “matches this filter.”

My original post:

In several plugins I’ve been developing recently, I’ve needed some form of “rule evaluation.”

For example, one plugin needs to filter notes “created today,” while another one (pictured) applies styles based on whether a note meets certain criteria—currently, folder and path matching.

I also briefly experimented with developing a Bases plugin. At the time, it seemed that this query system and its results could only be used within extended Bases views. But could a similar rule system be made available elsewhere as well—so third-party plugins could quickly filter notes or configure conditional matching in different contexts?

Existing similar solutions

As far as I know, the obsidian-custom-views plugin has implemented a similar filtering-conditions feature in its settings. At first, I assumed Bases had provided that UI and API—but it seems the plugin author may have manually recreated the whole system instead.

I’m wondering whether this could become an official API, so developers with similar needs could rely on the same shared interface and provide rules and a user experience fully consistent with Bases.

What I’m hoping for is precisely a unified interface like this—one that is fully consistent with Bases Filters.
Users would not need to learn another interaction model, and plugin authors would not need to independently implement their own condition-matching rules and GUI designs.

It would feel much more seamlessly integrated with Obsidian’s native experience.

Plugin use cases for such a system

A few examples of plugins and use cases that could benefit from such a system:

• Apply shared cssclasses values to notes that match certain conditions, without manually adding them to every note. (I’m developing a plugin for this.)
• Configure different behavior for notes matching specific rules. For example, Note Toolbar could map different toolbars based on folders, or allow a property to directly specify which toolbar to use.
• In Templater, apply different templates based on the folder a note belongs to. In fact, “checking a folder” is probably the most widely used subset of this kind of rule system.
• In Notebook Navigator, hide notes based on filename matching, folder matching, the presence of tags, or the presence of specific properties.
• In Custom Views—as mentioned above—assign different custom reading-view templates to notes according to matching rules.

I could list many more examples. These are all plugins I have actually used, and most of them rely on their own implementation of filtering rules to solve the same general class of problem. Perhaps few plugins would need every condition supported by Bases Filters, but a Bases Filters-style API could satisfy nearly all of their existing needs—in a unified, native way.

Perhaps plugin developers could also choose which conditions to enable. For Templater, for example, file.folder might be all it needs.

[cheznine]

Adding my vote!

I’m about to add a rules engine to my plugin and would love to be able to reuse this API and UI.

In my use case, for Note Toolbar, I need to be able to check if a file matches a given rule, and display the associated toolbar for that rule.

Particularly I need this as suggested by Moyf, above:

There’s also a slight variation of this use case: given a particular note, a plugin could determine whether it “matches this filter.”

… but beyond just notes, as I need to check applicable rules against Bases, Canvas files, etc.

[Moy]

I just remembered another old plugin with over 204k downloads: obsidian_supercharged_links.

It also implements its own “filtering system” based on paths, tags, and properties (attribute value).

So I think this is clearly a fairly common and broadly applicable need.

---

Taking this a step further: could the Graph view’s search syntax offer an enhanced mode that uses this new API?

My current basic filter is:

-file:.base -path:PeriodicNote -path:4-Archive -tag:#core -path:Bots -path:学习笔记/Obsidian

But I think it could also be presented in a Bases-style format:

And, if combined with the feature proposed in Bases: Quickly enable/disable filter groups via buttons toggles - Feature requests - Obsidian Forum, we could quickly toggle the visibility of different categories of notes. This would make working with the Graph view much easier than editing text in the current tiny search field.

This is getting me a little excited… I think I should create a separate feature request for it!

[FEZ]

Would like to add my upvote to this as well. I received a request on my Multi Properties plugin to be able to mass-edit properties on all notes within a Base view.