Willkommen auf den JavaScript, Angular, React und HTML & CSS Days. Die finden gerade unter uns statt und wir haben uns einen Trainer geschnappt: Fabian Gosebrink. Hi Fabian. Schön, dass du da bist und uns ein paar Fragen beantwortest rund um dein Workshop Thema Angular Formulare. Bevor wir starten und du uns noch ein bisschen was dazu erzählst ganz kurz zu dir: Du hast ja auch einige Titel. Du bist Microsoft Services MVP, Google Developer Expert GTI und natürlich auch Softwareentwickler und Speaker bei ganz vielen Konferenzen nationalen und international. So bezogen auf deine Karriere gibt es irgendwas, worauf du besonders stolz bist?
Ich glaube ich finde es einfach cool oder bin stolz darauf, dass ich machen kann, was mir Spaß macht. Ich merke es im Alltag, gerade wenn man manchmal nicht mehr so viel programmiert, beim Kunden ist, viel Consulting macht und sowas. Wenn ich dann wieder zurück zum Programmieren komme. Es macht einfach Spaß. Ich finde es einfach extrem cool und schön, dass ich in einem Bereich arbeiten kann, der mir Spaß macht und ich das meinen Hauptberuf nennen darf. Das ist eigentlich cool und dass diese ganzen Titel dabei rausspringen, ist eigentlich nur weil ich in der Community aktiv bin, weil man eben ja ich glaube auch so ein bisschen Herzblut da rein legt und ist natürlich schön, wenn das rausspringt, dabei. Das ist schon mal cool, dass ich morgens aufstehen kann und ich kann, machen was ihr Spaß macht.
Sehr schön. Dann zu deinem Workshop. Wie gesagt du bist hier für Formulare. Was sind denn so typische Herausforderungen mit Formularen in Angular. Ich habe gehört eigentlich kommt fast jeder Programmierer mal mit Formularen irgendwie in Verbindung und da gibt’s bestimmt auch so ein paar Tücken, die man zu beachten hat.
Ja, es ist so bei Formularen muss man halt immer sehen, dass es das erste Mal ist, dass der User im Prinzip etwas eintippen muss. Das heißt, sie nimmt die Hand von der Maus und muss auf einmal für uns arbeiten auf unserer Webseite und das wollen wir natürlich den Benutzer so angenehm wie möglich machen. Das heißt wir müssen alles unternehmen, um gute Meldungen zu geben. Stichwort Validierung. Wir müssen gucken, dass die Forms richtig angeordnet sind, gut designt sind und so. Also da kommt viel zusammen. Validierung ist immer ein Thema. Ich meine jeder hat schon mal einen Flug gebucht oder irgendwo die Kreditkarte angegeben und das war nicht richtig oder so und man hat es verflucht, weil man die Fehlermeldung nicht richtig gesehen hat. Oder eine Telefonnummer zu validieren. Das ist immer ein Thema, immer eine Herausforderung, dass man das schön anzeigt und dass der User auch was damit anfangen kann. Und auch die Schachtelung von den Forms, die Architektur von den Forms. Also ich muss gucken, wie ordne ich das ganze an. Ich habe einen Namen, vielleicht ein, zwei, drei Adressen dazu, vielleicht gibt’s auch so Dynamic Forms, wo ich Felder hinzufügen kann. Das sind alles Herausforderungen, die ich habe, die ich auch schon bei Kunden in Projekten gesehen habe, wenn es zu Angular Forms kommt.
Ja, es gibt jetzt auch so ein Unterschied zwischen diesen herkömmlichen Formularen und typisierten Forms. Was ist denn so der Vorteil von diesen Typisierten Angular Forms?
Also ich hoffe mal, dass die Typisierten jetzt die Herkömmlichen werden in Zukunft. Also Angular hat eingeführt, dass jetzt Forms Typen haben. Vorher waren sie nicht typisiert. Das hatte den Nachteil, dass immer, wenn wir Daten bekommen haben – und wir haben die im Prinzip an unsere Forms gegeben – waren die nicht Type Safe. Wir wussten nicht genau, wenn die Daten aus der Form rauskommen, was ist das für ein Typ und wir mussten casten. Das heißt wir hatten einen Typ und mussten sagen das, was da rauskommt ist das und das und der und der Typ, könnte ein User sein oder so. Wir hatten aber keinerlei Sicherheit, um zu wissen okay habe ich jetzt eine Nummer in einen String umgewandelt oder eingegeben oder sowas. Das wussten wir nicht und jetzt mit typisierten Plattforms kriegen wir Fehlermeldungen, wenn das passiert. Das heißt, wenn ich jetzt versuche ein Alter von einem Benutzer in einen Namensfeld zu schreiben, wo der Typ nicht passt, dann kriege ich auf einmal eine Fehlermeldung. Das heißt wir sind wesentlich sicherer unterwegs, wenn wir mit Formularen arbeiten und ich kann sogar Typen allein für meinen Formular erstellen und kann dann im Prinzip mappen. Das heißt von meiner Datenbank kriege ich einen User den kann ich Mappen in meinen Form User, kann den dann behandeln und danach wieder zurück mappen und ich bin immer typisiert dabei. Und das ist eigentlich eine sehr coole Sache. Die Fehlermeldungen helfen enorm, wenn man dann einen Fehler macht, sieht man das sofort.
Du hast es schon ein bisschen gerade angerissen. Ist es auch so, dass die Formulare gut testbar sind, oder wie kann man das sicherstellen?
Also ich bin persönlich sehr großer Fan von Reactive Forms. Also es gibt zwei Ansätze. Es gibt die Template Driven und Directive Forms. Beide sind gut testbar. Die einen sagen das ist besser, die anderen sagen das ist besser. Ich persönlich bin eher so der Mensch, der auf Reactive Form steht, eben weil sie in meinen Augen sehr gut testbar sind, sehr einfach testbar sind. Ich kann in meinem Code meine Forms festlegen und habe sehr wenig mit dem Template zu tun. Wahrscheinlich mag ich es auch deswegen, weil ich style-technisch da überhaupt gar nicht so bewandert bin und dann eher froh bin, wenn ich alles in meinen TypeScript-Code habe. Das macht sie sehr gut testbar. Das ist schon mal die eine Sache mit Reactive Forms. Die andere Sache ist die Validierung. Wenn man von Testbarkeit bei Form spricht, muss man auch immer über die Validierung sprechen, weil diese Logik will man ja meistens testen. Das ist ja genau das. Kommt eine Fehlermeldung, wenn ich eine falsche Telefonnummer angebe? Kommt sie, wenn ich eine falsche IBAN-Nummer angebe oder Kreditkartennummer oder sowas? Das heißt, diese Validatoren abkapseln in eigene Klassen, gesondert behandeln als architektonische Elemente von meiner Form und dann kann ich sie auch super testen. Und wenn man das auch noch in kleine Components aufteilt; also ich sage immer, wenn man darüber nachdenkt – soll es eine Component sein oder nicht – und die dann auch noch mal wegkapselt, hat man auch wieder einen kleinen Teil, der meine Form darstellt und ich kann wirklich nur meine Form testen und kann gucken, dass das alles funktioniert. Und möglichst alle Fälle abdecken, die der Benutzer eingeben könnte, damit ich eben schön Error Meldungen anzeigen kann.
Stay tuned
Bei neuen Artikel & Eventupdates informiert werden:
Okay, ja cool. Dann kommen wir auch schon zur letzten Frage: Was wünscht du dir denn für die Weiterentwicklung des Angular Frameworks generell und gibt es etwas, wo du sagst hey Angular Team da müsst ihr noch mal nachbessern oder das könnte einfach besser werden?
In allererster Linie wünsche ich mir im Moment ein bisschen Ruhe bei all der Dynamik, die wir jetzt bekommen haben. Wir haben Standalone Components bekommen vor nicht allzu langer Zeit. Die Community muss das erstmal adaptieren, die müssen erstmal das jetzt einführen und damit arbeiten und das muss erstmal in meinen Augen neuer Standard werden. Das heißt, da könnte man noch mehr in der Dokumentation machen. Angular macht das aber auch gerade. Sie sehen zu, dass das eben alles danach umgestellt wird auf die Standalone Components. Dann haben wir jetzt Signals neu, die Angular angekündigt hat. Signals sind dazu da die Change Detection ein bisschen einfacher zu machen für Angular. Stichwort, wann hat sich was geändert und wann muss was geändert werden. Da wünsche ich mir auch mehr Dokumentation, Talks, Artikel darüber und Blogartikel auch vom Angular-Team, die das noch weiter erklären. Und das sind eben zwei Sachen die Angular gerade in den letzten Monaten gepusht haben. Angular sich da ein bisschen zurückgespielt, wenn man so auf Social Media guckt. So manche Entwickler sagen auf einmal Angular ist ja doch gar nicht so uncool, wie ich dachte. Das finde ich in erster Linie mal schön und wenn sich das jetzt mal so setzen würde, wenn wir jetzt mal so ein bisschen Ruhe da reinkriegen würden. Wir nehmen diese zwei Neuerungen und wir gucken jetzt mal, wie wir damit klarkommen und machen das. Ich finde es wirklich cool was da passiert aber wir müssen das erstmal adaptieren, wir brauchen Knowledge in diesen Bereichen und das muss sich dann auch beim Kunden durchsetzen. Ich meine wir sehen ja wie weit teilweise Kunden sind und die können auch nicht immer gleich aufs Neueste springen. Das dauert schon seine Zeit. Wenn wir in der Schlagzahl weitermachen, wie das in den letzten Wochen oder zwei, drei Monaten der Fall war, dann wäre es echt zu viel. Also ich wünsche mir ein bisschen Ruhe und ich freue mich extrem auf das, was da kommt – Diese Standalone Components und die Signals, wenn die adaptiert werden. Und wenn man in der nächsten Zeit da wie gesagt mehr Doku, mehr Knowledge aufbauen würden, die wir dann auch beim Kunden einsetzen würden und vor allem sehen würden, das wäre cool.
Dann gibt’s ja viele Neuerungen, wofür es sich lohnt auch mal wieder auf ein Trainings Event zu kommen. Das war’s. Danke dir für die Zeit.
