Hiding empty attributes or conditionally promoting them?

[pureume]

Hi folks, I am somewhat new to Trillium and am currently exploring its functionality to see how I might be able to adopt it.

Currently, I am trying to figure out if there is a way to hide empty attributes, or, alternatively, promote them conditionally (such as only on notes that have a particular label) when these are declared in a template the note inherits. I can think of two ways to achieve this currently:

1. Use multiple templates: For example, a Person template for all people, Author template for authors, Family template for family members, etc. This is somewhat cumbersome and tedious, and doesn't really solve the problem because there will always be scenarios where a note may inherit relation declarations but does not have relevant values for those attributes (so they are promoted but empty).

2. Promote attributes manually: in templates, the declared relations will be set to not promoted, and then on an individual basis you can re-declare the relation as promoted within individual notes. This is also error-prone and tedious. I am also not sure if there would be some kind of performance penalty for re-declaring attributes in every note.

There may be a robust way to achieve this, but I am still somewhat new and unfamiliar. Thanks in advance for your insight!

[dosubot[bot]]

Hi @pureume! I'm Dosu and I’m helping the Trilium team.

Unfortunately, there's no built-in way to conditionally promote attributes or hide empty ones in Trilium currently. This is actually one of the most-requested improvements — users report that long lists of empty promoted attributes consume excessive screen space, especially on mobile.

Here's what's available:

Built-in option: You can add #hidePromotedAttributes to specific notes to completely hide the promoted attributes widget on those notes. This is all-or-nothing though — you can't selectively hide just the empty ones.

Workaround with scripting: You can create a custom toggle button using a frontend script to show/hide the entire promoted attributes widget, but this only affects visibility, not which attributes appear.

Upcoming improvement: Collapsible promoted attributes are planned for an upcoming version, which will let you collapse/expand the section to reduce visual clutter.

For your template design, your intuition about multiple templates is actually the recommended approach — only include promoted attributes that most inheriting notes will actually use. You can also use a base template pattern: create a general "Entity" template with common attributes, then have specialized templates (Author, Family, etc.) extend it with domain-specific attributes via ~template relations.

Re-declaring attributes in individual notes shouldn't cause performance issues, but it does add management overhead as you noted.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}

   

[pureume]

Great answer, thanks dosu. Similarly, is there a performance penalty on the database level when declaring lots of relations that go unused by notes?

[dosubot[bot]]

Good question! Declaring unused relation definitions in templates shouldn't cause direct database performance penalties — only actual attribute/relation instances (rows with values) are stored in the attributes table. Relation definitions on templates are themselves stored as rows, but notes that inherit from the template don't get additional database entries just because a relation is declared.

That said, there are inheritance-related performance concerns to be aware of:

• Bidirectional relations on templates can cause cascading inheritance issues — all child notes inherit unintended relationships, creating performance degradation
• Deep template hierarchies with many chained templates can slow things down
• Attribute duplication can occur in complex inheritance structures where the same attribute gets listed multiple times

So the overhead isn't from unused declarations per se, but from how inheritance chains are resolved at runtime. Prefer one-way relations over bidirectional ones when possible, and keep template inheritance reasonably shallow.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}