Thanks for the insight. This is just so annoying, it’s the feature that keeps me from fully committing to Obsidian
This is false. JSON allows both block and flow style. In fact, the JSON everyone is familiar with is flow style:
{
element: {
subelement: [1, 2]
}
}
The above is JSON and it is flow style. When Obsidian mangles it, it turns into:
element:
subelement:
- 1
- 2
That is not a familiar JSON format, and it is block style.
What makes you suggest that the frontmatter YAML (flow or block style) is converted internally to JSON (that is generally flow style) and therefore when it is written to YAML it has to become block-style? If this is genuinely the implementation the Obsidian team went with, it’s a terrible implementation.
You’re correct that nested YAML is compatible with JSON, in fact nested YAML is JSON.
You are right, JSON supports both block and flow style. I incorrectly said that Obsidian converts the YAML into JSON object, in fact what I ment is that obsidian parses the YAML into a java script object. I’m not an expert on how arrays are represented in memory on runtime, but I suppose, there is no difference whether the array was declared using block of flow-style notation. So even if you read a JSON object into a javascript object and dump it back into a JSON object using JSON.stringify you may not get the same formatting for your arrays.
Obsidian seems to use this YAML typescript library to parse and write the YAML frontmatter. This library currently seems to support only dashed lists when converting a javascript object to YAML. To address the issue one would probably need to change the library to better support the output of nested lists/arrays.
8 posts were merged into an existing topic: Plugin: Template Architecture and Nested Properties Editor for Complex Metadata Structures
+1 from me too , please
Use case or problem
Well, I know the obsidian team doesn’t seem to be a big fan of nested metadata information, but there are a lot of obsidian users who do use this (see also Properties: Support multi-level YAML (nested attributes)). My personal use case is an electronic lab notebook vault, that programmatically queries parts of the metadata of ELN notes to include them in other notes, which would not be possible without grouping (nesting) metadata information.
Now, it would be great to use the new bases plugin to create dynamic tables based on this metadata.
Proposed solution
I don’t know how the bases plugin is implemented, but it probably uses some kind of database to store the metadata information. So the easiest way to store the nested keys in the DB and query them would be to store a flattened version of the JSON frontmatter object. Like this the content of each nested key could accessed like any normal non-nested property.
Current workaround (optional)
There is no work around for this problem I would be aware of.
8 Likes
Using join(sort(row["user names"]), "<br>") in a dataview block, it is possible to read the values in the user names list property and display them in a column in a table cell. This makes the values much easier to read rather than bases which displays the values all concatenated.
Frontmatter:
---
user names:
- email:
- github: xyz
- gitlab: xyz
- jira: xyz
- slack: xyz
- rover: xyz
---
Example data view results:
email: -
github: xyz
gitlab: xyz
jira: xyz
slack: xyz
rover: xyz
vs. bases results
email: - github: xyz gitlab: xyz jira: xyz slack: xyz rover: xyz
3 Likes
Honestly I don’t know why this isn’t a thing yet. It would be a game changer for me and I was attracted to Obsidian because of the level of freedom of how I structure my infomation and the YAML data support.
3 Likes
Just one quick note here regarding bases.
It is possible to access nested attributes in formulas and filters using the dot notation.
parent:
child1: a
child2: b
parent.child1
9 Likes
Coming back to this. I am mostly concerned with the ability to edit these nested properties. I would bed the team realizes the “headache” it could create so maybe a consideration to makong a nested property core plugin that allows you to create custom types.
Just a thought. I am glad they functionally work with bases but i would like to be able to use them ourside of source view in a single note
5 Likes
With bases, is it possible to return values within object (linked notes) values in frontmatter? For example, I have a fileClass = “feature” note with field = “requirement” and value = “[[]]”. The fileClass = “requirement” note has a field = status. I would like to add a custom column to a base of “features” that shows the status of the associated requirement. In Dataview I can achieve this with requirement.state
Unfortunately not (yet) - there could be a function like Templater has (tp.file.find_tfile) that would get the referenced file, but at the moment such a function does not exist in Bases (maybe when API access for Bases gets released it can be built)
3 Likes
I hope they can add an “object” type.
3 Likes
Another +1. Object properties take my vault from good to great. As they function now is fine, but a UI around the concept would be such a time save.
1 Like
This would be awesome!
1 Like
+1 for this. Especially with Bases, objects in YAML are so intuitive!
1 Like
Use case or problem
I had like to be able to view and edit nested properties in the bases view. It is currently possible to view nested properties using “formulas”, though it is not possible to edit them.
Proposed solution
Add ability consider nested properties as valid columns instead of require the user to use formulas to display them.
I believe adding the ability to load nested properties as columns would enable its edition for free.
3 Likes
+1 Especially with Bases, the front matter is more integrated part of Obsidian than ever.
2 Likes
Bases seems really cool, but all the data I already have in my vault uses nested YAML structure extensively. I feel a little left out of being able to actually enjoy the new features unless I go through the task of scripting a way to convert the property structure across my vault.
Edit: I want to make it exceedingly clear that I will not consider restructuring my properties as a solution. Until nested properties are supported just like every other property, I won’t invest my time or energy to integrate Bases into my workflow.
2 Likes