Aufteilung eines großen Laravel Livewire Components – Teil 1

In diesem Blogbeitrag erfährst du, wie du Livewire-Komponenten effektiv aufteilst, Views und Validierungsregeln strukturierst und Sub-Komponenten wiederverwendest. Optimiere deine Livewire-Entwicklung mit bewährten Best Practices. Bleib dran!

Manchmal, egal welche Lösung du zur Entwicklung deines Systems verwendest, kommt der Punkt, an dem alles etwas zu groß wird und unübersichtlich zu werden droht. Zum Glück bietet Livewire eine Lösung für dieses Problem.

Was ist Livewire?

Laravel Livewire bietet eine Möglichkeit, dynamische Benutzeroberflächen zu erstellen. Anstatt einer JavaScript-Bibliothek wie Vue oder React erlaubt es Entwicklern, ihren Code in PHP-Komponenten und Blade-Templates zu schreiben. Es ist fantastisch. Ich nutze es bereits im vielen Projekten. Wenn du es noch nicht ausprobiert hast, empfehle ich dir, es einmal anzuschauen.

Was ist das Problem?

Oftmals beinhalten Tutorials und Beispiele nur den Aufbau kleiner Komponenten, wie z.B. eines Kontaktformulars oder einer To-Do-Liste. Das ist vollkommen in Ordnung, da es ermöglicht, den Aufbau von Anfang bis Ende zu zeigen. Doch in einem Projekt aus dem wahren Leben hat man oft mit großen und sehr komplexen Systemen zu tun und erhalten hier dann kundenspezifische Anforderungen die umgesetzt werden sollen.

Nehmen wir als Beispiel eine Website zur Buchung von Mietwagen für den Urlaub. Bei der Buchung müssen Kundendetails wie Name und Adresse, der gewünschte Fahrzeugtyp sowie Extras wie zusätzliche Versicherungen oder sogar Hotelreservierungen erfasst werden.

Eine Herangehensweise wäre die Erstellung einer einzigen großen Komponente mit der gesamten Logik und einer einzelnen Ansichtsdatei, die immer länger wird. Das funktioniert wahrscheinlich gut, aber es gibt Tools, mit denen man diese Aufgabe in überschaubare Abschnitte aufteilen kann.

Die Aufteilung der Komponentenklasse mit Traits

Livewire v2 bietet eine großartige Funktion von PHP namens Traits, mit der man eine Datei erstellen kann, die innerhalb einer Klasse verwendet wird und der Klasse die Methoden und Eigenschaften des Traits zur Verfügung stellt. Dadurch kann man die Logik auf mehrere kleinere und besser handhabbare Dateien aufteilen und sie in der Hauptkomponente wiederverwenden.

Wenn wir zu unserem Beispiel der Mietwagenbuchung zurückkehren, benötigen wir möglicherweise ein Trait, das unsere Methoden zum Abrufen von Fahrzeugdaten enthält, ein weiteres Trait für Standortinformationen wie Adressen oder ein Trait zur Speicherung der Kundendetails.

Aber Livewire-Traits gehen sogar noch weiter.

Neben der Definition eigener Methoden können wir auch eine Namenskonvention verwenden, um uns in die Livewire-Lifecycle-Hooks einzuklinken. Wir haben gesagt, dass wir ein Trait erstellen werden, das sich auf Fahrzeuginformationen konzentriert, aber wie machen wir diese Daten für den Rest der Komponente verfügbar? Wir könnten eine Methode aus der mount-Methode der Hauptkomponentenklasse aufrufen, aber wir könnten dies auch im Trait selbst tun, indem wir die mount-Methode des Traits verwenden.

Wenn unser Trait „VehicleInformation“ heißt, können wir eine Methode „mountVehicleInformation“ in unserem Trait erstellen, in der wir die Fahrzeugdaten einer öffentlichen Variable zuweisen. Dadurch stehen sie der Hauptkomponente zur Verfügung.

Aus dem obigen Beispiel können wir sowohl in der Hauptkomponentenklasse mit $this->vehicles als auch in der Blade-View mit $vehicles auf die Fahrzeugdaten zugreifen.

Eine weitere Herausforderung bei der Entwicklung großer Livewire-Komponenten besteht darin, die Views und Validierungsregeln zu verwalten. Um die Code-Wartbarkeit und die Wiederverwendbarkeit zu verbessern, können wir auch hier auf die Aufteilung setzen.

Zusätzlich können wir Sub-Komponenten erstellen, um bestimmte Funktionen oder Abschnitte unserer Hauptkomponente zu modularisieren.

In meinem nächsten Beitrag werde ich detailliert darauf eingehen, wie wir dies auch erreichen können. Sobald dieser Beitrag fertig ist, werde ich hier einen Link bereitstellen, damit ihr ihn lesen könnt.

Bleibt gespannt und freut euch auf weitere Tipps und Tricks zum effizienten Entwickeln mit Livewire!

Mein Rückblick auf das Jahr 2022

Wie jedes Jahr, schreibe ich in den letzten Wochen des Jahres immer ein kurzes Review über das vergangene Jahr. Dies ist besonders für mich immer interessant, da ich mir wirklich bewusst nochmal Gedanken dazu mache, was gut oder schlecht gelaufen ist. Aber durch den Beitrag hier erhaltet ihr auch einen Einblick und vielleicht ein wenig Inspiration.

Gerade nutze ich die Zeit diesen Beitrag zu schreiben, auf dem Weg nach Köln zur diesjährigen Firmenveranstaltung. Es ist auch was besonderes dieses Jahr. Denn Tricept feiert den 22. Geburtstag. Darum sind neben den Mitarbeiterinnen und Mitarbeiter auch z.B. Kunden eingeladen. Auch für mich ist es dieses Jahr etwas besonderes. Denn ich bin nun auch schon seit 10 Jahren bei Tricept mit dabei.

Als ich vor 10 Jahren meine Ausbildung zum Fachinformatiker in der Anwendungsentwicklung angefangen habe, hätte ich nie gedacht so lange hier zu bleiben. Da ich zuvor eine Ausbildung zum Koch absolviert hatte, kannte ich viele Kollegen die oft nur wenige Jahre oder gar Monate in einem Betrieb gearbeitet haben.

Doch nicht bei Tricept. Nach meiner Ausbildung wurde ich übernommen und die Projekte und Aufgaben wurden immer vielfältiger und spannender. Natürlich aber auch fordendern und anspruchsvoller. Wenn ich zurück auf die letzten gut 8 Jahre blicke, die ich hauptsächlich im Bereich für Phoenix II gearbeitet habe, ist es wirklich erstaunlich was wir für ein tolles Produkt entwickelt haben und was ich auch alles dazu beitragen konnte.

Mittlerweile ist mein Beruf wirklich viel mehr als nur das reine Arbeiten. Es ist meine Berufung. Ich stecke neben der Arbeit auch in meiner Freizeit wirklich sehr viel Zeit in private Projekte und das Kennenlernen von neuen Funktionen, Packages oder Technologien. Dies ist auch der Grund, warum ich Tools wie Sitealarm.de, Zhylon.de oder meinen URL-Shortener entwickelt habe und auch ständig weiter am laufen halte.

Dieses Jahr war geprägt von vielen Änderungen. Auch durch einen Umzug in Sommer, musste ich viele Gewohnheiten umstellen und die neue Umgebung auf mich einwirken lassen. Insgesamt hatte ich dieses Jahr recht wenig Zeit in private Projekte gesteckt. Erst jetzt so gegen Ende Oktober gelingt mir es wieder besser.

Insgesamt glaube ich aber, dass ich meine privaten Ziele gut eingehalten habe und auch einige Projekte weiterentwickeln konnte. Ich habe mir ja extra nicht zu viel vorgenommen. Etwas schade finde ich jedoch weiterhin, dass ich viel zu wenig hier auf meinem Blog schreibe oder auf Twitter poste. Das werde ich vermutlich dann nächstes Jahr angehen.

Technologisch habe ich noch intensiver mit ClodFlare beschäftigt. Habe hier z.B. die Zero Trust Technology angesehen. Auch im Bereich Server Management im Bezug auf Zhylon habe ich einiges neues gelernt. Und mein Projekt Management Tool ist mittlerweile soweit ausgereift, dass es schon einige Bekannte als echte Lösung verwenden.

Ich hoffe das nächste Jahr geht genau so gut weiter wie es aktuell läuft. Noch etwas mehr Zeit für die Familie und vielleicht auch weiterhin mehr Bewegung durch Fitness.

Ich empfehle dir auch Mal auf die freien Stellen bei Tricept mal zu schauen. Wenn sich die Digitalisierung interessiert und eine Ausschreibung auf dich zu trifft, dann bewerbe dich gerne bei der Tricept.

Nun heißt es anpacken und die letzten Wochen des Jahres noch super abschließen.

Verschlüsselung der .env Datei

In modernen Anwendungen wie z.B. Laravel, werden häufig „.env“ Dateien verwendet, um Zugangsdaten für die Datenbanken, API-Token oder andere Zugangsschlüssel zu speichern (siehe https://dotenv.org/). Dies hat den Vorteil, dass diese nicht im Quellcode der Anwendung hinterlegt werden müssen und so an einer zentralen Stelle gespeichert werden. Außerdem kommen sie so nicht in die Versionskontrolle wo sie ggf. von Personen außerhalb des Projektes gelesen werden könnten.

Sobald ein neuer Wert in dieser Datei hinterlegt wird, muss dieser auch bei allen Entwickler im Team hinterlegt werden oder in die produktive Umgebung eingespielt werden. Gerade wenn es hierfür keinen richtigen Prozess gibt, wie die Zugangsdaten dann verteilt werden, könnte dies wieder unsicher übertragen werden. Vielleicht wird hier eine Rundmail geschrieben oder mit einer Message via Slack, Teams oder gar in WhatsApp verschickt. Und sollten sich die Werte auch nicht in Produktion automatisch oder per Deployment aktualisieren, dann muss hier auch immer händisch noch der richtige Wert hinterlegt werden.

Eine Lösung hierfür kommt von Dotenv selbst und bietet eine Synchronisierung. Doch wer Kosten sparen möchte oder eine Cloud Lösung nicht in Frage kommt, der steht wieder vor dem Ausgangsproblem.

Darum habe ich ein kleines Package gebaut, mit dem man die .env Datei sicher im Repository hinterlegen kann, ohne das es hier zu Bedenken der Sicherheit kommt. Mit dem Package lässt sich die lokale .env Datei sicher verschlüsseln und damit auch in das Repository einchecken. Andere Personen im Team können diese dann auschecken und dann wieder entschlüsseln. Das gleiche geht auch für die produktive Umgebung. So muss nur noch der geheime Schlüssel bekannt sein, welcher nur für ausgewählte Personen im Team bekannt ist.

Das Package findest du wie immer bei GitHub. Es befindet sich noch in der aller ersten Version: https://github.com/TobyMaxham/laravel-envcrypter

Wechsel zu MySQL wegen PHP MSSQL – Verbindungsproblem

In der Zhylon Cloud haben wir historisch einen MSSQL Server für die Abarbeitung der Jobs in einer Queue im Einsatz. Leider hatten wir in der Vergangenheit immer wieder Probleme beim Einsatz des SQL Servers von Microsoft. So auch der folgende Fehler, der einen Teil der Anwendung am vergangenen Wochenende lahm gelegt hat.

Nach einer Routinewartung hatten wir plötzlich Probleme, das die Anwendung sich mit dem Server Verbinden konnte. Wir haben hier, wie fast überall, Laravel 9 in der Standardkonfiguration im Einsatz und haben dann folgenden Fehler erhalten:

Fatal error: Cannot connect to server: 192.168.1.95\ZHYLONBD,3306 : SQLSTATE: 08001
code: 10054
message: [Microsoft][ODBC Driver 17 for SQL Server] TCP Provider: Error code 0x2746
SQLSTATE: 08001
code: 10054
message: [Microsoft][ODBC Driver 17 for SQL Server] Client unable to establish connection in DbConnector.php on line 110

Eine Lösung dafür haben wir schnell gefunden und wird von yitam auf GitHub im Repository vom microsoft/msphpsql beschrieben. Das Problem war wohl, das Versäumnis auf eine neuere Version des SQL Servers umzusteigen. Ein paar Tests mit Docker und dem SQL Server 2017 und 2019 waren erfolgreich und hatten keine Probleme. Allerdings hatten wir nicht geplant hier ein Upgrade auszuführen, da hiermit auch deutlich höher Kosten entstehen würden und wir sehr kritisch und auch unzufrieden mit dem SQL Server sind.

Wir haben uns daher kurzerhand dazu entschieden, die alte MSSQL Datenbank durch eine MySQL Datenbank zu ersetzen. Dies ging tatsächlich relativ schnell und es waren kaum Anpassungen notwendig. Ein paar Migrations mussten angepasst werden, da die Syntax nicht kompatibel war. Außerdem mussten wir für eine relativ alte Datenbank einmal alle Migrationen „rückwärts“ erstellen, da es hierfür keine Migrations gab. Wir haben hierfür das Package Xethron/migrations-generator verwendet, welches zwar nicht länger aktualisiert wird, es für diese einmalige Nutzung aber völlig ausreichend war.

Als Review zu dem Thema haben wir uns nun festgelegt, dass wir in den nächsten Monaten noch die ein oder andere ältere Struktur ablösen und modernisieren werden. Außerdem haben wir einen Prozess angestoßen, der zukünftig dafür sorgen soll, dass Updates und Upgrades zeitnah ausgeführt werden.

Neues Projekt: Laravel CRM

Wir haben lange darauf gewartet und jetzt ist es hier: Laravel 9. Und nach ein paar Wochen aktiver Benutzung bin ich wieder sehr begeistert von den ganzen Neuerungen.

Was mich auch sehr erfreut, ist der Ausschluss von PHP Versionen unter PHP 8. Zum einen ist es nun endgültig notwendig, Projekte auf PHP 8 umzustellen. Zum anderen wird diese Tatsache auch wieder Schwung in viele OpenSource Projekte und Packages bringen.

In diesem Zuge habe ich mir überlegt, ein neues Projekt zu starten. Ich möchte dabei möglichst viele Funktionalitäten mit Laravel abdecken und gleichzeitig an meinen Test-Driven-Development Skills arbeiten. Ich habe mir daher vorgenommen dieses Jahr an einem Customer Relationship Management zu arbeiten unter Verwendung von Laravel 9.

Das Ziel soll dabei also nicht die Konkurrenz zu anderen Produkten auf dem Markt sein, sondern viel mehr darin, gerade für Neueinsteiger in Laravel oder generell in die PHP Programmierung aufzuzeigen, was es alles für Funktionalitäten in Laravel gibt und wie man diese in einem echten Projekt verwenden kann.

Eine Idee zur Umsetzung wäre, dass ich aufgrund der Laravel Dokumentation einzelnen Task erstelle, welche dann umgesetzt werden. Dabei muss beachtet werden, dass die Umsetzung trotzdem realistisch sein muss und nicht mit aller Kraft dann irgendwie funktioniert.

Außerdem sollen auch die fachlichen Themen des CRM nicht vernachlässigt werden sondern eher Vorrang haben. Ich werde hier natürlich auch ein paar OpenSource und kommerzielle CRM ansehen, um hier die fachlichen Themen heraus zu arbeiten.

Das Projekt und alle dazugehörigen Themen werden OpenSource oder öffentlich zugänglich sein. Daher hoffe ich auch auf Unterstützung bei diesem Projekt. Jeder is herzliche zu Pull-Requests oder auch als Collaboration eingeladen.


Hier nochmal alle Links zur Übersicht.

Repository: https://github.com/TobyMaxham/laravel-crm

Projekt: https://github.com/users/TobyMaxham/projects/1