Block-Embed-Dashboards
Dashboards aus echten Blöcken — live, nicht aus Kopien
- Du bettest einen Block per Embed ein und erkennst, dass es derselbe Block ist. ·· Erfolgskriterium: Du änderst den Block im Embed und weist die Änderung an der Heimat nach.
- Du baust ein Dashboard aus mindestens einem Embed und einer Query. ·· Erfolgskriterium: Dein Dashboard zeigt einen festen Block plus eine live berechnete Liste.
- Du erklärst den Unterschied Embed gegen Kopie und das Sichtbarkeits-Risiko. ·· Erfolgskriterium: Du nennst je ein Beispiel für sicheres und für riskantes Embedden.
Block-Referenzen geben jeder Aussage eine Adresse. Ein Embed geht den Schritt weiter: Es zeigt den Block selbst an einem zweiten Ort — denselben Block, nicht ein Abbild. So baust Du ein Dashboard aus echten Inhalten, das nie auseinanderläuft, weil es nichts kopiert.
Embed ist keine Kopie
Kopiere einen Block, und Du hast zwei Wahrheiten, die ab dem nächsten Edit auseinanderdriften. Embette ihn, und es bleibt eine Wahrheit, an zwei Orten sichtbar. Änderst Du den Block im Dashboard, ändert er sich auch an seiner Heimat — und umgekehrt. Das ist Transklusion: ein Inhalt, viele Fenster.
{{embed ((6c1b9a2e-7d84-4f12-a3b9-0e5c1d7f2a48))}}
;; zeigt denselben Block — eine Quelle, hier nur ein weiteres Fenster5 Regeln für Block-Embed-Dashboards
- Ein Embed ist der Block selbst, kein Snapshot — es gibt keine zweite Version, die veraltet.
- Edits synchronisieren in beide Richtungen: Dashboard und Heimat sind dasselbe.
- Mische Embeds mit Queries — feste Blöcke für Wichtiges, Regeln für das, was sich ändert.
- Ein Embed zeigt auch die Kinder des Blocks; wähle die Granularität bewusst.
- Lösche nie den Quell-Block, um ein Embed zu entfernen — entferne nur das Embed, der Block bleibt zu Hause.
Ein Dashboard aus Embeds und Query
## Sprint-Dashboard
{{embed ((a8e2d710-4f3b-4c1a-9e2d-5b7c8a1f0e63))}} ;; Sprint-Ziel, lebt im Planungs-Doc
{{query (and (property "type" "task")
(property "sprint" "aktuell"))}} ;; offene Aufgaben, liveVorher/Nachher — Copy-Dashboard vs. Embed-Dashboard
| Eigenschaft | Copy-Dashboard | Embed-Dashboard |
|---|---|---|
| Inhalt | Kopien | dieselben Blöcke |
| Aktualität | altert ab dem Einfügen | immer live |
| Edit | nur lokal, driftet | synchron, beide Wege |
| Quelle der Wahrheit | unklar (zwei Stände) | der Block selbst |
| Pflege | manuell nachziehen | keine |
Ehrliche Frage
Wie viele Deiner Dashboards zeigen kopierte Stände, die schon beim Einfügen veraltet waren? Die Antwort entscheidet, ob ein Dashboard Dir die Wahrheit zeigt oder nur ein Foto von gestern.
- Bau ein kleines Sprint-Dashboard aus genau einem Embed und einer Query. Bette einen festen Block ein, der anderswo lebt — etwa ein Sprint-Ziel — und ergänze eine Query für das, was sich laufend ändert, etwa die offenen Aufgaben. Ändere danach den eingebetteten Block im Dashboard und prüfe an der Heimat, dass die Änderung dort ebenfalls steht.⏱ 5 min
💡 Adressiere den Quell-Block zuerst über seine Block-Referenz und kopiere die ((id)) — dann fügst Du im Dashboard nur noch {{embed ((id))}} ein, statt den Inhalt abzutippen.
Musterlösung: Im Dashboard steht oben ein {{embed ((id))}} auf das Sprint-Ziel, darunter eine Query auf die offenen Aufgaben des aktuellen Sprints. Änderst Du das Ziel im Dashboard, steht dieselbe Änderung am Planungs-Doc, weil es derselbe Block ist und keine Kopie. Vor dem Teilen prüfst Du, dass kein eingebetteter Block vertraulich ist — denn ein Embed bindet Sichtbarkeit.
Was passiert, wenn Du einen eingebetteten Block im Dashboard änderst?
Ein Block, überall richtig.
Bau Dein Dashboard aus echten Blöcken, nicht aus Kopien — Dein Zweitgehirn hält jede Sicht aktuell, weil es nie etwas dupliziert. Ein Begleiter, der eine Wahrheit pflegt, keine Standbilder.
Slot sichern··kostenlos →