Currently, when working with data in a base view, the only way to find specific records is by creating persistent filters. This works well for permanent organization, but creates friction for quick, one-time searches.
Base views currently only allow filtering based on property values, but sometimes you need to search within the actual content of notes. For example, imagine you have recipe notes where the ingredients aren’t stored in properties but within the note body. If you want to filter the current base view to find all recipes containing “turkey”, that functionality isn’t currently available in bases.
Proposed Solution
Add a search function that works within the current view, similar to Obsidian’s core search plugin functionality. This should search both note properties AND the full content of each note. This could be implemented as:
Quick search box at the top of each base view (like the global search bar)
Keyboard shortcut (Ctrl/Cmd+F) to open search, matching Obsidian’s standard behavior
Full-content search that searches through both property values and the entire text content of notes in the view
Search behavior that temporarily filters visible records in real-time as you type
Search syntax that could optionally support the same operators as Obsidian’s core search plugin (quotes for exact phrases, OR/AND logic, etc.)
Like Obsidian’s core search, this would temporarily show only matching records while the search is active, but wouldn’t create or save any permanent filters.
Current Workaround
None currently exist.
Benefits
Faster workflow for quick record lookups
More intuitive user experience consistent with core search functionality
Ability to search a smaller subset of vault notes more efficiently
This feature request differs because it specifies the ability to filter based on the content of the entire note, including YAML frontmatter. However, this feature request mostly satisfies the requirements of that one. Even the solutions suggested by some comments about adding search boxes to each base view column could be replicated by filtering against the full content of notes already filtered by the base view. I think their popularity is additive. Feel free to combine them if needed.
That’s fair. There were a lot of comments in the other thread with many ideas. Can you add the tag bases to this post? I’m surprised it hasn’t gotten more likes. bases
I don’t think that comment is related because this request doesn’t require inline properties. I think fuzzy search/core search is something where much of the work has been done while inline properties would take significant work.
I am not sure about scanning the entire files, but narrowing the records pulled by the tables is a very useful feature that is usually available in most data table view applications.
I started experimenting with the db-folder plugin for some tables where I really need it to
Narrow down the results.
I really hope it will be added at some point in the future because this Base feature really is a great tool.
I want to add a custom property to my view, like summary, which is used to display a small portion of the beginning of the note (or a specific heading). However, it seems that there’s currently no API available to access content of the note. At first, I tried to manually create a summary property for each file and copy the beginning into the property, but I eventually gave up because it was too troublesome.
Proposed solution
It would be great to have a method like content() under the file, for reading the body content of a file. For example:
// Reads the full content
file.content()
// Reads up to 100 characters from the beginning of the content
file.content(100)
// Reads up to 100 characters from the section under the heading "### summary"
file.content('### summary', 100)
I’m not sure whether reading the content of each note would cause performance issues, since Bases is currently much faster compared to Dataview. But I think this would make it much easier to generate custom properties without having to manually copy contents into frontmatter.
As long as you’re filtering first and only then parsing the contents of notes, it shouldn’t cause any noticeable performance issues.
I regularly use Dataview tables based on the free-text contents of notes without any performance issues on desktop or mobile. This is from a vault with >20,000 notes.
As another example, my Air Quotes plugin can free-text filter the entire raw text of the bible as you type (750,000 words) with zero noticeable performance hit - you type and the results are immediate. I didn’t even bother to do any indexing - it’s just the regex function .matchAll(). Javascript/CPUs are pretty fast these days. A better developer could do it even more efficiently then I did.
Same experience here.
My own pseudo-plugin filters by property first but even if there is no filter set, once the index is in memory, the results for note content are near-instant (for a single line search such as .*?search.*?term.*). In my case, I’d say even faster than in the core Search Modal… Both on PC and older tablet.
Yea, I’d love that. Maybe using it as filter would be bad for performance but as a property to be added as a column that would be awesome and might not have too bad of an impact in performance?
I often need to view related notes transcluded within my note. For example, when viewing a project note, I want to see all its related meetings transcluded within the project note. The reason for this is to be able to get an easy overview of what was said when, and to be able to do a quick search for when topic X was discussed related to this project.
Proposed solution
Bases should have transclusion as an optional view. This view would show the full content of the notes within the base (as if the note was displayed with ![[]]). Using this, a base could then be shown within a note using and all its filtered notes would show transcluded.
Current workaround (optional)
Currently using Dataview to list all related notes as ![[]]
