[Feature Request] Add option to create yaml properties for fields instead of inline

[bluerosegarden]

Hello! Somewhere I had read that Typing does not support using YAML properties as fields because of the way Obsidian parses links, and that won't chance until Obsidian fixes the way linking works in properties. That is perfectly fine, however I would still love to be able to create empty yaml properties in a newly created note! It looks like the only way I can do so is to write some Javascript code, which I will absolutely do but I think just providing a ergonomic way to make empty properties is a nice middle-ground until the linking issue is fixed.

My usecase in the moment would be to add a reviewLater property that I can set as a bool in Obsidian's editor.

Thank you!

[konodyuk]

Could you clarify, is your request generally about adding a setting to store fields in frontmatter? As far as I know, the issue with links in yaml has been resolved, so supporting it is on my roadmap, but I cannot give any timeline, as this feature is of low-medium priority currently.

In the meanwhile, we can use this issue as a place for discussion of the potential implementation. My current view is roughly as follows:

1. add support for per-field configuration via marks:

type A {
    fields {
        one: String // stored as inline field by default
        two `yaml`: String // stored in yaml
        two `inline`: String // stored as inline field, specified explicitly
    }
}

2. add support for per-type default configuration via attribute:

type A {
    field_location = "yaml" // defaults to "inline", supports these two values
    fields {
        one: String // stored in yaml as mark is not specified and class-level setting defaults it to yaml
        two `yaml`: String // stored in yaml
        two `inline`: String // stored inline
    }
}

These concepts are rather unpolished, so the mark syntax and placement may be changed, as well as other details. Sharing them just for discussion.

Will the described features be sufficient for your use case? Unfortunately, I am not planning to add any intermediate levels of support, such as creating empty frontmatter fields. If you need, you can rather easily do it via on_create hook, where you can read the content of newly created note and add frontmatter prefix there. (The hooks are not documented currently, but soon will be.)

[bluerosegarden]

As far as I know, the issue with links in yaml has been resolved

Oh that's great then! I must've read something extremely outdated then hahaha.

Will the described features be sufficient for your use case?

YES Those would absolutely solve my usecase, and moreso since I prefer storing all my fields in the frontmatter anyways ^^. imo version 2 is best, because then it can be inherited easier for people like me who just wants everything to be stored in frontmatter. Version 1 would work better for people who mix inline and yaml but I don't know a reason why someone would want that?

edit: oh duh somehow I missed that in version 2 you can still set each field to a specific place, so yes I think 2 is the best option!

In the meantime I'll use the on_create hook once the documentation is finished! Thanks again