RFC 34 - Type System for Notes

[jonathanyeung]

Discussion for RFC 34 - Type System for Notes

---

Note to readers: the Development Design section (https://wiki.dendron.so/notes/E8ZUvTzJ7cVOyZtqHiIKX.html#development-design) at the bottom wasn't meant to be included in the RFC - it was just a scratch note section as I was writing the spec, but I'll leave it there as some comments have already been made for that section.

Thanks!

[SR--]

Interesting, maybe a 'person' note? E.g., with filename surname.firstname.md but the title: Firstname Surname?

Will the types be preset or user-definable?

[jonathanyeung]

Will the types be preset or user-definable?

It'll be a mix of both - for types that we think everyone can benefit from, then we'll build those into Dendron (i.e. scratch notes, daily journal notes, to-do notes). Then, users must also be able to create their own types that cater to their own needs, or else we're failing the extensible part of the design. How exactly users do that is still something that needs refinement - that's part of the open question in this section of the RFC:

Extensibility - it should be possible to add new note types with relatively low friction. Varying levels of friction, with the top level being the level for MVP (minimal viable product)

1. Devs can define and add a new note type without altering core engine code
2. Devs can define and add a new note type without altering the Dendron extension (via supplementary extensions)
3. Users can define and add a new note type locally within Dendron itself (no touching of .vsix's necessary)

To which extent (1-3) we want for authoring and implementing note types is an open question.

How I'm thinking about this is that we'll probably iteratively expose functionality to a user-created type - it's relatively simple to expose basic operations such as applying a template to a type, or having custom control on a note name. However, it's not quite as simple to expose an API surface to allow a user to control the rendering behavior in preview.

It's a bit tricky to strike a balance between allowing dynamic behavior and having it be easy to implement by the user - take for example with hooks (https://wiki.dendron.so/notes/12551d19-04c2-4d26-ac1e-d23ff3181a9c.html) - it's powerful and dynamic in that you can arbitrarily run javascript by just dropping it into a file, but in terms of ease-of-implementation, it's quite hard to debug in this environment if something goes wrong.

[kevinslin]

Overall

• like the type system in general, what is the next step here in terms of implementation?
  • might be good to convert an existing note to a type (eg. journal notes)
    • the immediate implementaiton is to override getFrontmatterFields so that the journal date gets set based on journalFormat
• also, I don't

Open Questions

Should a note be aware of its parent note(s)? Leaning towards no
agreed
Should a note be aware of its siblings? Probably
agreed

How does someone (an end user) actually implement a type?

can a user drop javasciprt into {workspace}/types? we can dynamically import types for a given project

What if a user creates a schema that applies to pre-existing notes? As aligned with existing behavior, we will only apply templates to newly created notes.
this sounds right. we might add a lifecycle event, onConvert that takes place when you are changing types

[fdaguin]

1. About:

   Refactor Operations based on Types

   Some possible ways to refactor:

   • Modify Template (or more generally, modification of the type itself). Say you wanted to add an additional header to your template and apply it across all notes for that type

   • How will drift be detected between the note and its template? Will Specifying headers within blocks #248 be used?
   • How does the note will be synced with the template itself if drift is detected?

2. Does this feature aim to be compliant with the DITA Specification?

[ghost]

Just curiouse, what is the DITA Specification, and its purpose?

Following your link leads me to the Spec in full with no direct link or section That I could find for an explanation.

[ghost]

Okay this RFC opens a lot of possibilities in my mind.

But some core questions I would have:

1. Are Note Types extendable?
   For example, we have the Journal Note Type but I would like to have behavior X for my Private journal and behavior Y for a Project Journal, like different Templates or additional Frontmatter fields.
2. Could a Note type influence how the Note type is rendered in Dendron-based views?
   1. Would it be an option to customize the rendering of a Note Type in the Graph view?
      This would be in the future, but this could allow for Journal Notes to show an Icon of a Journal in the Graph view, and the Note type for Person could show an Icon for a Person to, have the option for more visual clues in the Graph view
   2. Option of customizing the Treeview
      Like showing an Icon for the Project status or the Todo Priority etc.
3. Could this system be used for Linting notes
   Like making sure the Note contains Certain Headers with a Block containing something, or that it contains certain Frontmatter Attributes with certain Values, like Project Status that is of Enum X