Deutsch
Francais
Nederlands
Svenska
Norsk
Dansk
Suomi
Espanol
Italiano
Portugues
Magyar
Polski
Cestina
Русский
Im modernen Webdesign ist es unerlässlich, responsive Layouts zu schaffen, die auf allen Bildschirmgrößen gut aussehen. Besonders beim Arbeiten mit komplexen Layouts wie CSS Grid kann die Anpassung an kleinere Bildschirme eine Herausforderung darstellen. Hier zeigt sich der Vorteil von benutzerdefinierten CSS-Eigenschaften in Kombination mit Media Queries, da diese Lösung sowohl kompakt als auch leicht verständlich ist.
Wenn wir uns das Beispiel eines Kurses ansehen, der sowohl Videos als auch begleitende Textbeschreibungen enthält, können wir durch die Kombination von CSS Grid und benutzerdefinierten CSS-Eigenschaften die Layouts so gestalten, dass sie sich flexibel an unterschiedliche Bildschirmgrößen anpassen. Die grundlegende Struktur des CSS-Grids sieht wie folgt aus:
Dieses Grid teilt den verfügbaren Raum in 12 gleichmäßig verteilte Spalten, wobei das Design so konzipiert ist, dass Inhalte dicht nebeneinander angeordnet werden, wenn der Platz es zulässt. Um nun die Position und Größe von Videos und Texten innerhalb des Grids zu steuern, können wir benutzerdefinierte CSS-Eigenschaften wie --videosize und --textsize einführen, um die Anzahl der Spalten, die einem Video oder Text zugewiesen werden, dynamisch zu bestimmen:
Durch die Verwendung der grid-column-Eigenschaft in Kombination mit benutzerdefinierten Variablen wird die Flexibilität erreicht, das Layout zu ändern, ohne dass der gesamte Code angepasst werden muss. Beispielsweise könnte der Video-Slider die --videosize-Eigenschaft auf einen Wert zwischen 3 und 7 begrenzen, während der Text-Slider automatisch den verbleibenden Platz aufnimmt.
Die Verwendung von grid-template-columns und benutzerdefinierten CSS-Eigenschaften ermöglicht eine präzise Kontrolle über das Layout der verschiedenen Elemente im Kurs. Eine wichtige Funktion, die in diesem Zusammenhang berücksichtigt werden sollte, ist die Interaktivität des Layouts. Die Video- und Textgrößen können durch Schieberegler in der Benutzeroberfläche angepasst werden, was eine dynamische Anpassung des Layouts zur Laufzeit ermöglicht:
Das Setzen dieser Variablen über die Schieberegler sorgt dafür, dass sich das Layout sofort ändert, wenn der Benutzer eine neue Größe auswählt. Eine zusätzliche Herausforderung entsteht jedoch, wenn externe Komponenten wie der YouTube-Player in das Layout integriert werden. Diese Komponenten haben möglicherweise ihr eigenes Layoutsystem, was zu Inkonsistenzen führen kann. Hier kann die Methode location.reload() verwendet werden, um das Layout neu zu laden und alle Komponenten zu rendern.
Ein weiterer wichtiger Aspekt bei der Gestaltung von Layouts für verschiedene Bildschirmgrößen ist die Verwendung von Media Queries. Media Queries ermöglichen es, bestimmte CSS-Regeln nur unter bestimmten Bedingungen anzuwenden, z. B. bei bestimmten Bildschirmgrößen. In unserem Fall können wir Media Queries verwenden, um das Layout für kleinere Bildschirme anzupassen:
Durch diese Anpassung wird das Layout auf größeren Bildschirmen beibehalten, während auf kleineren Bildschirmen die Kacheln (Tiles) auf eine einzelne Spalte umschalten, sodass sie besser lesbar und benutzerfreundlicher sind. Ein weiteres wichtiges Merkmal dieser Lösung ist, dass sie unabhängig vom Angular-Code funktioniert. Designer können sich auf die Gestaltung des Layouts konzentrieren, ohne sich um die zugrunde liegende Logik kümmern zu müssen.
Ein Vorteil dieser Methode ist, dass sie nahtlos in Systeme integriert werden kann, die Design-Tokens verwenden. Das bedeutet, dass Änderungen im Design, wie z. B. Farbänderungen oder Schriftgrößen, ohne das erneute Bereitstellen der Anwendung übernommen werden können.
Wichtig zu beachten ist, dass das Arbeiten mit benutzerdefinierten CSS-Eigenschaften und Media Queries nicht nur eine technische Herausforderung darstellt, sondern auch ein Verständnis für das Zusammenspiel zwischen verschiedenen Komponenten und deren Layoutsystemen erfordert. Besonders bei der Integration von externen Komponenten oder bei der Arbeit mit dynamischen Layouts, die auf benutzerdefinierte Einstellungen reagieren, kann es schnell zu unerwarteten Ergebnissen kommen. Es ist daher ratsam, immer wieder Tests auf verschiedenen Bildschirmgrößen durchzuführen, um sicherzustellen, dass das Layout auf allen Geräten gut aussieht.
Was sind die konkreten Vorteile und Einschränkungen der Ahead-of-Time-Kompilierung mit Angular Ivy?
Im Vergleich zur früheren View Engine ist das Ivy Instruction Set von Angular deutlich effizienter und tree-shakable. Das bedeutet, dass nur die tatsächlich im Anwendungscode verwendeten Instruktionen in das Produktionsbundle aufgenommen werden. Verzichtet eine Anwendung beispielsweise auf Mehrsprachigkeit, werden sämtliche Anweisungen zur Internationalisierung aus dem finalen Bundle entfernt. Ebenso verhält es sich mit Animationen: Werden sie im Code nicht verwendet, entfallen auch die entsprechenden Instruktionen. Dadurch reduziert sich die Bundle-Größe erheblich, was unmittelbare Auswirkungen auf die Ladezeiten und die Performanz der Anwendung hat.
Der entscheidende Unterschied zur View Engine liegt in der Art, wie die Templates verarbeitet werden. Während die View Engine zur Laufzeit die Datenstrukturen der Templates interpretieren muss, nutzt Ivy vorkompilierte Instruktionen, die direkt ausführbar sind. Das führt zu einer deutlich schnelleren Initialisierung und DOM-Manipulation zur Laufzeit.
Die Ahead-of-Time-Kompilierung (AOT) spielt eine zentrale Rolle in diesem Paradigma. Aktiviert man das strikte Template-Typprüfungsverfahren, lassen sich die meisten Typfehler frühzeitig erkennen – noch bevor die Anwendung überhaupt ausgeführt wird. Diese Fehler treten entweder beim Build-Prozess auf oder direkt im Codeeditor, sofern der Angular Language Service verwendet wird. Ohne strikte Typisierung könnten diese Fehler erst zur Laufzeit sichtbar werden, was potenziell zu schwer zu identifizierenden Problemen führt.
Ein bedeutender Fortschritt durch Angular Ivy betrifft auch die Testbarkeit. Im Gegensatz zur View Engine erlaubt Ivy die Ahead-of-Time-Kompilierung auch für Unit Tests. Gleichzeitig bleibt die dynamische Erstellung von Modulen, Komponenten, Direktiven und Pipes zur Testzeit möglich. Der AOT-Compiler wird in Kombination mit einem Just-in-Time-Prozess für dynamische Komponenten verwendet, was eine flexible und dennoch performante Testinfrastruktur ermöglicht. Zusätzlich beschleunigt ein Kompilierungs-Cache sowohl den initialen Build als auch nachfolgende Rebuilds.
Beim eigentlichen Deployment führt die Verwendung von AOT zu einem weiteren Vorteil: Der Just-in-Time-Compiler muss nicht mehr mit ausgeliefert werden. Die Anwendung startet dadurch schneller, da die Kompilierung bereits zur Build-Zeit erfolgt ist. Das verbessert insbesondere die Startzeit komplexer Anwendungen erheblich.
Allerdings bringt dieser Ansatz gewisse Einschränkungen mit sich. Deklarierbare Konstrukte wie Komponenten, Direktiven und Pipes dürfen nicht von Informationen zur Laufzeit abhängig sein. Sie müssen vollständig zur Build-Zeit analysierbar und kompilierbar sein. Das schließt die dynamische Konfiguration über serverseitige Daten oder externe Konfigurationsdateien im Kompilierungszeitpunkt aus – es sei denn, man entscheidet sich, den Compiler trotzdem zur Laufzeit zu laden, was jedoch dem Grundgedanken der Ahead-of-Time-Kompilierung widerspricht.
Eine Ausnahme stellen injizierbare Abhängigkeiten dar – Services, Funktionen oder Werte –, die auch zur Laufzeit bereitgestellt werden können. Dabei ist zu beachten, dass nur synchron verfügbare Werte direkt injiziert werden dürfen. Asynchrone Daten müssen über Services, Promises oder Observables abstrahiert werden, um AOT-kompatibel zu bleiben.
Besondere Vorsicht ist beim Umgang mit sogenannten Factory-Providern geboten. Die direkte Übergabe des Rückgabewerts einer Funktion an einen Value Provider ist nicht kompatibel mit AOT. Stattdessen muss eine Factory-Funktion verwendet und über useFactory registriert werden. Dies erlaubt es Angular, die Funktion erst zu einem geeigneten Zeitpunkt im Lebenszyklus der Anwendung auszuführen – beispielsweise zur Initialisierung einer Zeitzonenabhängigkeit.
Ein weiterer Grenzfall betrifft die Verwendung von Funktionen oder statischen Methoden zur Deklaration von Metadaten – etwa innerhalb eines Angular-Moduls. Enthält eine solche Funktion mehr als einen Rückgabepunkt oder sonstige Logik wie Bedingungen oder Schleifen, ist sie mit AOT inkompatibel. Das lässt sich durch eine Reduktion auf eine einzige Rückgabeanweisung in Form eines ternären Operators beheben, wodurch die Funktion für die Ahead-of-Time-Kompilierung akzeptabel wird.
Darüber hinaus sind auch getaggte Template-Literale nicht mit AOT kompatibel. Der Versuch, solche Literale direkt im Template einer Komponente zu verwenden, führt unweigerlich zu einem Kompilierungsfehler. Stattdessen empfiehlt sich die Konstruktion solcher Strings mittels einfacher Funktionen oder interpolierter Literale, die zur Build-Zeit vollständig aufgelöst werden können.
Wichtig ist bei all dem, dass das Zusammenspiel von strenger Typisierung, modularer Architektur und Kompilierungszeitpunkt die Grundlage für ein robustes und performantes Angular-Projekt bildet. Wer diese Prinzipien konsequent umsetzt, profitiert nicht nur von einer schnelleren Laufzeit und kleineren Bundles, sondern auch von einer besseren Wartbarkeit des Codes.
Zudem ist es essenziell zu verstehen, dass AOT nicht als Ersatz für saubere Architekturentscheidungen dient. Dynamische Features, wie sie etwa in stark konfigurierbaren Anwendungen benötigt werden, sollten gezielt durch Angular-Mechanismen wie Lazy Loading, Dependency Injection und modulare Services abgebildet werden. Die Einschränkungen von AOT sind keine Hürden, sondern leiten zu einem besseren Designverständnis hin.