I am writing to propose an exciting addition to Obsidian MD that would greatly enhance its capabilities and provide users with the ability to seamlessly integrate dynamic content into their notes.
Proposed solution:
To achieve this functionality, I suggest implementing a feature that allows users to utilize file properties and insert their values directly into the body of their notes. This can be done by introducing a YAML front matter system that enables users to define file properties at the top of their notes. This section would serve as a repository of key-value pairs, allowing users to assign values to specific properties. Users can then effortlessly insert these property values into the body of their notes using a straightforward syntax, employing double curly braces ({{ }}).
Example:
---
myProperty: My Value
---
# My Note
This is the value of myProperty: {{myProperty}}
In this example, the {{myProperty}} placeholder will be dynamically replaced with āMy Valueā when previewing or rendering the note. Any modifications made to the value in the YAML front matter will automatically propagate throughout the note.
Current workaround :
Use the Templater plugin. For example, if you have a file property called āauthorā in your note, you can use {{tp.file.property("author")}} to insert the authorās name into your note.
However, this doesnāt completely function the same way as my proposal above because you cannot cite values from the frontmatter as you are writing the note.
There was also a plugin called: Obsidian Inline Variables, which had the intention of bringing this functionality to Obsidian but it appears to have been abandoned.
Yes, Meta-Bind is an almost perfect solution, stumbled upon it myself, but great suggestion. This should be more native though. For example, this is meta-bind issue probably, but it uses toggles instead of checkboxes.
With the beta release of Bases (and baked-in extensibility), properties really assume preeminence for structured data. While most of the time Iām content to keep those properties hidden away in YAML, there are times when selective data are relevant to the note content itself and I want those properties to be visible. Currently I rely on Dataview to display this.property but given Dataviewās sunsetting and future development of Bases, I would like a āCoreā solution to display selected properties in my notes.
Proposed solution
Other forum posts suggest this might be possible with CSS, but I think it would be more straightforward to create a properties codeblock that could be placed anywhere in the body of a note. I am NOT proposing placing editable properties in such a codeblock ā for my purposes, I just need to display some or all of the existing properties in the note body.
Yikesā¦ characterizing this as āassertionā seems a little hostile. More like a premise, and perhaps a mistaken oneā¦
When I described Dataviewās āsunsettingā I was drawing on a number of sources reporting over the past year that it was in maintenance mode, as blacksmithgu turned attention to Datacore. I apologize if Iāve mistakenly repeated unsupported gossip, and I appreciate @RoyRogersā point.
Dataviewās ongoing development status aside, my request for a ācoreā solution in the form of a codeblock still offers merit, I think. Nontechnical users (like me) ā who may find Bases easier to use than Dataview ā are familiar with embedded queries and similar uses for codeblocks.
The views: ... part should be optional so that writing bases on the fly could be flawless. I havenāt tested bases myself so I donāt know if views: can be omitted. Also they could make these two equivalent:
filters:
and:
- taggedWith(file.file, "example")
filters:
- taggedWith(file.file, "example")
In this case and: would be not required when we apply only one filter.
Are you saying that using a base code block in a note I could:
a. Filter by this fileās file name (so the values only come from this note)
b. and display only the values of
property A
property B
property C
ā¦
As I said earlier, I am a nontechnical user, so I donāt know how to interpret the filter syntax. But because the code block would likely be used in templates, it would have to be able to reference itself abstractly and not explicitly by name. Like with Dataviewās this.file.name ā¦
Also, do you think there would there be a performance or resource issue in this approach? Per the docs, āBy default a base includes every file in the vault.ā To my non-coder mind, using a filter to exclude all but one file in the vault seems like a lot of computational work instead of simply pulling a few properties from the current file. But what do I know?
Finally, the bases code block would probably need to set the view as a list as opposed to a table for readability and aesthetics. I know thatās on the roadmapā¦
Embedded bases can use this to access properties of the current file. For example, this.file.name will resolve to the name of the file which has embedded the base, instead of the file being evaluated.
In a sidebar, this takes on the special meaning of āthe currently active fileā. This allows you to create contextual queries based on the active file in the main content area. For example, this can be used to replicate the backlinks pane with this filter: linksTo(file.file, this.file.path).
The corresponding filter is file.file == this.file.file. Obviously I donāt know how performant this particular filter is. I believe this works in constant time.
Views can add additional data to store any information needed to maintain state or properly render, however plugin authors should take care to not use keys already in use by the core Bases plugin. As an example, a table view may use this to limit the number of rows or to select which column is used to sort rows and in which direction. A different view type such as a map could use this for mapping which property in the note corresponds to the latitude and longitude and which property should be displayed as the pin title.
In the future, API will allow views to read and write these values, allowing the view to build its own interface for configuration.
Here is example of table configuration (Iām not sure if the example is exhaustive):
type: currently only table views but later there will be several other types of views
name is your view name (you can have multiple views)
limit: how many rows are visible in your table
filters: view specific filters, this syntax is same for all view types
group_by: group similar rows together
agg: not sure what this is
order: column order and column select, I assume this is also used for column selection
What is missing above: row sorting (or was order used for rows, not columns?) and sorting direction. If order means row sorting then column select and column order is missing in the example.
Printing selected properties using other than tables would be quite difficult. In case of list view type one list item corresponds to one file and then in that list item you should print other list containing selected properties. This requires quite complex syntax and new functions.
For historical purposes, I want to report that I did follow @blue_emperorās approach and it got it to work until the most recent update (1.9.2 catalyst) rewrote the Bases function/syntax. I then update my codeblocks and the solution works again. For nontechnical users, however, note that the changes make the examples provided above less helpful.
I think Iād also add that I donāt think this (creating lots of one-row tables to materialize content otherwise segregated in the YAML property area) is the best possible approach for my notetaking purposes, which includes a lot of journaling and tracking.
What my original request asked for was a āproperties codebook.ā After two weeks of dabbling, I think the Bases codeblock would work if we can utilize other view types. I mentioned ālistā above, but I also wonder about the opportunity to simply display a formula property as a block, or bulleted list. The roadmap also mentions ācardsā which may be what I am looking for. Anyway, Iām a Coda.io user, and one of the tools I use there is to write a formula on the canvas drawing on data in a table. Such a codeblock (using current 1.9.2 syntax) might look like:
```base
filters:
and:
- content == "daily review"
- '!file.path.contains("Templates")'
- date == this.date
views:
- type: bulleted list
name: "Today's results"
order:
- date
- healthNotes
- weight
```
filters:
and:
- content == "daily review"
- '!file.path.contains("Templates")'
- date == this.date
views:
- type: bulleted list
name: "Today's results"
order:
- date
- healthNotes
- weight
I understand what you want but in this bulleted list query one list item corresponds to one file result determined by filters. This is how lists queries should work by default. Then you would want to specify what inline content is used for the list item. This could be any markdown code but in practice you would want other lists, a single line or some multiline text, pictures/videos/codeblocks/other embeds. The syntax should be very similar between lists and cards but obviously cards have grid and specific width/height. In your case I donāt see much difference using lists or cardsāboth should offer slightly less awkward view for your single file properties. You can use CSS to customize the view even more.
IA Writer has a nice, simple syntax ([%property]) for including metadata values in body text. Their metadata syntax is much the same as Obsidianās properties, so adopting their embedding syntax for this would provide interoperability (granted only with 1 app, but itās better than nothing). Metadata ā iA