Context Variable Expansion on Templates

WHAT DO YOU RECOMMEND?

Add templating mini-DSL with expansion on object creation, e.g. {{today}}

Including on titles.

Define and limit what’s in the context, e.g.

  • Date related universal context
  • Current object context ({{this}} ?
  • Current user, e.g. {{me}}
  • Current location, e.g. {{location.city}}?
  • API provided {{ctx}} - for scripting / integration

I’recommend simple string expansion for an MVP (except maybe for {{this}}, if decided). Object matching could be thought of later on, for example by a detecting a context value that looks like a json string, e.g. {anyID: ..., strRepr: ..., objForCreation: {type: ..., ...}}

REAL WORLD USE CASES

ADDITIONAL CONTEXT

IMO, a mini-DSL is a fundamental primitive of templating. The possibility to combine it with API-provided context provided for new level of interesting integration scenarios.

Might leverage some.implemented primitives from: Shorcuts for insterting dates inline - #27 by MarchCowboy55

My AI assistant’s blob. I found it adds.

Suggested Implementation Approach:

A shortcode syntax such as {{today}}, {{now}}, {{date:format}}, or {{user}} would provide immediate utility while remaining intuitive. This could extend to:

  • Date/time variables: {{today}}, {{now}}, {{yesterday}}, with optional formatting ({{today:YYYY-MM-DD}})
  • User context: {{user.name}}, {{user.id}}
  • Object context: {{object.id}}, {{object.createdDate}}, {{object.type}}
  • Set/collection context when applicable

Key Use Cases:

  1. Daily journaling: Automatic date in titles without manual entry
  2. Meeting notes: Pre-populated with current date, attendee names, and meeting type
  3. Project management: Templates that include creation timestamp and responsible user
  4. Recurring tasks: Dynamic due dates relative to creation (e.g., {{today+7}})

Technical Considerations:

  • Variables should evaluate at object creation time, not template save time (addressing the issue in #2824)
  • Support for date math ({{today+3 days}}) would enable powerful workflows
  • Consider escaping mechanism for literal braces when needed
  • Maintain backward compatibility with existing templates

Priority Suggestion:
This feature would significantly improve Anytype’s competitiveness with other PKM tools that offer similar functionality (Obsidian, Notion, etc.). The implementation complexity appears moderate given the existing template infrastructure, and the user value is substantial.

PR find: Feature/JS-8994: Template placeholders by ra3orblade · Pull Request #2101 · anyproto/anytype-ts · GitHub - possibily limited in scope.