Warum ich Angular für den Aufbau eines URL Shorteners gewählt habe

URL-Shortener sind Werkzeuge, die wir verwenden, um Links kürzer zu machen, als sie tatsächlich sind. Mit einem URL-Shortener können Sie einen langen Link (vielleicht für ein Anmeldeformular oder einen Artikel) in eine kürzere Version umwandeln.

Im Hintergrund werden die lange und die kurze Version eines bestimmten Links in einer Datenbank gespeichert. Wenn ein Benutzer dann den kurzen Link in einem Browser besucht, leitet der URL-Shortener den Benutzer zur langen Version des Links weiter (wo der eigentliche Inhalt zu finden ist).

Verkürzte Links von URL-Shortenern werden häufig verwendet, wenn die lange Version dieser Links zu lang wäre, um sie zu verwenden. Das Teilen von Links in sozialen Medien oder das Gestalten von Flyern und Anzeigen sind beliebte Anwendungsfälle für URL-Shortener.

Für eines meiner Projekte habe ich einen persönlichen URL-Shortener erstellt. Meine Absicht war es, ihn für Links zu Artikeln, die ich schreibe, oder Videos, die ich produziere, zu verwenden. Ich habe Firebase verwendet, um das Backend des URL-Shorteners zu erstellen. Insbesondere habe ich die Firestore-Datenbank verwendet, um kurze und lange Versionen eines beliebigen Links zu speichern.

Um Links zu erstellen, musste ich die Firebase-Konsole verwenden. Das war kein Problem, aber bei der häufigen Bearbeitung von Links war es umständlich. Die Benutzererfahrung (UX) war nicht ideal. Nun stand ich vor einem Problem. Wie erstelle, bearbeite und lösche ich Links? Ich musste ein Frontend für den URL-Shortener erstellen. Ich brauchte dafür eine Website.

In diesem Artikel werden wir die verfügbaren Tools, die für den Aufbau dieses Frontends verwendet wurden, die getroffenen Entscheidungen und die Faktoren, die zu diesen Entscheidungen geführt haben, untersuchen.

Problemstellung

Die Projektanforderungen waren

• Plattform/Architektur. Die Ingenieurskunst und Struktur des Codierungsprozesses.
• UI-Toolkit. Komponenten, die für die verschiedenen Teile der Benutzeroberfläche verwendet werden.
• Komfort. Das Backend zu erstellen war nicht schwierig, also sollte dieses Frontend auch nicht schwierig sein. Ich wollte sauberen Code und schnelle Entwicklung.

Die erste Entscheidungsfindung: Angular

Viele Ideen kommen einem in den Sinn, wenn man anfängt, ein Frontend zu entwickeln. Im Großen und Ganzen können wir die Optionen für die Frontend-Entwicklung in 3 Plattformen kategorisieren

1. Website-Builder – wie WordPress, Wix, Squarespace usw.
2. Vanilla-Entwicklung – mit reinem HTML, CSS und JavaScript.
3. JavaScript-Framework – wie React, Vue, Angular usw.

Meiner Erfahrung nach bieten Website-Builder eine sehr eingeschränkte Auswahl an Widgets, Komponenten und Vorlagen. Die meisten Website-Builder bieten keine einfache Möglichkeit, ein komplettes benutzerdefiniertes Backend wie Firebase zu integrieren. Obwohl es möglich ist, beeindruckende Websites zu erstellen, indem man diese Teile zusammenfügt, war die Komplexität meines Projekts wahrscheinlich über das hinausgehend, was diese Dienste normalerweise bieten.

Die Verwendung des No-Framework-Stils oder Vanilla wäre eine Möglichkeit gewesen. Der entscheidende Faktor, der mich davon abhielt, die reine Vanilla-Route zu wählen, war jedoch, dass die neueste Nicht-CDN-Version des Firebase JavaScript SDK (Version 9) für die Installation über npm oder yarn und das Modul-Bundling ausgelegt ist.

JavaScript-Frameworks kümmern sich um Kernfunktionen des Frontends (wie Routing, Backend-Anbindung usw.), um den Aufwand für Entwickler zu reduzieren. Es gibt viele davon, und die Wahl, welches verwendet werden soll, schien eine schwierigere Entscheidung zu sein.

Es gibt viele JavaScript-Frameworks für die Frontend-Entwicklung. Beispiele sind Angular, React, Vue usw.

Von den verfügbaren Frameworks bin ich mit Angular am vertrautesten. Das liegt daran, dass ich es in früheren Projekten wie diesem verwendet habe

• Choir Carol Quiz: Ein Portal, bei dem Quizteilnehmer in zwei Runden von zeitgesteuerten Multiple-Choice-Fragen zu ausgewählten Bibelkapiteln gegeneinander antraten.
• Genesys AE-FUNAI Community: Ein benutzerdefiniertes Formular, mit dem Mitglieder des Genesys Campus Club AE-FUNAI (meine Community) ihre Fortschritte melden und ihre Erfolge teilen können.
• Tutorial Management System: Ein einfaches Dashboard zur Sitzungsverwaltung zwischen Studenten und Tutoren.

Diese Vertrautheit ermöglicht es mir, schnell mit Angular zu entwickeln. Die Fähigkeit, schnell zu entwickeln, sollte nicht unterschätzt werden.

Ich habe Angular wegen seiner objektorientierten Programmierung (OOP) gewählt. OOP ist ein Programmierparadigma, das sich stärker auf Klassen, Daten oder verwaltete Zustände konzentriert als auf die Logik, die die Daten steuert, wie es bei der funktionalen Programmierung der Fall ist. Die Trennung von Belangen ist ein Vorteil der Verwendung von OOP. Mit anderen Worten, OOP ermöglicht Kapselung. Es ermöglicht Ihnen, Aspekte des Programms auf bestimmte Domänen oder Klassen zu beschränken.

In Angular sind Komponenten (und ihre Lifecycle-Methoden) an TypeScript-Klassen gebunden. Das lässt einen auf die OOP-Art denken. Der OOP-Vorteil spiegelt sich darin wider, wie Angular-Komponenten als wiederverwendbare UI-Einheiten im Angular-Framework dienen. So sehen Sie eine Angular-Komponente als eine eigenständige Einheit, die dennoch Teil eines Ganzen ist. Das erleichtert die Frontend-Entwicklung, da verschiedene Teile der Frontend-Anwendung Komponenten zugeordnet und somit dort verwendet werden können, wo sie benötigt werden.

Ich habe Angular auch gewählt, weil es TypeScript verwendet. TypeScript ist JavaScript mit Merkmalen einer typisierten Programmiersprache. Typisierung bedeutet in diesem Zusammenhang, dass eine Variable die Art des Wertes, den sie enthält, während ihrer gesamten Lebensdauer nicht ändern kann. Zum Beispiel wird eine Variable, die einen String enthält, nicht plötzlich eine Zahl enthalten, während sie in diesem Programm verwendet wird. Typisierung erhöht die Codequalität und reduziert Fehler.

Aufgrund seines Typsystems reduziert TypeScript die Zeit, die für das Debugging von Angular-Anwendungen aufgewendet wird. Es bietet eine gute Entwicklererfahrung, da der Entwickler mehr Zeit für den Aufbau der Frontend-Anwendung hat. Auch das Debugging wird für den Entwickler einfacher.

Hinweis: Hier erfahren Sie mehr über objektorientierte Programmierung mit TypeScript

Noch zu den Vorteilen von Angular: Angular-Anwendungen kommen als komplette Einrichtung. Sie kümmern sich selbst um wichtige Funktionen wie das Bündeln von CSS-Präprozessoren oder Angular-Services. Das bedeutet, wenn Sie Angular verwenden, müssen Sie jede Bibliothek nicht einzeln konfigurieren, Angular kümmert sich darum.

Ein Angular-Service ist das, was Angular zur Konfiguration der Dependency Injection verwendet. Einfach ausgedrückt, ist Dependency Injection die Bereitstellung einer Anwendung mit dem, was sie zum Funktionieren benötigt (Dependencies), ohne dass sich die Anwendung darum kümmern muss, wie die Dependencies erhalten wurden. Ich habe mich auch wegen der Out-of-the-Box-Verwaltung von Services für Angular entschieden. So wird z.B. Firebase automatisch allen Angular-Komponenten zur Verfügung gestellt, die es benötigen, ohne zusätzliche Konfiguration.

Die Vorteile von objektorientierter Programmierung, TypeScript und Dependency Injection machen Angular zu einer guten Wahl für die Frontend-Entwicklung. Gekoppelt mit der Tatsache, dass ich mit Angular bereits vertraut war, war Angular für dieses URL-Shortener-Projekt praktischer.

Angular-Artikel auf CSS-Tricks sind ebenfalls Teil der Geschichte. Sie gaben mir mehr Vertrauen in die Verwendung von Angular.

Die zweite Entscheidungsfindung: Material Design

Nachdem ich Angular ausgewählt hatte, war meine nächste Aufgabe die Überlegung, wie ich die Benutzeroberfläche (UI) gestalten würde.

Ich könnte es ignorieren und stattdessen Vanilla CSS verwenden, aber warum das Rad neu erfinden? Schließlich würde dies den Grund für die Verwendung eines JavaScript-Frameworks – Komfort – zunichte machen.

Bei der Wahl eines UI-Toolkits scheint es eine Fülle von Optionen zu geben. Um nur einige zu nennen: man kann Bootstrap, Bulma, Semantic UI, Tailwind usw. verwenden. Jedes Toolkit hat seine eigenen Spezifikationen und Motivationen.

Für den Anwendungsfall meines Projekts führte Material Design die Gruppe an.

Einer der wichtigsten Faktoren war die Unterstützung für Angular und Material Design. Es gibt eine reine Angular-Spezifikation für Material unter material.angular.io (das ist eine Unterdomäne der Angular-Dokumentation selbst).

Ich habe mich für Material Design entschieden, da es sich auf Komponenten konzentriert. Im Gegensatz zu anderen CSS-Frameworks hat es keine CSS-Utility-Klassen. Das war in Ordnung, da ich nur ein Komponenten-Kit wollte (Schaltflächen, Symbole, Eingabefelder, Seitenleisten, Snackbars usw.). Material fügt auch selbst Animationen, Ripple- und Schatteneffekte hinzu; das macht es praktischer als andere Bibliotheken.

Darüber hinaus bietet Angular Material eine Out-of-the-Box-Theming-Unterstützung. Bei der Initialisierung von Angular Material haben Sie die Möglichkeit, ein vordefiniertes Thema für die gesamte Angular-App auszuwählen oder ein benutzerdefiniertes zu erstellen.

Aus Bequemlichkeitsgründen habe ich bei der Einrichtung von Angular Material ein dunkles Thema gewählt.

Die dritte Entscheidungsfindung: Reaktive Formulare

Nachdem ein Framework und ein Toolkit festgelegt waren, widmete ich mich einer der wichtigsten Funktionen des URL-Shorteners. Der Kern des Frontends des URL-Shorteners ist das Formular zur Erstellung und Aktualisierung von Links.

Nennen wir dieses Formular den Links-Editor. Das Formular des Links-Editors hat nur zwei Eingabefelder, eines für die kurze Version eines Links und das andere für die vollständige URL, zu der die kurze Version weiterleiten wird.

Zur Verwaltung von Formularen bietet Angular zwei Mechanismen. Anstatt also ein Formular zu erstellen und dessen Validierung und Übermittlung zu handhaben, wie es bei reinem HTML und JavaScript geschieht, muss man eine der beiden von Angular bereitgestellten Möglichkeiten nutzen. Die beiden Methoden sind

1. Template-gesteuerte Formulare
2. Reaktive Formulare

Template-gesteuerte Formulare kontrollieren, wie der Name schon sagt, den größten Teil des Angular-Formulars über den HTML-Code (Template). Dieser Ansatz ist vorzuziehen, wenn Ihr Formular nicht viel tut oder für den einmaligen Gebrauch bestimmt ist.

Reaktive Formulare bieten hingegen einen modellgesteuerten Ansatz zur Handhabung von Formulareingaben, deren Werte sich im Laufe der Zeit ändern. Ich benötigte reaktive Formulare, da dies dasselbe Formular ist, mit dem ich jederzeit verschiedene Links bearbeiten würde.

Hinweis: Hier finden Sie weiteres Material zur Verwendung reaktiver Formulare.

An dieser Stelle spielten die Vorteile früherer Entscheidungen eine Rolle. Angular Material hat form-field-Komponenten. Das form-field umschließt die Eingabe als Komponente und bietet bei Bedarf Animationen, Ripple-Effekte und Fehlermeldungen.

Daher habe ich es für die beiden Eingabefelder des Editor-Formulars verwendet.

Die vierte Entscheidungsfindung: Angular Material Bottom Sheet und Drawer

Die letzte Entscheidung betraf die Verbesserung der Benutzererfahrung. Der URL-Shortener würde andere Funktionen benötigen, wie z.B. die Anzeige aller erstellten Links und deren Analysen. Diese Funktionen würden Platz auf dem Bildschirm beanspruchen, was mich dazu veranlasste, darüber nachzudenken, ob es bessere Lösungen gäbe, das Links-Editor-Formular dem Benutzer anzuzeigen.

Wenn der Benutzer derzeit kein Interesse am Links-Editor-Formular hat, ist es sinnvoll, dass das Links-Editor-Formular nicht immer sichtbar ist. Dies würde Platz in der Benutzeroberfläche für andere Elemente freimachen.

Das Aufteilen dieser Benutzererfahrung in zwei separate Seiten fühlte sich jedoch störend an. Stattdessen habe ich, um das Links-Editor-Formular bei Bedarf zu öffnen, eine Floating-Action-Button auf der Seite zum Erstellen von Links hinzugefügt. Wenn dieser Button geklickt wird, öffnet sich das Editor-Formular in einer passenden UI-Komponente.

Ein Bottom Sheet ist, wie der Name schon sagt, eine UI-Komponente, die sich vom unteren Bildschirmrand öffnet. Es enthält interaktive Inhalte, mit denen der Benutzer arbeiten kann. Es überlagert die aktuelle Ansicht eines mobilen Bildschirms (blockiert sie aber nicht vollständig).

Bottom Sheets werden normalerweise anstelle von Pop-ups verwendet, wenn der Benutzer viel Zeit mit der Interaktion mit ihren Inhalten verbringt. Bottom Sheets sind also gut geeignet, um den Editor auf mobilen Bildschirmen zu öffnen. Die Interaktion mit einem Bottom Sheet ist jedoch schwierig, wenn der Bildschirm breit ist. Ich benötigte eine andere UI-Komponente für das Links-Editor-Formular auf breiten Bildschirmen.

Drawer öffnen sich seitlich. Die Verwendung eines Drawer zum Öffnen des Links-Editor-Formulars auf einem breiten Bildschirm war die beste Option. Drawer wären für den Editor auf mobilen Bildschirmen nicht gut geeignet. Die Bildschirmbreite wäre relativ gering und der Drawer könnte den Bildschirm vollständig verdecken (was keine wünschenswerte UX ist).

Ich habe diese beiden UI-Komponenten von Material Design für das Formular ausgewählt, um einen gewissen responsiven Effekt zu erzielen. Egal ob auf meinem Handy oder Laptop, die Erstellung von Links würde in einer passenden UI-Komponente erfolgen.

Im Code prüft Angular, ob das Gerät eine kleine Bildschirmbreite hat. Wenn ja, öffnet es ein Bottom Sheet, das das Links-Editor-Formular enthält. Wenn der Bildschirm hingegen breit ist, öffnet Angular einen Drawer, der dasselbe Formular enthält.

Die Verwendung dieser beiden Komponenten brachte eine geringfügige Komplikation mit sich. Wenn mein Handy gedreht wird oder die Fensterbreite meines Laptop-Browsers verringert wird, öffnet sich das Formular in der entgegengesetzten UI-Komponente. Das heißt, anstatt sich auf einem Laptop in einem Drawer zu öffnen, öffnet es sich in einem Bottom Sheet (weil die Browserbreite reduziert wurde).

Wartung, Zukunftssicherheit, zukünftige Releases

Als ich über Möglichkeiten zur Iteration an diesem Projekt nachdachte, stieß ich auf Einschränkungen bei der aktuellen Anwendungsfallgestaltung für einen einzelnen Administrator. Aber mit Authentifizierung und Benutzerkonten könnte es zusätzliche Benutzer unterstützen, die Links verwalten und auf Analysen zugreifen.

In diesem Fall wären die oben genannten Komponentenwahlen immer noch angemessen. Der Links-Editor ist responsiv, sodass Benutzer auf jedem Gerät eine gute Benutzererfahrung haben.

Wenn ich es noch einmal tun müsste, würde ich glaube ich die Vanilla-Methode ausprobieren. Komplett ohne Helfer wie Angular, Material oder UI-Komponenten entwickeln. Ich würde versuchen, von Grund auf in HTML, CSS und JavaScript zu entwickeln und sehen, ob ich nicht an Komfort verliere, wie ich es mir vorgestellt habe.

Fazit

Den finalen Angular-Code finden Sie hier auf GitHub.

Dies war eine Überprüfung einiger der wichtigsten Entscheidungen, die ich bei der Entwicklung meines Projekts getroffen habe. Natürlich gibt es mehr, als nur das Frontend eines URL-Shorteners zu entwickeln. Aber für den Anfang machten diese UI-Komponenten den Entwicklungsprozess bequem. Sie machten das Links-Editor-Formular responsiv und könnten für Sie in Ihren Projekten von ähnlichem Nutzen sein (nicht unbedingt ein URL-Shortener).

Es gibt viele andere UI-Komponenten aus verschiedenen Bibliotheken, die Sie für solche Projekte verwenden können. Aber wie in meinem Fall, wenn Komfort ein entscheidender Faktor ist, werden Sie die richtige Entscheidung treffen, die für die UI passend ist.

Letztendlich prägten das Verständnis dessen, was mein Projekt benötigte, die Kenntnisse über Tools, die ich aus früheren Projekten verwendet hatte, und die Erwartungen an Zeitbeschränkungen meine Entscheidungen. Meine Erfahrungen aus der Vergangenheit – Erfolge und Fehler – halfen mir ebenfalls.

Prost!