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.