I had sent this RFC to the Dendron team.
RFC for blocks and queries features in Dendron
These features are heavily inspired by Notion , Logseq , Editorjs and the Wordpress block editor .
Disclaimer: I’m relatively new to Dendron. This is a proposal for adding features that are currently missing in Dendron and which I personally would love to see. I think adding these features would make Dendron even more awesome.
Blocks
The proposal is that content in a Dendron note is organized in units call ‘blocks’. A block can hold any type of content, including text, images, tables, etc. There would be a large number of “built-in” blocks and the possibility for users to create their own block types (see, for example, how Editorjs enables this). Blocks can be nested arbitrarily deep within one another. For the purposes of this RFC, I’ll focus on blocks that have text content. That text content can be paragraphs, ordered and unordered lists, quotes, checklists etc.
Blocks can have attributes and properties. These would be arbitrary key-value pairs, although each block would have some defaults that make sense for that block type (for example, a ‘Done’ property for checklist block lines). See this blog post
that explains how Notion manages block attributes and properties. In Notion, attributes are key-value pairs present for every block. Properties are key-value pairs that contain custom attributes for a specific block or block type. Block attributes/properties could show up and be added/edited/deleted in a separate properties panel in the UI, but certain properties could also be added by typing in-line text in the block. For example, the text #tagname in a block would be used to tag that block with tagname, and the list of tags would be an attribute of the block.
A text note in Dendron would just be a collection of ordered blocks i.e. a set of blocks appearing in a particular sequence. The same block(s) may appear in other notes. When a block is updated in one note, the updates show up in all other notes where that block appears. (Dendron already has something similar: Note references).
When typing a note, new blocks could be created by typing a sequence of characters that imply “a new block begins here”. The simplest example is that a new block is created simply by pressing the ‘Enter’ key (which is how logseq works by default, although this can be configured in the settings). The type of block could be selected graphically from a dropdown (similar to Wordpress editor) or, even better, the / key can be pressed and that can result in a small dropdown immediately in front of the cursor, from which the type of block can be selected (this is similar to how logseq does it). The default new block type can be a text paragraph.
A nice-to-have feature would be that a block’s type can be changed after the block is created. Notion supports this. It especially makes sense for blocks that are all text.
Block queries
Since blocks have attributes and properties, it should be possible to query for blocks whose attributes/properties meet a defined criteria. The critera can be specified through a regex or something more user-friendly, or both. The ideal way to make a query should be right in a note. Imagine that the cursor is at the start of a note (or anywhere in the note body, for that matter) and the user types something like “/query foobar”. If that is a well-formed query, the results of the query should appear immediately below, in the note. This is how it works in logseq. For example, typing ‘/query tagname’ (without the ‘’) results in the in-situ text {{query tagname}} and all blocks tagged with tagname appear below the query line. The result is “dynamic” in the sense that if you open a different note, add a new block tagged with tagname, then go back to the earlier note containing {{query tagname}}, then the newly tagged block would appear in the query results.