Was ist Invisible?
Invisible ist ein versioniertes, deklaratives UI-System: Oberflächen werden nicht programmiert, sondern als validierbare JSON-Strukturen beschrieben und von einem Produktionsrenderer (PHP) in HTML übersetzt.
Das Wichtigste zuerst: eine Bibliothek für alles
Die Schichten bilden zusammen eine pflegbare, standardisierte Bibliothek — und diese eine Bibliothek ist die Basis für alles, was auf ihr entsteht: den kommenden tricoma Desktop, Website-Templates, Shop-Templates, E-Mail-Marketing-Templates und Web-Apps. Ein Button wird EINMAL gebaut, gepflegt und versioniert — und erscheint überall; ein Theme-Wechsel oder ein Token-Update wirkt in jedem Kanal gleichzeitig. Es gibt keine Desktop-Buttons, Shop-Buttons und Mail-Buttons mehr, die auseinanderlaufen.
Das System beantwortet drei Probleme klassischer UI-Entwicklung gleichzeitig:
- Doppelte Wahrheiten: Jeder Baustein hat genau ein Manifest. Registry, Assets, Builder-Controls und Doku werden daraus generiert — nichts wird zweimal gepflegt.
- Unkontrollierbares Kunden-HTML: Kunden wählen Props und Design-Tokens — nie freie Klassen, nie CSS, nie JavaScript. Kunden-JSON ist grundsätzlich untrusted und kann das System nicht beschädigen.
- Kaputte Seiten nach Updates: Publizierte Seiten sind unveränderlich (immutable Versionen). Breaking Changes an Bausteinen liefern Migrationen mit — alte Seiten rendern weiter, bis sie beim nächsten Publish automatisch migriert werden.
Der Kerngedanke in einem Satz
Definitionen (was es gibt) und Instanzen (wie es verwendet wird) sind strikt getrennt — dazwischen steht eine generierte Registry, ein strenges Publish-Gate und ein toleranter Renderer.
Woraus besteht das System?
| Baustein | Aufgabe |
|---|---|
| Definitionen definitions/ | Der Katalog: Tokens, Layouts, Elements, Components, Blocks, Templates, Actions — je ein Ordner mit Manifest, Props-Schema, Renderer, CSS, Demo |
| Build build/ | Kompiliert Tokens → CSS-Variablen, validiert alle Manifeste, erzeugt Registry-Cache und gehashte Assets (@apply aufgelöst) |
| Kernel + Renderer kernel/, renderers/ | Render-Vertrag, Props-Validierung, Surface-Renderer (JSON → HTML), Publish-Gates, Migrationen |
| Runtime runtime/ | Interaktivität im Browser: Lifecycle, semantische Events, Action-Dispatcher, Services (Navigation, Window, Notification) |
| Builder-Stufenmodell *-builder.php | Pro Schicht ein Builder (Element, Component, Block, Template) + der Page-Builder — alle speisen die Registry, die Vorschau ist der Produktionsrenderer (keine zweite Rendering-Wahrheit) |
| Site-Vorlagen blueprints.php | Fertige Portale/Websites als Produkt: bündeln (inkl. eigener Design-Tokens), Kunden instanzieren sich ihre eigene, pflegbare Kopie |
Weiter mit Wie wird es genutzt? — oder direkt ins Ebenen-Modell.