Many Quartz users make significant customizations to components. While this is wonderful and we love to see it, it has a tendency to make updating Quartz a horrible experience. This leads to significant support time spent on frequently occurring issues.

To address these issues, we want to implement an extension to the component system to address these concerns.

The idea

• Extend the current component interface to expose more information.
  • Split the data into buildtime and runtime
    • Buildtime data is more extensive data about the entire state of your notes. (MDAST/HAST trees, frontmatter properties, link cache, etc.)
    • Runtime data is less extensive, but available on the client (list of folders/pages, tags, slugs, etc.)
    • Currently, components can only access runtime data.
  • Provide a way to sources for components
    • Think lazy.nvim.
• Provide a structured way for what components are expected to do (what inputs can be expected from Quartz, what should outputs look like)
  • Provide a template repository to use as a starting point for component development.
• Move all current Quartz components to separate repositories, likely under the Quartz Community
  • This allows for easy forking and modifying of these components without risking merge conflicts whenever Quartz updates.
  • This also slims down the main repository a lot.

TODO

• Extend existing component types
  • Add typings for plugin source
• Create a component template repository
• Move existing Quartz components to the Quartz Community.
• Figure out how to deal with dependencies of components (npm packages mostly)