React ToDo-App - Teil 3.

Hallo, lieber Kay. Hallo, liebe Leute da draußen. Ich bin ganz voller Energie für eine neue Folge

von unserem Webcafé. Die Leute da draußen hören, denke ich, schon die zweite Folge, nee, die dritte Folge in diesem Jahr. Die dritte, ja. Genau, die dritte. Und darauf möchte ich auch kurz eingehen. Wir sind nämlich aus organisatorischen Gründen so ein bisschen davon abgewichen, die Folgen in der Reihenfolge zu veröffentlichen, wie sie aufgenommen wurden. Und vielleicht hat der ein oder andere das gemerkt in der ersten Folge zu der React-to-do-App. Da sind wir unter anderem noch auf Weihnachtsthemen im Intro eingegangen. Und das hat eben nicht mehr anders geklappt, die anders zu veröffentlichen. Aber wer da verwirrt war, war das zu Recht. Aber so langsam

pendeln wir uns wieder ein und veröffentlichen wieder in der Reihenfolge, wie wir auch aufgenommen haben. Ja, in jeder guten Beziehung muss man ja so ein bisschen unpredictable sein, um das Feuer am Laufen zu halten. Genau. Und es sind noch mehr verwirrende Sachen passiert. Ich habe ja zum 30.12. letzten Jahres geheiratet und heißt jetzt nicht mehr Felix Gehnen, sondern Felix Dransfeld. Das muss ich jetzt überall im Podcast und so noch ändern. Wollte das aber gerne erst machen, wenn wir eine Folge haben, wo das auch einmal genannt wird. Nicht, dass die Leute zu sehr verwirrt sind und denken, ich wäre ausgeschieden.

Habe ich mir einen anderen Felix geholt, weil ich den Namen so schön finde. Der Name ist wirklich schön, dass man an der Stelle gesagt hat. Ja. Kay, was für einen Tee hast du dir mitgebracht? Ja, Felix, gut, dass du fragst. Ich habe ja vorhin vor unserem Teeregal gestanden und da hat sich inzwischen eine große Sammlung auch von losen Tees versammelt, sage ich mal. Aber als ich so durchschau, habe ich festgestellt, ich habe keine Ahnung mehr, was ich ihm vorgestellt habe. Und dann ist mir ein Tee eingefallen, der noch verschlossen ist. Folgerichtig kann ich den noch nicht präsentiert haben. Und ich glaube, wenn ich das der Packung entnehme,

dann habe ich den aus dem letzten Niederlande-Urlaub. Da steht nämlich drauf, Fruit und Noten, Melange, Rosewolken, Apel, Amandel und Kanäle. Also leckerer Sud. Er ist so schön, also wirklich

schön rot. Ich habe ihn schon aufgesetzt und jetzt nehme ich einen Schluck. Oh Gott, das ist ja fantastisch. Also man merkt schon, wenn da immer Zucker drin ist. Der ist geil, da freue ich mich. Das ist natürlich einerseits gecheatet mit Zucker, aber andererseits schmeckt es auch einfach besser. Ja, ich wünschte, ich hätte eine Kanne. Aber was trinkst du? Ja, ich habe auch was ganz Besonderes dabei. Und zwar habe ich von meinem guten Freund, den Julian, einen Tee bekommen mit dem Hinweis, dass er auch genannt werden vielleicht sogar möchte in der Folge. Und der ist nämlich sehr begeistert von einem bestimmten Teeanbieter, heißt Palais

de Tee. Das ist jetzt keine Werbung, also zumindest bekomme ich da nichts für. Und Julian kenne ich jetzt nicht als ausgewiesenen Tee-Kenner. Von daher war ich sehr skeptisch. Und jetzt habe ich hier den Tee aufgemacht, wo ich gedacht habe, der hat am besten gepasst. Also er hat mir vier Beutel mitgegeben. Der da nämlich heißt New Year's Eve Green Tea, also Neujahrstee. Und weil da eine 31 drauf ist, denke ich, das passt auch ganz gut zum 31. Januar. Ja, und der Tee hat einen richtig coolen Teebeutel. Also ich habe in der Vergangenheit ja wirklich schon auch, glaube ich, mal ein Foto hier in den Podcast mit reingebracht, wo man gesehen

hat, dass ich auch teilweise sehr hochwertige Teebeutel schon hatte. Aber der Teebeutel, den ich hier heute versenkt habe, der toppt nochmal alles. Und der ist wirklich extrem cool gemacht und sehr hochwertig. Mache ich vielleicht dann auch nochmal ein Foto von und stelle das hier auch nochmal rein. Ja, und turns out, der ist wirklich sehr, sehr lecker. Und ich habe ihn genau nach Anleitung gemacht. War auch sehr froh, dass da eine Anleitung drauf stand. Das ist ein grüner Tee, den man bei 80 Grad aufgießt. Das habe ich natürlich genau beachtet. Und vier Minuten ziehen lassen. Und die Beschreibung von dem Tee ist

a gourmet green tea that blends sweet rose and fresh elderberry notes. The number 31 is a delicious way to celebrate. Also ganz wunderbar. Jetzt muss ich dich nochmal eben fragen, weißt du, was elderberries sind? Ich muss es nämlich googeln. Ähm, nee. Ah, Kay. Das sind Holunderbeeren. Oh. Ja, also es ist sweet rose und Holunderbeeren. Ja, ganz fantastischer Tee. Vielen Dank an Julian. Und ich freue mich, dass der mich hier über diese Folge bringt, wo wir den dritten Teil unserer To-Do-React-App vorstellen. Und heute sind so ganz grobe Stichworte Styling und Errorhandling. Aber Kay, ich will nicht zu viel vorweggreifen und gebe dir das Wort.

Genau, es sind sogar noch mehr. Und wir schließen nahtlos da an, wo wir beim letzten Mal aufgehört haben. Wir verlinken hoffentlich auch wieder das Repository in der Beschreibung, weil ich jetzt im Laufe von den Sachen, die ich gleich erwähnen werde, auch immer wieder Beispiele aus dem Code zeige, wie ich bestimmte Konzepte konkret umgesetzt habe. Und du hast es gesagt. Styling und Themes will ich als erstes nennen. Ich weiß, das ist dein Lieblingsthema. Dann ein bisschen über Errorhandling. Ich habe Testing, Linting und am Schluss, damit die ganze Anwendung irgendwo landet, so ein bisschen zum Thema CI, CD.

Ich freue mich drauf. Genau. Styling ist natürlich ein hochgradig subjektives Thema. Und wir beide geraten da ja regelmäßig in den Clinch, weil ich so ein bisschen Function over Form setze und du eher umgekehrt. Das heißt, ich orientiere mich da wirklich ganz streng an den Maßgaben, die ich gleich präsentiere. Und du hast da vielleicht auch so ein bisschen mehr das künstlerische Händchen und schaust dann auch vielleicht mal, was ist denn hier an dieser einen Stelle individuell optisch besonders ansprechend, auch wenn es jetzt vielleicht ein ganz klein bisschen gegen die üblichen Styling-Regeln, die es so gibt, geht.

Ja, du bist so sehr technischer Designer, will heißen, wenn so Material UI was vorgibt, wie man ein Padding macht oder in welchen Schritten, dann würdest du das im Normalfall auch immer befolgen. Und ich mache halt gerne das, was gut aussieht. Genau. Und das ist grundsätzlich jetzt nichts, was sich widerspricht. Deswegen will ich da jetzt heute nicht so die eindeutige Weisheit vermitteln, wo ich sage, Styling muss so gemacht werden und nur so. Sondern im Endeffekt kommt es immer darauf an, dass das gut aussieht, dass das gescheit funktioniert. Und dann muss das auch nicht immer sonderlich kohärent sein.

Wenn man jemanden so hat wie du, der weiß, was er tut. Was ich vielleicht eher machen möchte, ist zu beschreiben, wie man in großen Anwendungen, wo mehrere Entwickler, mehrere Bausteine und komplizierte UIs entstehen, vielleicht ein gewisses System reinbekommt, damit es nicht unabsichtlich chaotisch wird. Und Leute wie du, die dann vielleicht mit dem richtigen Auge da drüber gehen und nochmal das Design anpassen, da mit weniger Kraft große Wirkung entfalten können, weil ansonsten das UI sehr logisch und sauber aufgebaut ist. Da bin ich jetzt mal gespannt, was für eine Flughöhe du wählst, weil ich weiß,

dass wir in unserem Backlog für unseren Podcast eine eigene Folge allein dazu haben. Bin ich mal gespannt, wie weit du das hier ausrollst. Genau, das ist ja immer so ein bisschen das Thema hier bei dieser ganzheitlichen App, dass ich immer wieder Themen anschneide, die eigentlich schon eigene Podcasts gewesen sind oder eigene Podcasts wert sind. Deswegen will ich das immer nur so ein bisschen oberflächlich behandeln und konkret darauf eingehen, wie wir das hier in dem Beispiel machen. Und was grundsätzlich eine gute Idee ist, sage ich es mal so ganz offen formuliert, ist, wenn man beim Entwickeln der Anwendung Styling und Semantik trennt.

Was ich damit meine ist, dass die Entwickler, die so ihre alltäglichen Aufgaben machen, eigentlich wenig mit Styling zu tun haben sollten, sondern stattdessen anhand der richtigen UI-Elemente ausdrücken, was sie wollen und das Styling im Hintergrund, Stichwort Theme, kümmert sich automatisch darum, dass die Sachen gut aussehen. Also zum Beispiel will ich nicht, dass ein Entwickler, der irgendein Formular baut, sich super damit beschäftigt, wie ein Button aussieht, sondern er soll dann aus einem hoffentlich überschaubaren Katalog von Buttons, die es in der Anwendung gibt, den einen wählen, der immer verwendet wird

und den setzt er dann ein. Und bestenfalls ist es ja so, dass die Elemente, die an einer Stelle semantisch Sinn machen, wenn irgendwo ein Button zum Beispiel in einer Form platziert wird, dass der Button an der Stelle von Haus aus auch schon gut aussieht. Ich habe ein Beispiel aus der Praxis aus der letzten Zeit. Da hat irgendein Entwickler, ich selbst, da sah eine Überschrift nicht so richtig gut aus. Und dann habe ich aus einer Überschrift einen Span gemacht. Und das ist mir dann massivst im Code Review um die Ohren geflogen, weil eine andere Entwicklerin richtigerweise dann gesagt hat, Felix, du kannst jetzt hier die Semantik nicht umbiegen, nur damit das vernünftig aussieht.

Fantastisch. Und dann haben wir uns eine bessere Lösung einfallen lassen. Und das ist genau der Punkt, dass man das eigentlich ein bisschen trennen muss zwischen den Leuten, die tatsächlich das UI auf technischer Ebene bauen und überlegen, welche Sachen denn zum Anzeigen wichtig sind und wie da der Workflow und die Bedienung sein muss. Und hoffentlich eine vollkommen andere Person, die beschäftigt sich nachher damit, wie die ganze Anwendung als solches gescheit aussieht, indem man ein allgemeines Color-Theme festlegt, indem man individuelle Komponenten auf so einer globalen Ebene designt. Und da geht es dann nicht darum, an jeder einzelnen Stelle im Code,

wo zum Beispiel so ein Button verwendet wird, zu sagen, hey, der soll jetzt ein Box-Shadow haben oder sowas, sondern es gibt dann eine zentrale Stelle, möglicherweise so ein Theme, wo man sagt, alle Buttons dieser Anwendung haben einen Box-Schatten oder sonst irgendwas, sodass es also streng getrennt ist zwischen Entwickler, nenne ich sie jetzt mal, die eigentlich nur UI-Versatzstücke richtig zusammenpuzzeln und Designern, im Anführungszeichen, die dann ganzheitlich darüber gehen und überlegen, was kann ich denn hier für Entscheidungen treffen, die für alles gleichzeitig gut aussieht. Du sagst jetzt, dass oft erst programmiert wird

und dann wird ein Design drauf gemacht. In der Realität ist es eher andersrum aus meiner Erfahrung, dass man entweder so eine Bibliothek hat wie Material UI, die schon viel vorgibt, oder dass man ein Theme hat und darauf basierend stöpselt man letztlich auch die Elemente zusammen und ergänzt dann vielleicht nochmal das eine oder andere, wenn was fehlt. Ganz genau. Und Material UI ist nämlich das Stichwort, das verwenden wir generell in der Firma und auch jetzt hier konkret im Projekt, ebenso als Zwischeninstanz zwischen den Entwicklern von uns, die wissen, was für Logik implementiert werden soll

und so einer einheitlichen Bibliothek von Basisbausteinen, die immer wieder verwendet werden können. Und Material UI haben wir jetzt gewählt. Weiß ich gar nicht mehr, was da der ursprüngliche Grund war, aber wir arbeiten eben sehr effizient damit, wenn man weiß, wie man damit umgeht. Und die Idee ist wirklich, dass die Leute im UI, also beim Entwickeln der tatsächlichen Komponenten, dann wirklich nur sagen, was sie denn semantisch wollen. Also zum Beispiel, hier will ich ein Layout haben, das sieht so und so aus. Oder hier will ich einen Button haben und der soll nicht pink sein, sondern der soll die Primary Farbe haben,

welche auch immer das sein soll. So kann man dann schön trennen zwischen den wiederverwendeten Bausteinen, die man global stylen kann und den einzelnen Elementen, die der Entwickler braucht, um seinen Workflow abzubilden. Vielleicht der Vollständigkeit halber nochmal, wir haben in der Vergangenheit also sehr viel mit Material UI gearbeitet, aber Bootstrap muss sicherlich dann in der Riege auch genannt werden. Damit kann man natürlich auch einiges machen. Und was ich mal verwendet habe bei einem Projekt, was ziemlich gut funktioniert hat, was aber gar nicht so populär ist, ist Bulma. Das ist auch so ein Open Source CSS Framework.

Das hat für mich in einer kleineren Anwendung gut funktioniert, hat natürlich bei weitem nicht den Umfang von Material UI. Aber das nur mal, um so Ideen zu geben, dass es auch andere, ja, ich weiß gar nicht, ob es dann Frameworks, Bibliotheken, jedenfalls Designoptionen sind, die man nutzen kann. Genau, also bei solchen Frameworks, die nochmal so eine Abstraktion mit so einer Komponenten-Bibliothek anbieten, gibt es ja zuhauf. Es gibt natürlich auch so krasse Gegenbewegungen wie Tailwind CSS zum Beispiel, wo man wirklich auf jedem Element individuell irgendwelche CSS-Klassen puzzelt, die so auf ganz kleinem Scope sagen,

hier Padding, da Padding und sowas. Und das muss man aber dann auch schon richtig anwenden, damit es dann eben da nicht zu diesem Chaos kommt, was ich gesagt habe. Wir können uns ja vielleicht mal anschauen, wie ich es gelöst habe. Und dafür schauen wir uns die Create-Komponente an. Das ist also das UI-Element, was oben diese, ja, diese Create-Bar erzeugt, also so ein kleines Input-Feld, wo man den Text eingeben kann für eine neue Aufgabe. Und daneben so ein Submit-Button. Das ist versteckt unter Source-Modules-To-Do und dann Create, wenn das jemand nachvollziehen möchte. Und es ist natürlich eine relativ

übersichtliche Komponente, aber ich finde, anhand derer kann man gut nachvollziehen, was ich damit meine, nämlich diese Komponente enthält kein einziges Styling, stattdessen nur ein Rearrangement von verschiedenen semantischen Komponenten. Da haben wir also so einen Form-Wrapper, der sich um so einen internen Form kümmert, Form-States. Das hat jetzt nichts mit UI zu tun. Dann so eine Karte-Komponente von Material UI, die eben so ein hervorgehobenes Karten-Element macht mit Hintergrund und so ein bisschen abgehoben. Dann ein Stack, weil ich weiß, okay, ich will hier zwei Elemente gegeneinander ausrichten.

Auch da gebe ich tatsächlich ausnahmsweise ein bisschen Styling an mit dem Padding. Da müssen wir gleich mal drüber sprechen. Aber ansonsten auch hier eher semantisch, okay, die haben ein Spacing zueinander. Eins steht hier und das bedeutet einmal das Default-Spacing aus dem Theme und wenn irgendjemand sagt, das Default-Spacing soll 10 Pixel statt 8 sein, wie es bei Material UI ist, dann wird das überall automatisch angepasst. Und sowohl die Fields als auch die Icon-Button-Komponente haben auch kein eigenes Styling. Bei dem Icon-Button sage ich nur, die Color soll Primary sein. Auch da keine expliziten Werte,

sondern nur, was auch immer die Primary Color im UI ist. Vielleicht kann man hier zu dem Icon-Button noch sagen, da ist jetzt ein Title drauf, wo ein deutscher Text draufsteht, neue Aufgabe anlegen. Wir würden normalerweise in Projekten, die einigermaßen groß sind, da auch eine Internationalisierung, also eine Mehrsprachigkeit mit reinbringen. Genau. Das geht so ein bisschen rein, warum hier überhaupt ein Title. Wir haben ja schon ein Pluszeichen, aber da reden wir nachher noch mal ganz kurz beim Thema Accessibility und Testing drüber. Ich habe gesagt, ich komme auf dieses Padding noch mal zurück,

weil das ja wahrscheinlich das Erste ist, was tatsächlich hier individuelles Styling hat. Und da hast du mir noch eine Chat-Nachricht geschrieben, Felix, als es darum ging, das zu releasen, dass ich doch mal da von dieser Karte irgendwie das mit dich ausrichten soll, wenn du dich erinnerst. Ja, auf jeden Fall. Mein Problem an der Stelle war, ich hatte das genauso gebaut, wie ich das gesagt habe, nämlich habe kein individuelles Styling verwendet und nur Material-UI-Komponenten so verwendet, wie Material-UI das gerne hätte, nämlich konkret mit dieser Card und da drin einen Card-Content und da drin wiederum

dann nur dieses Layout zwischen den beiden Elementen. Und dieses Card-Content hat aus irgendeinem Grund, der bestimmt total sinnvoll ist, oben einen anderen Padding gehabt als unten. Also das war quasi von Haus aus genauso, wie die sich das designt haben. Haben die denn wirklich ein anderes Padding gehabt oder hat das irgendwie was mit Textlaufweiten und sowas zu tun? Nee, das hatte absichtlich ein anderes Padding und ich nehme an, das hat damit zu tun, dass die mit dieser Karte beabsichtigen, dass man unten immer noch so eine Card-Action drunter hat und in der mit der Kombination mit den Icon-Buttons,

die da vorgesehen sind, führt dann dazu, dass man eigentlich ein unsauberes Padding haben muss, das aber dann in der Gesamtansicht der Module zueinander wieder vernünftig ist, weil dann die Abstände passen. Ah, schade. Ich dachte, ich hätte jetzt eine meiner großen Weisheiten hier loswerden können. Nee, leider nicht. Und deswegen war ich nämlich vor dem Zwiespalt. Verwende ich jetzt die Sachen halb so, wie sie konzeptioniert sind, nämlich mit diesem Card-Content, den wir ehrlicherweise so missbrauchen, dass wir die Buttons nicht da drunter haben, sondern daneben? Oder gehe ich hier diese individuelle Lösung,

um Felix den Designer zufriedenzustellen und breche bewusst die Regeln, die ich gerade aufgestellt habe, und mache hier individuelles Styling, weil es an dieser Situation besser aussieht. Und ich finde, das ist ganz genau auch der Vorgang, wie es sein soll, dass man erst mal als Entwickler versucht, sich so streng wie möglich an den Vorgaben des Projekts oder der Design-Bibliothek die Design-Bibliothek zu halten und dann an den ausgewählten Stellen, wo man wirklich drüber diskutiert und darüber spricht, bewusst andere Entscheidungen zu treffen, um dann insgesamt ein stimmiges Design zu erzeugen.

Bei diesem Layout ist es auch sehr wichtig, meiner Meinung nach, dass Layouts, also das Arrangieren von mehreren Elementen zueinander, immer von außen nach innen passiert. Das bedeutet, wir haben hier als Beispiel die Field-Komponente und die Icon-Button-Komponente, wenn ich die einfach nur so reinsetzen würde. Das Field ist volle Breite, geht also 100% des Platzes und der Button in die nächste Reihe rutschen. Und ich will es jetzt aber im UI so ausrechnen, dass der linke Platz von dem Input eingenommen wird auf der rechten Seite des Buttons. Und so wie ich das löse, ist das mit einem Layout, das ich als Eltern-Element

über die beiden setze. Die beiden haben keine Ahnung voneinander, das Field und der Icon-Button. Das heißt, ich mache das nicht so, dass ich dem Button einen Margin nach links gebe oder sowas, um da so einen Abstand zu erzeugen, sondern die Kinder wissen nichts voneinander und von außen, hier in dem Fall mit dieser Stack-Komponente, sage ich, wie sich die Kinder zueinander ausrichten sollen. Und das hat eben große Vorteile, wenn man dann kompliziertere UIs hat, dass die Kinder wirklich gekapselte Module sind, die man nach Belieben auch wieder vertauschen und neu arrangieren und wiederverwenden kann,

ohne dass die irgendein eingebautes Spacing in irgendeine Richtung haben, was dann das UI zerschießt. Das setzt natürlich voraus, dass die Komponenten eben auch flexibel gebaut sind und die richtig großen Vorteile kommen dann eben zum Beispiel, wenn es um Responsive geht, dann ins Spiel. Also wenn ich jetzt den Bildschirm größer, kleiner ziehe zum Beispiel, dass dann der Platz auch optimal genutzt wird und vielleicht dieser Stack, den du hier aufgemacht hast, dann anders aufgelöst wird. Ganz genau so ist es. Deswegen ist es auch nochmal wichtig, dass die Elemente auch visuell nur den Platz wegnehmen,

den sie tatsächlich im Code wegnehmen. Das ist ein bisschen schwer formuliert, aber was ich damit meine, ist eben, dass wenn der Button ja eine Hintergrundfarbe hat, dass das Element im DOM auch wirklich nur so groß ist wie diese Hintergrundfarbe zum Beispiel oder wie die Abmaße von einem Text und dann nicht noch zusätzlicher Padding oder Margin oder sonstiger Space drin ist, der das Element auf DOM-Ebene größer macht als im UI ersichtlich. Bei Text ist es zum Beispiel häufig, wenn man da die Default-Einstellung netzt, dass der Text ja visuell eine bestimmte Größe hat, nämlich genauso hoch und breit

wie die Buchstaben sind, aber durch Leinheit oder sonst irgendwas da noch zusätzlicher Platz reinkommt, der total Sinn macht bei Fließtexten, aber in allen anderen Fällen dafür sorgt, dass da noch ein ganz klein bisschen mehr Platz ist, als eigentlich sein sollte und dadurch ersteht dann insgesamt unrundes Layout. Kay, jetzt kann ich meine Weisheit doch noch loswerden. Ich habe nämlich gestern gelesen, dass es eine neue CSS-Eigenschaft gibt, die heißt TextBoxTrim, also Text-Box-Trim und die sind nämlich genau dafür da, diese blöde Zeilenhöhe, wo man das Problem hat, wenn man Text mittig ausrichten will

in einem Button in einer Box, dass der nie mittig ist und deswegen muss man dann immer einerseits links, rechts und oben, unten ein unterschiedliches Padding oder einen unterschiedlichen Abstand angeben und manchmal aber sogar oben und unten und das ist ja immer eine Katastrophe oder man muss die Line halt nochmal extra festlegen und so weiter und mit diesem TextBoxTrim kann man jetzt sagen, einerseits wie oben gecroppt wird, wie unten gecroppt wird, wie insgesamt gecroppt wird, jedenfalls gibt es da Optionen, wo man wirklich sagen kann, ich habe die Eigenschaft jetzt nicht 100% mehr im Kopf, aber du kannst jedenfalls sagen,

mach die Box von diesem Text genauso groß, wie der Text tatsächlich ist und ne, nimm auch diese großen Buchstaben mit und so weiter und so fort und dann braucht man die ganzen Späße nicht mehr machen. Bin mir nicht sicher, wie das jetzt schon im Browser unsupportet ist, aber in ein paar Jahren haben wir das Problem gelöst. Das ist ja fantastisch. Ja, ja. Wie gerufen. Genau, so viel zum Thema Styling, Layouting insgesamt. Ich habe dich nicht großartig aufstöhnen hören. Genau, das war jetzt ja wirklich ein kurzer Anriss, aber Material UI, das muss man ja sagen, nimmt einem hier das Allermeiste erstmal ab

und sieht insgesamt stimmig aus. Für so eine Beispielanwendung glaube ich genau das Richtige. Und ehrlicherweise, das merke ich auch immer im Gespräch mit Kunden, man selber als Entwickler und Designer hat natürlich für jeden Pixel, der da falsch ist, ein Auge drauf, aber in der Realität, die Leute, die es verwenden, die merken das in den seltensten Fallen. Also wir häufig schon irgendwie Feedback bekommen haben, so, ach ja, ist mir gar nicht aufgefallen oder sonst irgendwas. Heißt natürlich nicht, dass man da schlampig sein sollte, aber Styling ist da, sagen wir mal, ein bisschen mehr forgiving

als unser nächstes Thema, das Errorhandling. Ja, wenn ich da nochmal zurück einhaken darf. Na, ist so eine schöne Überleitung und du machst es kaputt. Ja, die muss ich kaputt machen, weil ich da nicht mitgehen kann. Bitte. Also, natürlich gibt es einen Haufen Leute da draußen, denen so kleinere Sachen nicht auffallen oder denen das nicht auffällt, wenn da bestimmte Sachen nicht stimmig sind. Ich glaube, es gibt aber genauso viele Leute, die auch ein schönes Design in der Anwendung wertschätzen und ich kann jetzt von mir selbst, von meiner Frau und auch von anderen Leuten sagen, wir wählen auch Anwendungen,

die wir im täglichen Gebrauch nutzen, danach aus, ob die vernünftig aussehen, weil eines meiner Sprichwörter ist immer, wenn eine Anwendung gut aussieht, dann ist sie meistens auch nicht schlecht programmiert. Ist steile These, aber die werfe ich mal so in den Raum und ich weiß, dass sich zum Beispiel jetzt Leute für eine Warenwirtschaft entschieden haben, einfach weil die auch eine moderne Optik hatte und nicht mehr diese 90er Jahre und Desktop-Anwendung, und so weiter. Jetzt reden wir da natürlich nicht über einen Pixel, der verschoben ist, sondern über größere Sachen. Aber insgesamt, glaube ich,

macht das Design mehr, als wir denken und das ist genau das, worauf ich hinaus will. Es gibt sicherlich Leute, die auf eine Anwendung drauf gucken und denken, ja, ist doch alles in Ordnung. Aber ich glaube, jeder Mensch hat im Unterbewusstsein ein Gefühl dafür, ob eine Anwendung stimmig aussieht. Und nicht jeder kann das erklären, was stimmig ist und was nicht. Aber ich glaube, wenn eine Anwendung schon gut und konsequent designt ist, dann kriegen das die allermeisten Leute im Hinterkopf irgendwie doch mit und haben ein besseres Gefühl bei der Anwendung. Also von daher, ich messe dem etwas mehr Wichtigkeit bei,

als du das dann vielleicht tun würdest. Deswegen bist du der Designer von uns. Und es stimmt auch, dass wenn man so eine große Anwendung entwickelt mit vielen Bausteinen, wo unterschiedliche Leute dran arbeiten, dass es da ganz automatisch zu so einer gewissen Inkonsistenz kommt. Und da ist es auf jeden Fall wichtig, in regelmäßigen Intervallen sich nochmal ganzheitlich vor die ganze Anwendung zu setzen und wirklich die verschiedenen Bausteine gegeneinander auszurichten und zu überlegen, okay, hier machen wir jetzt da noch ein bisschen mehr Padding, weil es passt dann auf der ganz linken Seite

zum Bildschirm besser oder sonst irgendwas. Also das ist schon auf jeden Fall ein wichtiger Brocken, für den man sich aber auch Zeit nehmen muss. So ist es. Und jetzt darfst du nochmal überleiten. Error Handling. Wir haben dazu schon eine Folge gemacht, Folge 6. Deswegen möchte ich so diese Grundlagen von dem Error Handling wirklich nur nochmal kurz zusammenreißen und dann aber vielleicht viel mehr auf die konkreten Ausprägungen in der Anwendung gehen. Meine grundsätzliche Maßgabe ist, je wahrscheinlicher ein Fehler auftritt, desto elaborierter sollte auch dessen Handling sein. Und Handling, meine ich,

besteht aus drei Teilen, nämlich zum einen, wie oder was oder wo sagt die Anwendung überhaupt, dass es ein Problem gibt und wie gehen wir damit um. Und das hat wiederum zwei Aspekte. Nämlich, wie gehen wir als Entwickler damit um und wie gehen wir gegenüber dem Anwender damit um. Wichtig ist grundsätzlich meiner Meinung nach, dass Module und Units, ich halte das jetzt absolut ein bisschen abstrakt, für sich entscheiden können, wenn ein Zustand erreicht ist, in dem sie selber nicht mehr sinnvoll funktionieren können und das auch hart ansagen über einen knallharten Error, der den ganzen Code abbricht.

Das ist meiner Meinung nach der einzig sinnvolle Weg, da so eine gewisse Verlässlichkeit reinzubringen, auch ausdrucksstarke Fehlermeldungen zu erzeugen, die wir als Entwickler dann idealerweise irgendwo gelockt bekommen und dann konkret mit Texteck und elaborierten Fehlermeldungen und so weiter sehen können, was da schiefgelaufen ist. Gleichzeitig ist es natürlich für den Anwender, der da gerade irgendwas macht, total blöd, wenn er bei so einer Frontend-Anwendung auf einen Button klickt. Es gibt irgendwo einen ganz, ganz Mini-Fehler, der im Gesamtkontext der Anwendung nicht mehr dramatisch ist,

aber weil es eben ein harter Error ist, stößt die ganze Anwendung ab. Und deswegen muss man zu jedem Fehler, der so entstehen kann, von dem man es schon weiß und von jedem Fehler, den man antizipieren kann und auch alle Fehler, die man nicht antizipieren kann, die einfangen, bevor sie größeren Schaden einrichten. Und damit meine ich dann innerhalb der Anwendung so kleine Zäune spannen, innerhalb derer Fehler aufgegriffen und dann individuell an der Stelle irgendwie ein alternatives UI kommt oder eine Benachrichtigung an den Anwender. Je wahrscheinlicher der Fehler ist und je komplizierter das Modul ist,

desto elaborierter muss auch die Fehlermeldung sein. Und wir hatten zum Beispiel letztens den Fall, dass ich gefragt wurde, weil in einer Anwendung durch eine sehr, wie soll ich sagen, mutwillige Kombination von Eingaben und Aufforderungen, die man wirklich bewusst maßschneidern musste, einen Fehler erzeugen konnte, der wirklich die ganze Anwendung abschießt. Allerdings nicht ungeplant, sondern da kam dann einfach nur so ein großer Screen mit, hey, hier ist ein Fehler aufgelaufen, was sollen wir damit machen? Bitte laden Sie die Seite neu, liebe Anwender. Und die Argumentation war, wenn man so einen elaborierten

Prozess machen muss, um überhaupt den Fehler zu erzeugen, dann finde ich es auch total okay, wenn die Anwendung da wirklich nur das Allernötigste macht und sagt, yo, ich weiß, es gibt einen Fehler, hier kannst du Seite neu laden und dann ist es idealerweise wieder hergestellt. Und je tiefgreifender die Fehler dann sind oder je wichtiger die Module sind, muss man da eben dann sehr bewusst für die jeweilige Stelle sich ein Error Handling überlegen. Wir gehen mal vielleicht in ein konkretes Beispiel rein. Das finden wir in der Actions-Datei unter To-Dos, also Source, Modules, To-Dos, Actions. Und dort wiederum

haben wir die Funktion Remove. Und was wir dort sehen, ist, dass wir eine ID für eine To-Do als Parameter bekommen und was wir dann machen wollen, ist aus dem Store, nenne ich es mal, wo wir alle Aufgaben gespeichert haben, eine bestimmte mit einer ID zu löschen. Kann man auf den Button klicken und die To-Do wird dann ausgeblendet. Und jetzt kann es hier das Szenario geben, alleine erstmal auf Typenebene, dass die To-Dos value null sind. Und was ich dann gemacht habe, ist hier als allererstes, bevor es losgeht, ein Check eingeführt, der sagt, hör mal, ist denn die Liste aller To-Dos, die ich habe null

und damit in so einem Loading State. Und wenn dem so ist, dann mache ich hier einen harten ThrowError To-Do sei empty. Man könnte jetzt argumentieren, okay, wenn dieser Fall eintritt, dann habe ich hier einfach einen Error geworfen und dann kaskadiert das durch die ganze Anwendung durch, wenn da nicht noch von außen irgendwelche Sicherheitsmaßnahmen getroffen wurden und legt die ganze App lahm. Wahrscheinlich nicht so geil für den Nutzer, aber gleichzeitig, wenn man sich überlegt, okay, wie kann ich denn diese Remove-Funktion aufrufen, wenn überhaupt noch gar keine Tasks geladen wurden und die einzige

Implementierung dieser Funktion in der Anwendung eben auf so einem UI-Button hängt, könnte man sagen, okay, wie hoch ist die Wahrscheinlichkeit, dass ich auf den Button klicke, der zu einer To-Do gehört und eine To-Do entfernen möchte, die es gar nicht gibt. Und in diesem Fall habe ich dann entschieden, ja, da muss man sich schon einigermaßen für anstrengen. Das heißt, es ist also nicht ein Fall, der super häufig vorkommt und weswegen ich hier schon ein super elaboriertes Error-Handling mache. Könnt ihr auch einfach ein stilles Return Null machen oder sowas. Dann würde das UI nicht abstürzen. Aber gleichzeitig eben,

weil das so ein elaboriertes Szenario ist, möchte ich als Entwickler trotzdem wissen, falls das irgendwann mal vorkommt. Und deswegen habe ich hier dann eben dieses strenge Error-Thrown gemacht und wirklich einen Error geworfen. Der ist jetzt hier wirklich nur sehr basic, aber da könnte man sich vorstellen, noch mehr Informationen anzuhängen, sodass ich dann später in unserem Error-Logging als Entwickler genau sehen kann, oh, guck mal, es ist doch irgendwie aufgetreten und vielleicht sogar Informationen bekomme, Stacktraces oder weiß ich nicht was, die mir helfen zu verstehen, wie es dazu kommen konnte.

Das ist, glaube ich, hier das Allerwichtigste, dass man was mitbekommt, was man sich vorher vielleicht nicht vorstellen kann, weil, dass du hier die To-Dos abfragst, ob die null sind, ja, da könnte man eben, wie du das beschrieben hast, auf die Idee kommen, das macht eigentlich überhaupt keinen Sinn und du könntest die ganzen Zeilen 77 bis 80 sind sie hier rauslöschen, also du müsstest ja nicht mal was returnen, der erwartet ja einen Void, das heißt, du könntest ja einfach den Filter unten anwenden, auch der hätte kein Problem damit, wenn da, glaube ich, die To-Dos leer wären. Ich mache ein kleines

Fragezeichen dahinter, aber ich denke, es wird funktionieren und dann würde man es eben nie mitbekommen. Jetzt kann es aber sein, aus irgendwelchen Gründen und in der Praxis kommt es eben häufiger vor, als man denkt, dass doch dieser Fehler geworfen wird und dann ist natürlich schön, eigentlich wiederhole ich nur, was du gesagt hast, wenn es dann in unserem Error-Logging auftaucht und dann kann man sich nämlich nochmal neu kalibrieren und merkt dann so, oh, habe ich vielleicht doch an eine Situation nicht gedacht und kann dann drauf eingehen. Muss ich übrigens korrigieren, weil das wird dann nämlich

doch um die Ohren fliegen, das To-Do.Value kann nämlich ein To-Do-Array sein oder Null und du kannst nicht Null.Filter machen, das heißt, alleine TypeScript wird schon hier aufs Dach steigen, aber es gibt jetzt nicht andere Möglichkeiten, wie man damit umgeht, indem man einfach sagt, okay, machst du so ein Fragezeichen dahin mit so einem Null-Check oder du machst vielleicht keinen Error, sondern sagst einfach nur Return im Early Escape, aber das sind eben alle Szenarien und ich merke das bei vielen neuen Entwicklern, die sagen, okay, ich will um Gottes Willen nicht, dass meine Anwendung kaputt geht,

haben wir, glaube ich, in der Podcast-Folge Nummer 6 auch sehr lange drüber gesprochen, aber eben diese Ausdrucksstärke von einem Error sollte an der Stelle nicht unterschlagen werden. Ein bisschen anders sieht es aus in der Funktion ein bisschen weiter oben, da haben wir die Get-Funktion, die macht so ein bisschen fancy Sachen, aber was sie unter anderem macht, wenn ich das mal kurz skizziere, ist, dass sie Dateien aus dem Local Storage lädt und die dann einmal validiert, Validierung haben wir schon letztes Mal drüber gesprochen und sie dann in den internen State der Anwendung packt, also aus dem Local Storage

des Browsers, validieren gegen ein bestimmtes Schema und dann in den lokalen State. Und hier, im Gegensatz zu der anderen, zu dem anderen Beispiel gerade, habe ich mich sehr bewusst dazu entschieden, ein lokales Error-Handling zu machen, weil nämlich genau dieses Validate eine Funktion ist, von der ich schon im Code idealerweise sehen kann, dass sie einen Fehler erzeugt und der auch gar nicht so unwahrscheinlich ist, weil da kann ja jeder im Local Storage irgendwie die Werte manipulieren oder es gibt verschiedene Versionen der Anwendung, wo in diesem Local Storage mal andere Werte gespeichert wurden

oder sonst irgendwas. Also im Vergleich zu dem vorherigen Fehlerfall, wo das Szenario sehr unwahrscheinlich ist, dass es auftritt, ist es hier im Gegenteil sehr wahrscheinlich, dass es auftritt oder sehr wahrscheinlich her. Und deswegen gehe ich hier genau die andere Route und sage nicht einfach, ich werfe einen Error und die Anwendung muss sehen, wie sie damit umgeht, sondern ich überlege mir für diesen konkreten Fall ein ganz spezifisches Error-Handling. Und das bedeutet, in dem Fall habe ich dieses Validate und so weiter in einen Try-Block gepackt und im Catch-Block mache ich dann genau drei Dinge,

nämlich zum einen ich logge den Error, der da entsteht, an eine zentrale Stelle, gehe ich gleich nochmal drauf ein und mache zusätzlich aber auch Feedback für den Nutzer, nämlich indem ich dem eine kleine Snackbox anzeige, hier Laden fehlgeschlagen oder weiß ich nicht was und zusätzlich noch, dass die interne Liste der To-Dos auf einen leeren State setze, damit trotz des Fehlerfalls die Anwendung weiter laufen kann. Das wäre also so ein Beispiel von bewusst den Fehler an der Stelle gehandelt und individuell darauf abgestimmt, was dann passieren soll. Dieses Log-Error, was ich da anwende, das ist eben

das Error-Handling für uns, nicht das für den Nutzer, dafür haben wir dieses Enqueue-Snackbar, heißt es hier und das ist einfach eine Helferfunktion, die ich an jeder Stelle einsetze, wo Errors entstehen, mache ich einfach Log-Error und übergib als Parameter den Error, um den es da gerade geht und dann habe ich nämlich eine zentrale Stelle, wo ich als Entwickler entscheiden kann, wie ich damit umgehe. Schreibe ich einfach in die Konsole oder in irgendeine Log-Datei oder haben wir glaube ich auch in der Folge darüber gesprochen, loggen wir das zu einem expliziten Dienstleister oder irgendwo extern hin,

wo wir dann darüber benachrichtigt werden, den Stacktrace einsehen und solche Sachen. Also total essentiell auch hier den Fehler für uns bewusst irgendwo hin zu schreiben und dafür explizit diese Funktion zu schaffen. Die Funktion nicht dann unter utils und logerror.ts Da sammeln sich jetzt erstmal die Errors. Genau. Das war jetzt der klassische JavaScript-Weg mit Throw-Error und diesem Try-Catch-Block. Dann gibt es natürlich auch noch das Ganze auf der React-Ebene und hier gibt es eben alternativ zu diesem Try-Catch gibt es das Konzept der Error-Boundary. Das ist so ein React-Konzept. Das habe ich hier

abgebildet durch eine zusätzliche Komponente. Das kann man zum Beispiel in der App TSX finden im Source-Root-Verzeichnis. Da habe ich eine Error-Boundary um das eigentliche Create gemacht um damit zu zeigen ich kann nicht alle Fehler-Szenarien antizipieren deswegen muss ich davon ausgehen dass in dieser Create-Komponente irgendein Fehler passiert weiß ich nicht was Type-Error oder sonst irgendwas man kann ja nicht im Vorfeld alle Fehler vorhersehen und dann mache ich aber trotzdem um so Module eine Error-Boundary wo ich sage okay hier dieses Create-Modul und alles was da drunter hängt alle Sub-Komponenten

die spanne ich so ein wie in einem Try-Block und wenn da drin ein Fehler passiert dann habe ich jetzt hier in dem Fall so ein Fallback-UI wo ich einfach nur eine Fehlermeldung anzeige aber um eben so ein bisschen zu zeigen auch auf React-Ebene kann man so Zäune spannen innerhalb der Anwendung und Bereiche feststecken in denen wenn man da so Sicherheiten haben möchte ein anderes Beispiel ist in der To-Dos-Liste das finden wir unter Modules To-Dos da gibt es die To-Do-View die letzten Endes eine Liste aller Aufgaben anzeigt und dafür die jeweilige To-Do-View-Komponente rendert und auch hier habe ich um

jede einzelne To-Do-View eine Error-Boundary gesetzt um eben zu sagen ich betrachte jede einzelne To-Do als so einen kleinen Zaun wo ich sage okay wenn hier drin ein Fehler stattfindet dann will ich nicht dass das durchkaskadiert bis weiß ich nicht wo sondern ich fange den ganz eng ein und sage hier habe ich jetzt zum Beispiel sogar eine alternative Error-Komponente geschrieben die dann angezeigt wird wenn da ein Fehler entstanden ist und so kann man eben enge Zäune spannen und sich das individuell überlegen was man da macht oder eben auch nicht so wie im Fall allerersten Beispiel die Error-Boundary

ist aber nicht in der To-Do-View sondern in der To-Do-S.tsx glaube ich genau die ist als Rapper um die To-Do-View drumherum im Grundsätzlichen war es das zum Thema Error-Handling ich lasse dir jetzt ein bisschen Zeit für Fragen oder sonstiges ja Kay du hast das Error-Handling so vollständig abgehandelt hier ich habe versucht zwischendurch mir Fragen zu überlegen und habe das auch getan aber du bist auf alles eingegangen also von daher kann ich hier keine Weisheiten mehr einstreuen jetzt noch ein Schluck stärkenden Tee und dann leiten wir über zum Thema Testing die werden jetzt sukzessive weniger umfangreich

die Sachen wir haben jetzt also noch ein paar Sachen zum Thema Testing auch da Podcast Nummer 5 schon groß drüber gesprochen Linting gehe ich noch kurz drauf ein auch ein eigener Podcast schon gewesen bin ich mir gar nicht sicher aber wir haben es auf jeden Fall schon erwähnt an CICD deswegen würde ich sagen wir ziehen es jetzt einfach durch oder? dann machen wir nicht noch einen zweiten Podcast ja wie du meinst auf meiner Uhr stehen jetzt ein bisschen was über 35 Minuten leg mal los genau Testing wie gesagt Podcast Nummer 5 deswegen spare ich mir jetzt da den ganz großen Bogen zu spannen und zu sagen

warum Testing hilfreich ist welche Varianten es gibt worauf man achten sollte und so weiter und so fort da haben wir hoffentlich einen sehr erschöpfenden Podcast drüber gemacht aber Testing ist ja auch neben der eigentlichen Code-Entwicklung so das Thema Nummer 1 da gibt es unfassbar viele Tools unfassbar viele Anleitungen im Internet wenn man da neu ist da hat jede Firma so seine eigenen Best Practices und Chains was sie machen und so weiter und so fort deswegen gehe ich jetzt hier wirklich nur darauf ein was ich jetzt in dieser konkreten Anwendung beispielhaft gemacht habe ich habe nicht die ganze

Anwendung durchgetestet sondern nur so anhand von 2-3 Beispielen gezeigt wie ich zum einen Unit-Tests geschrieben habe damit meine ich jetzt hier konkret einzelne isolierte Funktionen die Sachen machen hauptsächlich aus dieser Actions-Datei und ich habe es jetzt mal Feature-Tests genannt nämlich React-Komponenten getestet die schon ein bisschen mehr Richtung Rendering und sowas gehen worin möchten wir anfangen Felix du darfst dir aussuchen damit das ein bisschen interaktiv ist also ich würde auf jeden Fall mal bei einem Unit-Test einsteigen also schön weit unten fantastisch dann schauen wir uns

die Datei Actions.test.ts an die liegt da auch im To-Dos-Modules-Ordner und da sieht man zum Beispiel dass ich hier zwei Tests gemacht habe die ich mit so einem Describe-Block nur dieser Unit create zugeordnet habe und das Schöne und das Schöne daran ist dass ich auch die Actions die dahinter liegen die ja in unserer Metapher so ein bisschen Controlling und Modeling sind habe ich so weit isoliert dass das wirklich reines JavaScript ist und das heißt den ganzen UI-spezifischen Kram kann ich hier außen vor lassen und sehr klassische Unit-Tests schreiben wo ich dem AAA-Konzept folge zuerst eine Welt

setze dann eine Funktion ausführe und dann das Ergebnis beurteile und hier ist so der erste Test mal als Beispiel dass ich als erstes eine Systemzeit setze das ist wichtig weil es unten bei dem Erstellen der To-Do ja darauf ankommt dass der jetzige Zeitpunkt da als Create gesetzt wird und dafür ist es sehr wichtig dass ich auch diesen Parameter kontrollieren kann als Testumgebung und mich nicht darauf verlassen muss dass ich da irgendwie dynamisch das richtige Datum auslese oder sonst irgendwas sondern für diesen Test hier ist das mit Y Set System Time pin ich für diesen Test die Uhrzeit genau auf diesen Wert

und egal wie viel Zeit innerhalb des Tests vergeht bleibt immer auf die Millisekunde dasselbe dann rufe ich die Create-Funktion auf die erfordert nur ein Label und anschließend prüfe ich ob in dieser globalen To-Dos-Liste die ich da habe ein neuer To-Dos-Eintrag ist und der die Werte hat die ich erwarte du hast jetzt AAA angesprochen das steht ja für für Range Act und Assert das ist so genau das was wir hier mal machen was vielleicht noch so ein bisschen auffällig ist ich glaube oder ich hoffe ansonsten sind die Tests relativ selbstsprechend da habe ich jetzt nicht so super fancy Sachen gemacht

aber was ich empfehlen würde ist für die tatsächlichen Assertions zu schauen welche Arten von Tests denn mein Testing Framework der Wahl in diesem Fall ist es White Test anbietet die allermeisten Testing Frameworks haben irgendeine Art von so Assert to be wo man Wert A mit Wert B vergleicht das ist immer die Holzhammer-Lösung aber die allermeisten geben auch viel viel individuelle Assertions mit hier sieht man es zum Beispiel Zeile 14 da sage ich nicht einfach to be null bei dem Completed Add was initial leer sein soll sondern es gibt eine extra to be null Funktion und das macht nicht nur den Test

ein bisschen sprechender sondern häufig ist es auch so dass hinter diesen Assertion Funktionen die da angeboten werden unterschiedliche Outputs hinterstecken wenn die fehlschlagen und zum Beispiel bei der Testing Library für UI die wir gleich haben da wird dann in der Log schon der DOM ausgegeben der gerade da ist um zu zeigen warum Elemente nicht da sind oder andere Sachen die dann individuell für diese Art des Tests relevant sind dann gehen wir über zum Feature-Test das ist glaube ich ein bisschen spannender an der Stelle ich habe dafür einen oder mehrere Tests für die To-Do-View geschrieben

auch die liegt neben der eigentlichen UI-Komponente vom To-Do also Modules To-Do To-Do-View und dann die To-Do-View Punkt Test und hier habe ich auch mit diesem Describe-Block versucht verschiedene Bereiche zusammenzufassen und was man hier schon sieht wenn man sich das ein bisschen anschaut ist dass die Tests ein bisschen komplizierter sind weil sie eben wirklich eine React-Komponente rendern müssen und man dann mit dem DOM interagieren muss und ist ein bisschen kontrovers aber meiner Meinung nach ist das der richtige Zeitpunkt um über Accessibility zu sprechen weil ich jetzt auf irgendeiner semantischen

Art und Weise mit dem UI sprechen muss und verschiedene Bibliotheken haben da verschiedene Ansätze wie man es macht und tatsächlich diese React-Testing Library die spricht aktiv gegen das was ich hier mache das finde ich eine ganz spannende Geschichte sondern was die sagen ist man soll das ruhig in der Anwendung machen indem man so künstliche Attribute auf den Elementen verteilt und dann sagt sowas wie Test-ID gleich Header Test-ID gleich Title und darauf dann die Selektoren aufbauen um irgendwelche Bereiche im UI anzusprechen weil deren Argument ist die kann man auf alle Elemente drauf setzen

und die funktionieren immer gleich mein Argument ist aber dass ich an der Stelle mit meinem UI interagieren möchte wie ich es auch als Mensch tue als Mensch gehen wir privilegierte Menschen mit Augenlicht den strikt optischen Weg das heißt wenn wir eine Fläche zum Anklicken suchen dann haben wir gelernt wie so ein Button üblicherweise aussieht und können anhand der Beschreibung der da drauf steht in Zusammenhang feststellen und klicken dann mit der Maus an die Stelle wo wir diesen Button vermuten und wenn man es aber runter bricht dann können so automatisierte Systeme das nicht und da rede ich

zum Beispiel über Screenreader für sehbeeinträchtigte Menschen oder auch sowas wie irgendwelche Crawler die sehen die Seite ja nicht zwangsläufig mit Augen wie wir und können optische Zusammenhänge herstellen sondern was die machen ist die untersuchen die Seite anhand semantischer Merkmale also Elemente mit denen sie interagieren und wie die bezeichnet sind und hier in dem Beispiel von diesem To-Do View möchte ich jetzt also herausfinden im ersten Test ob generell so ein To-Do angezeigt wird wenn ich ihn rendere und da nicht irgendein Fehler aufpassiert ist oder sowas und da habe ich überlegt was identifiziert

denn so eine To-Do und in unserem Fall wenn man es runter bricht ist ja eine To-Do eigentlich als Hauptkriterium der Text der dazugehört da gibt es noch ein paar andere Sachen drumherum die in der Entity stecken aber der Text ist so der Dreh- und Angelpunkt und deswegen benutze ich auch den Text der To-Do als Identifikation für das UI-Element das ich damit in Verbindung bringen möchte das können wir uns vielleicht in der To-Do View selber mal anschauen da habe ich nämlich um das ganze Element drumherum ein Area Label bei ID gesetzt und das stellt eine Verbindung her über die ID zu dem visuellen

Text das ist weiter unten in dem List Item Text ist die ID gesetzt das stellt die semantische Verbindung zwischen diesen beiden Blöcken her und das bedeutet auf Accessibility Ebene hat der gesamte Container für für diese To-Do View den Text des To-Do Textes sag ich mal vielleicht ein bisschen schwer zu beschreiben man kann sich das im DOM wenn man das im Browser ausmacht sehr schön über die Accessibility Tabs anschauen die vom Browser ein bisschen zu unterschiedlich funktionieren aber genauso wie die normalen DOM Elemente gibt es da eben auch so eine Aufstellung von den semantischen Elementen und da sieht man

dass es dann ein List Item gibt mit dem Titel irgendwas auch immer der Text ist der da eingetragen wurde und alles andere was in dieser To-Do ist also Buttons oder Icons oder Text oder sowas stehen damit im Kontext dieses Wrappers ist das halbwegs verständlich Felix? ja im Wesentlichen kann man das ja runterbrechen auf statt diese Test IDs die unseren Code so ein bisschen polluten und nur in den Testen Sinn haben die ersetzen wir eigentlich oft durch diese ARIA Elemente das ist ja immer ARIA Minus und zum Beispiel hast du in dem List Item hast du ein ARIA Minus Labeled by das ist so ein bisschen

sprechend diese ARIA steht ja immer für Accessible Rich Internet Applications das ist ja diese Web Accessibility Initiative worüber das kommt man kann natürlich jetzt argumentieren dass man sich damit den Code auch vermüllt mit diesen Eigenschaften aber sie helfen natürlich am Ende trotzdem auch unter anderem Screenreadern den Code besser zu verstehen also von daher hat es auch wenn wir es im Wesentlichen für die Tests benutzen und viele Anwendungen sicherlich nicht von Menschen mit Beeinträchtigungen hier verwendet werden also zumindest die die wir jetzt bisher gemacht haben trotzdem hat es einen

Mehrwert in der Anwendung und ist deswegen nicht eben nur Müll genau wenn ich mir schon die Mühe mache die Elemente irgendwie sinnvoll auszuzeichnen oder irgendwie auszuzeichnen dann mache ich es doch gleich so dass es mehr als nur einen Vorteil hat zum Thema Testing noch hier ein Beispiel zum Thema Spy und Mox wir haben hier in der To-Do-View Test Datei auch noch einen Test zum Thema diesem Togglen und das heißt Should call toggle complete on checking und was ich da testen möchte ist das wenn ich die To-Do abschließe dass es dann auch entsprechend nicht nur der Button gedrückt wurde sondern auch im Hintergrund

die Daten geändert werden und das ist gleich der Punkt hier an der Stelle wenn ich diese To-Do-View teste dann interessiert mich ja eigentlich gar nicht ob tatsächlich auch komplett durcheskaliert wird dass ich diesen Button geklickt habe in dem Sinne von dass sich der Local Storage ändert und der interne State dieser ganzen Anwendung sich ändert sondern was mich hier eigentlich interessiert ist dass wenn ich das UI Element klicke in diesem Fall auch hier wieder über eine Roll Checkbox mit einem Label complete dann habe ich vorher einen Spy auf der Toggle Funktion gesetzt und möchte hier nur wissen

wurde diese Toggle Funktion aufgerufen das heißt wirklich so den allernächsten Schritt zwischen dem was in dieser Komponente wirklich passiert nämlich es wird irgendeine andere Funktion aufgerufen das möchte ich abtesten und was diese Funktion dann wiederum für sich macht das ist dann nicht Aufgabe dieser Unit zu testen sondern das ist dann die Aufgabe des Unit Tests für diese Toggle Funktion und deswegen möchte ich das hier nicht noch mit abfrühstücken sondern wirklich nur prüfen wurde die aufgerufen mit den Parametern die ich erwarte das war es das war es zum Thema Testing dann scrolle ich mal

weiter zum Thema Linting es ist auch ein sehr subjektives Thema da hat jede Firma so seine eigenen Vorstellungen Konzepte Linting ist ja eigentlich eine Sache von der man sagt die Funktion funktioniert so oder so egal wie ich jetzt die geschweiften Klammern setze und das Linting ist dann wirklich nur dafür da um einen einheitlichen Code Style zu machen sodass wenn mehrere Anwender am gleichen Projekt arbeiten dass deren Code Styles sich nicht optisch großartig unterscheiden weil der eine die geschweiften Klammern in die nächste Zeile setzt der andere nicht sondern die ganze Anwendung soll wie aus einem

Guss erscheinen und damit meine ich auf Code Ebene deswegen ist Linting ab einer gewissen Größe eigentlich unumgänglich um da eben einheitliche Konzepte und Vorstellungen zu verwirklichen und auch damit sich die Entwickler damit nicht beschäftigen müssen weil was ich jetzt wirklich nicht machen möchte ist im Code Review den Entwicklern zu erklären wie sie die geschweiften Klammern zu setzen haben es hat ja wirklich gar nichts mit den Sachen zu tun mit denen sie sich eigentlich beschäftigen sollen nämlich mit der Logik und einem guten Programm und deswegen haben es wir zum Beispiel bei den Frontend

Projekten React JavaScript so gelöst dass wir dafür ESLint einsetzen und dann eine eigene Genen-IT-Systeme ESLint-Config erstellt haben die wir also bei allen Projekten einsetzen und dann feststellen können dass wir da eben das einheitliche Firmen Linting überall auftragen das ist sogar auch öffentlich ist jetzt vielleicht nicht unbedingt dafür gedacht um es selber zu verwenden dafür ist da die Update Sicherheit nicht so gegeben das mache ich so ein bisschen nebenher aber vielleicht als Inspiration dafür wie sowas aussehen kann und ich habe da wirklich sehr gute Erfahrungen mit die eigentliche

Implementierung in den Projekten ist dann sehr klein und das ESLint kümmert sich dann wirklich um alles was zum Thema Code-Styling zu tun ist da gibt es dann auch immer einen Reformatter in jeder IDE und das heißt beim Speichern werden automatisch die Regeln angewendet das ist bei uns zum Beispiel auch dann automatisch ein Prettier der da drüber läuft also ganz entspannt eine zentrale Konfiguration und eine Stelle wo das automatisch ohne dass die Entwickler was machen müssen das anwendet da sind wir ja tatsächlich ein bisschen unterschiedlicher Meinung weil ich nämlich denke so eine firmeneigene

ESLint-Config macht nicht so wahnsinnig viel Sinn weil es einfach auch gute Konfigs da draußen gibt also viele große Firmen veröffentlichen sowas ja Airbnb Twitter war es damals die haben ja alle Konfigurationen von denen man sich eine aussuchen kann die schon sehr nah an die eigene Forschung rankommen und die haben sich natürlich auch viele Gedanken dazu gemacht also mein Ansatz wäre eher davon was zu übernehmen du bist aber eher so auf dem Standpunkt dass du sagst ich will schon jede Konfiguration so haben wie es jetzt für unseren Code eben gut passt das kann man total verstehen aber grundsätzlich

sind wir da etwas unterschiedlicher Meinung man muss natürlich dazu sagen dass wir auch bei dieser Konfig hier nicht jede einzelne Regel selber aufgestellt haben sondern wir orientieren uns da an den normalen ESLint Recommended Regeln und haben dann wirklich nur in ausgewählten Fällen wo wir wirklich besondere Ansprüche haben da die Regeln selber überschrieben also das orientiert sich schon sehr weit am ESLint Standard und ich habe da vorhin so ein bisschen gezögert als ich gesagt habe dass es ja eigentlich nur tja visueller Flavor ist wenn man so möchte wenn es um das Lean-Thing geht aber das stimmt

meiner Meinung nach nur so bedingt also es ist nicht nur Visuelles will ich damit sagen was wir zum Beispiel haben ist eine ESLint Regel die forciert dass jede Variable typisiert werden muss sogar auch Primitives und das ist zum Beispiel auch etwas wo wir den gängigen Regeln widersprechen also jede einzelne Variable muss vor dem Gleichheitszeichen typisiert werden und das haben wir gemacht weil wir eben sagen uns ist diese strenge Trennung zwischen Abstraktion und Implementierung wichtig haben wir auch einen eigenen Podcast zugemacht und das bedeutet zum Beispiel auch dass wir immer Arrow Functions

gegenüber Named Functions bevorzugen per ESLint Regel weil bei einer Arrow Functions kann man dieses Konzept anwenden und die Funktion typisieren bevor die Implementierung kommt bei einer Named Functions geht das nicht da ist das ein bisschen vermischt und das sind in der Theorie sind das optische Regeln weil beides funktioniert gleich aber für uns ist da eben sehr viel Aussagekraft dahinter und Lesbarkeit und vor allem Einheitlichkeit ob man das so oder so macht und deswegen ist es glaube ich schon wichtig sich nicht nur auf gängige Practices zu berufen obwohl das natürlich ein guter Einstiegspunkt ist

und einem auch hilft in mal fremde Sachen gut reinzukommen aber eben bewusst auch manche Regeln zu setzen oder zu verbiegen wenn sie den eigenen Konzepten folgen statt das einfach nur wirklich als ist ja nur so ein bisschen Formatierung abzutun da muss man ja auch sagen dass wir früher diese allgemeinen Regeln verwendet haben und uns dann Stück für Stück davon entfernt haben weil wir gemerkt haben dass unsere Praxis dann in manchen Punkten doch etwas anders aussieht zum Beispiel diese Typisierung von Primitives das war ja eine ganze Zeit lang nicht so dass wir es gemacht haben und haben dann für uns festgestellt

es klappt aber besser genau und zum Thema dass es nur visuell ist da habe ich auch noch eine nette Anekdote jetzt aus letzter Zeit ich hatte nämlich auch einen Merge Request gestellt und dann sagte jemand der das Review gemacht hat sagte dann boah Felix irgendwie sieht diese Zeile Code komisch aus und das kann man ja nur sagen wenn Code immer ähnlich aussieht wenn man so einen Blick für Code hat und das kann ich jedenfalls aus meiner Erfahrung sagen wenn ich auf Code drauf gucke dann kann ich sagen ob der von uns ist ob der aus unserer Firma kommt also in gewissen Grenzen aber ich habe so das Gefühl

wir haben schon eine gewisse Coding Art oder bestimmte Praktiken die man schon auch wiedererkennen kann und der Code sieht dann sauber aus und in dem konkreten Fall war es jedenfalls so dass wirklich auch einen Fehler drin gesteckt hat den man nicht direkt gesehen hat nämlich dass da ein Text nicht übersetzt wurde der eigentlich hätte übersetzt werden müssen und der stand dann einfach so ein bisschen verloren im Raum und das ist dem anderen Entwickler dann aufgefallen das fand ich ganz beeindruckend dass letztlich eigentlich durch dieses Linting was immer einen gleichen Code erzeugt auch bei dem Entwickler

dann ein Störgefühl erzeugen kann wenn irgendwas eben nicht so aussieht das ist ein fantastisches Beispiel das hat ja sehr viel mit Sehengewohnheit zu tun und genauso wie ich weiß nicht wie es dir geht aber ich als Muttersprachler Deutscher kann wenn ich ein Wort sehe auch wenn ich nicht unbedingt weiß wie es richtig geschrieben wird habe ich so ein instinktives Bauchgefühl von warte das ist irgendwie falsch geschrieben mir fehlt ein E oder weiß ich nicht sonst irgendwas einfach aus so einem Muskelgedächtnis heraus würde ich fast sagen und genauso ist es bei Code auch wenn man viele Jahre lang

mit derselben Art von Code gearbeitet hat und dann auch sehr gut darin ist Muster wieder zu erkennen dann passiert genau dieses Phänomen was du gerade beschrieben hast nämlich man sieht eine Zeile Code und hat instinktiv so ein Bauchgefühl von irgendwas ist hier falsch das habe ich sehr häufig in Code Reviews dass ich so einen instinktiven Impuls habe von hier ist irgendwas falsch und brauche dann aber 10-15 Minuten zusammen mit dem jenigen der es geschrieben hat um dann gemeinsam zu erarbeiten was denn hier eigentlich das Problem ist genau und auf der anderen Seite merke ich das auch immer wieder

wenn ich durch unseren Code durchgehe und eine bestimmte Funktion suche also ich mache zum Beispiel einen Bugfix für eine bestimmte Stelle habe ungefähr eine Vorstellung davon wo der auftreten kann habe vielleicht eine längere TSX Datei wo ich jetzt durchgehe dadurch dass die Dateien immer ähnlich aussehen muss ich gar nicht den ganzen Text lesen sondern habe schon so ein gewisses Gefühl also du konntest es jetzt gerade besser beschreiben als ich aber an welcher Stelle das auftreten kann also ich scrolle da durch und dann sehe ich ah alles klar hier das sieht so aus als wäre das die Stelle und oft passt es dann auch

also man hat wirklich so ein Gefühl für den Code und für die Struktur des Codes das ist ja tatsächlich auch so ein fortlaufendes Ding wo wir als Firma uns so dynamisch entwickeln und was auch leider viele Aspekte beinhaltet die man nicht über so konkrete Linting-Regeln abfrühstücken kann sondern da sind viele Sachen so von Mund zu Mund übertragen und ändern sich innerhalb von einer Projektlaufzeit weil wir dann doch irgendwie merken dass was anderes ist und wenn da neue Entwickler kommen und fragen ja wie wie macht ihr das denn wie sind denn die Regeln dann muss ich immer sagen ja ich sag dir wenn du sie gebrochen hast

aber ich kann dir jetzt nicht eine vollständige Liste aller Regeln geben die wir so haben dieses ESLint Preset ist der Versuch das irgendwie auch einzugießen aber dafür sind da viel zu viele undefinierbare so abstrakte Ideen dahinter die auch nicht um mal 100% in den Fällen eingesetzt werden können sondern eben nur in 99% der Fälle das macht es aber unfassbar schwer da so eine ja vermittelbare Kohärenz zu erzeugen fantastisch 9 von 10 abgehakt jetzt noch ein kleiner Block zum Thema Deployment kannst du noch fast geschafft bleib bei mir Felix ich kann auch Kay ich fürchte nur dass die Folge sehr lang wird

und uns die Zuhörenden abhanden kommen aber die können es ja in Etappen hören richtig wie ist der T Felix ja sowas von leer aber er war wirklich hervorragend fantastisch ich habe auch tatsächlich gar nicht viel zum CI, CD und Deployment und sowas zu sagen weil das jetzt wirklich sehr sehr individuell pro Projekt und pro Umfeld und auch alleine schon pro technischer Plattform ist da hat ja wirklich jeder wie soll ich sagen Git Repository Hoster alleine schon seine eigene Syntax wir haben zum Beispiel GitLab deswegen haben wir uns darauf angeschossen und die haben natürlich so eine ganz eigene Syntax mit ihrem YAML

was komplett inkompatibel semantisch ist zu den Sachen die GitHub mit den Actions hat deswegen kann ich da nur hier auf die gitlab.ci.yaml Datei verweisen die da auch im Projekt liegt die so ganz grob beschreibt wie eben beim Commit oder bei einem Merge Request eben so ein festes Toolset von Aufgaben automatisch in der Pipeline um so ein paar Buzzwords zu verwenden durchgelaufen werden wichtig wichtig ist da vielleicht dass man da möglichst versucht auch TechStack agnostisch zu sein und damit meine ich möglichst die Sachen so formulieren dass sich für sie auch Standalone laufen das ist hier zum Beispiel

wenn man sich so mal diesen Test Unit Step anschaut das einzige was da im Wesentlichen passiert ist dass NPM Install in der Node Umgebung ausgeführt wird und dann NPM Run Test und da sind also keine großartig GitLab spezifischen Sachen drin außer vielleicht die Formulierung wie diese Schritte zu erfolgen haben aber das sind eben auch einfache Sachen die ich auch in der lokalen Entwicklung nachvollziehen kann und das ist mein größter Tipp immer versuchen möglichst wenig Logik innerhalb der Pipeline Syntax also in diesem Fall dieser GitLab CI zu haben sondern möglichst viel dann entweder durch TechStack

spezifische praktischen abzubilden wie zum Beispiel die Node Scripts oder eben vielleicht eine eigene Shell Datei zu schreiben in der man kompliziertere Sachen macht damit man es zum einen lokal einigermaßen gut testen kann so wie es dann nachher auch in der Pipeline läuft und vielleicht dann doch im Fall der Falle schnell mal nach Bitbucket oder sonst irgendwo hin wechseln kann Mensch ich merke auch dass die Zeit zunimmt hier meine Zunge ist wie eine Schlange die sich selber zu einem Luftballon verknotet ja wir könnten vielleicht nochmal drauf eingehen was so die Standard Pipeline Schritte sind

das ist vielleicht das Interessantste hier dran die wir sonst so machen also dass zum Beispiel Linting immer gemacht wird ist klar also bei uns kommt kein Code an der nicht durch unseren Linter durchgelaufen ist wir lassen natürlich unsere Tests laufen in dem Fall von deiner Beispiel App sind es glaube ich jetzt erstmal nur die Unit Tests die dann durchlaufen und dann haben wir irgendeinen Build Step und am Ende ein Deployment was wir manchmal manuell dann noch aktivieren oder was zum Teil auch automatisch passiert genau wir haben gerade vorhin gesagt das Linting sollte eigentlich automatisch schon in der IDE

des Nutzers unsafe passieren hier ist es wirklich nur nochmal als doppelter Boden um wirklich sicherzustellen dass das auch alle Leute richtig aktiviert haben Unit Tests mal so ein Test Compile wie du gesagt hast alles richtig und da muss man wirklich sehr individuell anhand der Anforderungen und der Möglichkeiten überlegen was man da macht und ehrlicherweise im Gegensatz zu all den anderen Sachen die ich jetzt angesprochen habe ist das jetzt auch schon wirklich hart an der Grenze eines Anwendungsentwicklers die ja wirklich nur eine Anwendung schreiben wollen und das ist ja schon viel mehr Richtung

Tja Deployment habe ich ja schon eingangs gesagt man könnte argumentieren dass natürlich saubererweise am Ende von so einem Anwendungszyklus vielleicht so ein Docker Image rauskommt das man dann dem Kunden übergeben kann und das schon am besten irgendwie automatisch anhand so einer Pipeline generieren sollte aber da kann man glaube ich auch jetzt in dem Scope von so einem Podcast da nicht so richtig viel in die Tiefe gehen Ja ich würde sagen insgesamt kommt das natürlich auch sehr darauf an was für ein Umfeld man entwickelt du sagtest ja zum Beispiel gerade beim Deployment das ist jetzt für einen

Anwendungsentwickler nicht mehr so interessant das bezieht sich natürlich vor allem auf die Projekte die wir machen wo wir dann DevOps dabei haben Administratoren und so weiter und so fort eigene Grafika jedenfalls für alle Anwendungsteile so einen eigenen Menschen der es dann macht wenn wir jetzt ein paar Jahre zurückdenken wo man dann eher Fullstack mäßig unterwegs war da wäre das dann schon interessant natürlich auch eine Pipeline als Anwendungsentwickler aufsetzen zu können und dann hinterher auch was rauszubekommen was man dann wirklich verwenden kann wenn das Team eben nicht die entsprechende

Größe hat und ich glaube dass das jedem Anwendungsentwickler auch gut tut zumindest von den Sachen mal gehört zu haben oder vielleicht auch selbst mal eine Pipeline aufgesetzt zu haben häufig ist es ja wichtig dass man einfach weiß dass es solche Dinge gibt auch wenn man jetzt aus dem Stand nicht weiß wie man so eine GitLab Pipeline aufsetzt aber das haben wir ja auch in der Vergangenheit immer gemerkt sobald mal irgendwo so ein Stichwort nur im Raum steht und man irgendwie so ein grobes Gefühl dafür hat dass das vielleicht vom Vorteil sein könnte für die eigenen Sachen die man macht da muss man sich

natürlich selber intensiv damit beschäftigen und das richtige Tool für den Anwendungsfall finden genau was jetzt für mich bei Deployment auch ganz wichtig ist ganz viele machen da natürlich einen wahnsinns Overkill dann laufen die Pipelines lange dann werden da zig Build Steps gemacht und meine Prämisse dabei ist immer versuchen es doch irgendwie so einfach wie möglich zu halten das Nötigste drin zu haben und das jetzt nicht zu overingenieren also wenn wir in den Chats hier lesen ja Pipeline funktioniert wieder nicht oder Pipeline dort wieder lange dann hat man am Ende natürlich auch nichts gewonnen

also es muss schon irgendwie gut funktionieren und kompakt bleiben ja Felix damit ist mein Magnum Opus abgeschlossen mein Vermächtnis sage ich mal jetzt kannst du dich zur Ruhe setzen ja intensiv muss ich sagen auch in der Vorbereitung und dann hier so konsequent das durchzuackern war schon etwas fordernd sage ich mal aber ich hoffe mal die eine oder andere Person nimmt daraus was mit und dann für die nahe Zukunft geloben wir wieder ein bisschen zugänglichere Themen mit mehr Leichtigkeit ja Kay eins kann ich dir versprechen wenn keiner da draußen was mitnimmt dann habe ich was mitgenommen und dafür danke ich dir

schon mal sehr ich habe noch ein mini Feedback von den letzten Folgen und zwar sprechen wir darüber dass wir weit einsetzen und ich musste lernen es heißt Veed obwohl sich das für mich sehr komisch anhört aber offensichtlich ist das die offizielle Aussprache und wir versuchen uns mal dran zu gewöhnen ist das jetzt schon die Zeit wo ich sagen kann ich bin zu alt für sowas und ich nehme meine eigene lange eintrainierte Aussprache sagst du auch immer noch Router oder ist es bei dir schon Router kommt drauf an in welcher Stimmung ich bin also zu Hause steht ja weder ein Router kann ich dir sagen ich nenne es auch

oft noch so obwohl ich meine dass es anders richtig ist aber gut so ist es aber für alle da draußen die das vielleicht zum ersten Mal hören die sollten sich es vielleicht dann richtig angewöhnen also das soll natürlich gar nicht ignorant kriegen danke für das Feedback an der Stelle natürlich also nicht zurückhalten ich bemühe mich auch und solche Inputs sind ja gerade wichtig um mal alte Muster zu brechen wunderbar Kay das war die längste Podcast Folge die wir jemals gemacht haben und deswegen müssen wir ganz schnell zu Ende kommen ich danke dir ganz herzlich wir hören uns und ich wünsche dir später einen schönen Feierabend

Tschödelü