Hierarchies
Summary
Within a vault, your notes are stored hierarchically as .
delimited markdown files.
Below is a hypothetical hierarchy for a file tree:
.
└── project1/
├── project1/designs/
│ └── project1/designs/promotion.png
├── project1/paperwork/
│ └── project1/paperwork/legal.md
└── project1/tasks/
├── project1/tasks/task1.md
└── project1/tasks/task2.md
The same hierarchy in Dendron would look like the following:
.
├── project1.md
├── project1.designs.md
├── project1.designs.promotion.md
├── project1.paperwork.md
├── project1.paperwork.legal.md
├── project1.tasks.md
├── project1.tasks.task1.md
└── project1.tasks.task2.md
Concepts
In the following concepts, we will be using the following file tree
From Layout
Go to text →
Basic
.
├── dendron.code-workspace
├── dendron.yml
├── .dendron.port
├── .dendron.meta
├── docs/
├── .gitignore
└── vault/
├── root.md
├── root.schema.md
├── dendron.md
├── dendron.faq.md
├── ...
└── assets/images
- dendron.code-workspace
- vscode and dendron configuration
- dendron.yml
- dendron specific settings
- .dendron.port
- writes the port that the dendron engine is listening to
- .dendron.meta
- writes dendron specific metadata
- .gitignore
- add special notes
- docs/
- used to generate a static site from your vault
- vault/
root.md
- generated by dendron, root of all your hierarchies
root.schema.yml
- generated by dendron, root of all of your schemas
- assets/images
- default for
Dendron Paste Image
extension to put images in
- default for
Terms
workspace root
This is the folder where dendron.code-workspace
is located
Root
Every vault has a root. This is the root.md
.
Domain
The domain is the root of a specific hierarchy. In our example vault, we have one domain - dendron
.
Why Hierarchies?
Dendron is built around hierarchies and the axiom that a canonical hierarichal representation of notes is one of the most effective ways of managing large numbers of notes. You can read more about the thoughts behind this here.
.
's?
What's with the - It allows each file to also be a folder. This means your notes can have data but also contain other notes.
- It makes it much easier to perform certain refactoring operations. For example, say you had the following schema
Lets say you wanted to make- id: a-parent children: - child-a - child-b - id: child-a - id: child-b
child-b
a child ofchild-a
With the classical folder hierarchy, you would need to turn- id: a-parent children: - child-a - id: child-a children: - child-b - id: child-b
child-a
into a folder and then create a custom file to hold the content from the originalchild-a
With the. └── a-parent └── child-a ├── child-a-note └── child-b
.
delimited hierarchy, this becomes a simple rename operation. ├── a-parent.child-a └── a-parent.child-a.child-b
- It allows us to create stubs for parts of the hierarchy that don't exist and not clutter our file system with empty folders. With the classical folder hierarchy
With the. └── a-parent └── child-a └── grandchild-a └── great-grandchild-a.md
.
delimited hierarchy. └── a-parent.child-a.grandchild-a.great-grandchild-a.md