React ToDo-App - Teil 1.

Hallo, lieber Kay, und ein herzliches Willkommen an alle da draußen.

Wir haben exakt vor einem Monat am 13. November die letzte Folge aufgenommen. Also es ist ewig her, aber ich war auch im Urlaub. Bist du überhaupt da? Ja, hallo, hallo, ich bin da und ich freue mich auch, dass wir wieder hier sind. Und du hast recht, die letzten Wochen war so viel zu tun, der weihnachtliche Vorstress, dass wir einfach nicht dazu gekommen sind, die Podcasts vorzubereiten oder aufzunehmen oder sonst irgendwas. Ja, ich sehe es einfach nochmal viel so vor Weihnachten. Von Projektabschlüssen bis dann Organisationen von Weihnachtsfeier und so weiter. Und dann hat man private Termine.

Passte irgendwie nicht so richtig gut dazwischen in den letzten Wochen. Und dazu kommt ja auch, nachdem jetzt diese ganze leichte Unterhaltung der vergangenen Wochen aus dem Weg ist, gehen wir jetzt heute wieder rein mit so einem richtig technischen Hardcore-Thema. Da freue ich mich drauf. Genauso habe ich es mir in meinem Stichpunkt noch aufgeschrieben, dass es heute technisch wird. Kommen wir aber gleich zu. Als erstes muss ich nämlich mal wissen, ob du dir so spät am Nachmittag, wie wir heute aufnehmen, 15.30 Uhr, noch einen Tee gemacht hast oder was hast du mitgebracht? Also, ich habe durch mein Teeregal geschaut, das in der letzten Zeit sehr angewachsen ist.

Und gleichzeitig hatte ich keine Ahnung mehr, was ich schon hier präsentiert habe. Aber ich habe jetzt herausgegriffen, ein Ingwerzauber aus dem Rossmann, das ist auch so ein loser Tee ohne Aroma-Zusätze.

Das ist im Rossmann gar nicht so leicht. Das war auf jeden Fall 60 Prozent Ingwer und dann auch noch so ein bisschen Orangenschalen und Zitonengras. Also, das haut mir richtig die Nasen nebenhöhlen frei. Ja, wo du das jetzt sagst, frage ich mich, warum ich keinen Wintertee mitgebracht habe. Weil ich die immer nur zu so einer ganz bestimmten Zeit im Jahr trinken kann. Also, vielleicht so von Mitte November bis Mitte Januar. Dann brauche ich so Zimt und sowas eher nicht mehr in den Tees. Und bin ja ganz viel wieder auf Chai und so weiter. Aber ich habe heute was anderes mitgebracht. Ich habe nämlich tatsächlich eine Liste an Tees, die ich schon mitgebracht habe.

Also habe ich mir das penibel aufgeschrieben. Sehr gut vorbereitet. Und weiß deshalb auch, dass ich in Folge 10, jetzt gucke ich gerade nach, ob das stimmt. So ist es. Ein Schwarztee aus Mauritius mitgebracht hatte, den mir meine Eltern mitgebracht hatten. Der war damals mit echter Vanille versehen und hatte so ein leichtes Vanillearoma. Ja, und jetzt war ich auf Mauritius und hatte tatsächlich die Gelegenheit, diese Teeplantage zu besuchen. Bois Chérie heißt die. Das ist im Süden von Mauritius. Ganz fantastisches Erlebnis für mich. Das erste Mal auf einer Teeplantage mal eine Teepflanze anfassen und das so zu erleben.

Die haben auch ein kleines Teemuseum dabei, wo dann natürlich die ganze Kolonialhistorie und so weiter auch aufgearbeitet ist. Fand ich total spannend. Alle meine Mitreisenden nicht so. Und deswegen habe ich natürlich jetzt heute auch einen Tee von dort mitgebracht. Ich wollte aber nicht den gleich nochmal mitbringen, sondern ich habe jetzt wirklich den klassischen Schwarztee, den Tee Nero von da mitgenommen. Und den habe ich hier und der schmeckt ganz fantastisch. Wieder, muss man sagen. Eine kleine Anekdote nebenbei. Ich hatte, glaube ich, eine Teeüberdosis. Da gibt es nämlich, wenn man da eine Führung macht.

Ganz interessant wirklich. Also da ist ganz viel in Handarbeit. Da kann man wirklich sehen, wie die Teesäcke befüllt werden. Wie alles über die Fließbänder läuft. Wie es getrocknet wird. Was für verschiedene Schritte das da sind. Jedenfalls gibt es am Ende dann so eine Teeverkostung. Da kann man so viel Tee verkosten, wie man will. Und die haben natürlich nicht nur eine Sorte Tee, sondern ich würde jetzt mal schätzen 12, 13, 15 Sorten. Und für mich kommen dann so 7, 8 Sorten in Frage, die ich ganz lecker finde. Also dann im Wesentlichen die Schwarztees, die aromatisierten Schwarztees. Hat mir einer mit Kokos zum Beispiel ganz gut gefallen.

Und da habe ich jedenfalls alle Tees probiert. Alle mit Zucker drin. Alle mit Milch drin. Und danach hatte ich, also ich hatte irre Kopfschmerzen. Und ich habe wirklich mich gefühlt, als wäre ich irgendwie auf Heroin oder irgendwas. Und konnte danach tatsächlich wochenlang keinen Tee mehr sehen. Und jetzt bin ich so seit ein, zwei Wochen bin ich wieder im Tee-Game drin. Und jetzt liebe ich den Tee wie vorher. Aber das war schon heftig. Also habe ich mich durchprobiert. Aber dieser Schwarztee ist jedenfalls ganz fantastisch. Und den brauche ich, denke ich, heute auch. Denn wir sind ja in einer sehr technischen Folge.

Und da erzählst du ganz viel, weil du es intensiv vorbereitet hast. Du hast nämlich eine To-Do-App gebaut in React. Und das soll so ein bisschen beispielhaft sein für die Projekte, die wir bauen, zu machen. Und du wirst uns da durchführen. Vom Konzept bis hinterher zum Deployment. Ich bin ganz gespannt. Jetzt habe ich sehr, sehr viel erzählt. Aber ich denke, der Rest der Folge wird von mir nicht mehr so viel kommen. Von daher, Kay, ich überlasse dir mal das Feld. Du kannst insbesondere dadurch glänzen, indem du darauf aufpasst, dass ich mich nicht hier zu sehr in wirren Details verliere. Weil du hast schon recht.

Ich habe einfach mal so ein Projekt aufgesetzt von ganz vorne. Und dann haben du so eine To-Do-App. Unsere sämtliche Best Practices und Erfahrungen, die wir so über die Jahre gesammelt haben, zusammengegossen. Und die möchte ich heute einfach mal hoffentlich verständlich durchgehen. Du hast es gesagt. Konzept, Installation, wie bauen wir den Projektbaum auf? Errorhandling, um nur so ein paar Stichpunkte zu nennen. Und die besondere Herausforderung ist, dass ich das akustisch machen muss und eigentlich die ganze Zeit Code rezitiere. Es wird eine kleine Herausforderung. Wir gucken mal, ob das klappt.

Aber deine Aufgabe heute, Felix, wird es vor allem sein, zu schauen, ob das halbwegs nachvollziehbar ist, was ich hier schildere, und im Zweifel einzugrätschen. Und ich kann auch schon sagen, das wird eine mehrteilige Folge, das große Magnum Opus der Gen-IT-Systeme. Das heißt, wir machen jetzt schon mal den ersten Teil von N. Dann machen wir eine kleine Winterpause. Und dann nächstes Jahr geht es frisch weiter mit weiteren Teilen. Mal schauen, wie lange wir brauchen, um da durchzugehen. Ja, und dann kann man vielleicht noch vorweg schicken, dass der Code auch bei GitLab veröffentlicht ist. Und wenn jemand ganz motiviert ist, könnt ihr euch den Code parallel auch angucken.

Den Link packen wir euch in die Shownotes mit rein. Und dann habt ihr wirklich da die Struktur. Ihr könnt die Anwendung auch mal aufmachen. Ihr könnt euch angucken, wie die sich anfühlt. Das ist natürlich ein kleines Ding. Und dann fällt es vielleicht etwas leichter, das so nachzuvollziehen, wie wir so eine Anwendung strukturieren. Jetzt kenne ich natürlich grundsätzlich die Struktur von unseren Anwendungen und was wir so machen und tun. Versuche mich aber trotzdem so ein bisschen in unsere ZuhörerInnen reinzudenken und dann entsprechend Fragen zu stellen, Kay, wenn du irgendwo den Faden verlierst.

Fantastisch. Und es ist auch eben eine Chance, dadurch, dass wir den Code jetzt idealerweise schon direkt in den Shownotes haben. Und ihr, beziehungsweise du, lieber Hörmensch da draußen, sich das anschaut und eine Frage dazu hast, dann freuen wir uns auch über deine Frage.

An die E-Mail-Adresse podcast-it-systeme.de. Dann können wir in den nächsten Folgen drauf eingehen und vielleicht die eine oder andere Sache, über die ich jetzt heute so hinweg galoppiere, nochmal näher erörtern.

Ja, und ganz wunderbar wäre natürlich auch, wenn ihr noch Input für uns habt, wie wir noch was verbessern können. Weil das ja immer so ist, wenn man jemandem Code zeigt, jeder, der programmieren kann, hat noch eine gute Idee, wie man es verbessern kann. Und wir sind da natürlich offen und freuen uns sehr, wenn ihr uns da sogar noch ein Stück weit helfen könnt. So, ich habe schon einen großen Schluck genommen. Wir steigen ein mit Kapitel 1, das Konzept. Was wollen wir überhaupt machen? So eine klassische To-Do-App. Und auch wenn es selbstverständlich ist, macht es auf jeden Fall Sinn, bevor man so ein Projekt startet, einmal zu überlegen, okay, was soll hier überhaupt gemacht werden, ohne dass ich mich schon total im Code verliere.

Weil wichtig ist erstmal, so ein abstraktes Konzept davon zu haben, was soll eigentlich passieren? Wie sind die Zusammenhänge und was sind die Anforderungen vom Kunden und kann ich die überhaupt so abbilden, wie alle sich das vorstellen?

Direkt reinspringen im Code, das ist zwar, macht total Spaß und Dinge neu machen und so weiter, aber wichtig ist erstmal dieser Schritt weg. Ich glaube, wichtig sage ich jetzt ganz oft in diesem Podcast und erkennen, um was es geht. Weißt du, was ich früher immer als erstes gemacht habe, wenn ich ein neues Projekt hatte? Was denn? Vielleicht wirst du da noch zu kommen, vielleicht nehme ich was vorweg, aber ich habe als allererstes, also wir überspringen jetzt den ganzen Schritt mit dem Kunden sprechen, Anforderungen aufnehmen und so weiter, glaube ich.

Kannst du mich aber auch korrigieren. Aber das Erste, was ich gemacht habe, bevor ich die erste Zeile Code geschrieben habe, war immer, dass ich so ein Entity-Relationship-Modell, also so ein ER-Modell, ER-Diagramm, wie auch immer man es nennen will, jedenfalls ein Datenbank-Modell aufgestellt habe.

Und das hat mir immer mega geholfen, die Anwendung so strukturiert einmal im Kopf zu haben. Fantastisch. Gib mir noch fünf Zeilen Zeit, dann können wir darauf hinauskommen. Herrlich, los geht's. Bevor wir darüber sprechen, wirklich erstmal ganz classic, was soll die Anwendung können? Wir wollen eine neue Aufgabe anlegen, dann wollen wir natürlich alle Aufgaben, die angelegt wurden, anzeigen und das heißt auch irgendwie persistieren.

Man möchte Aufgaben erledigen. Das ist also wirklich ganz abstrakt, da kann ich mit jedem Kunden drüber reden, der versteht das. Und dann der nächste Schritt, wenn wir alle einig sind, dass das so ungefähr das ist, was wir machen wollen. Felix, hast du vollkommen recht. Nämlich, wir überlegen uns, mit welchen Entitäten haben wir es hier zu tun. Wir haben da schon eine ganze Folge drüber gemacht und es ist meiner Meinung nach immer noch eines der allerwichtigsten, allerwichtigsten, wenn nicht sogar das wichtigste Konzept in der Programmierung. Deswegen möchte ich gerne auf unsere Folge zwei oder drei oder so verweisen, wo wir dieses Entity-Konzept ganz ausführlich besprochen haben.

Aber nochmal zusammengefasst geht es darum, eine Abstraktion im Code zu finden, mit der wir reale Dinge abbilden können.

Und das sind üblicherweise in so einer Anwendung mehrere und die haben bestimmte Eigenschaften und haben bestimmte Zusammenhänge. In so einer klassischen Backend-Anwendung bildet man das genau mit diesem Entity-Relation-Diagramm ab, wo man also sagt, wir haben diese und jene Entitäten und die haben die Zusammenhänge. Und auch wenn wir hier keine Datenbank im Grunde hinterhaben, ist der Prozess genau der gleiche, nämlich überlegen, welche Entitäten haben wir denn, was haben die vielleicht für Eigenschaften und wie stehen die in der Verbindung zueinander.

Und Felix, vielleicht magst du dir mal überlegen, was für Entitäten wir hier haben, wie die aussehen und welche Beziehungen die zueinander haben.

Ja, wir haben auf jeden Fall mal zentral die Aufgabe, nenne ich sie mal, also die To-Do. Das ist bei uns, glaube ich, im Moment nur ein Texteintrag, der als Eigenschaften wahrscheinlich hat, ob das erledigt ist oder nicht. Vielleicht so ein Archiviert-Status, gelöscht, sowas in der Richtung. So Benutzerverwaltung und sowas haben wir, glaube ich, jetzt hier in dem Moment nicht. Nee, genau. Also es ist wirklich ganz einfach eine einzige Entität, mit der wir interagieren, eine Repräsentation von so einer Aufgabe. Da hast du schon richtig den englischen Begriff genannt, den ich auch gewählt habe, nämlich To-Do.

Und meiner Idee nach hat dieses To-Do vier Eigenschaften, nämlich zum allerersten eine ID in Form eines Strings, wo wir irgendeinen unabhängigen Wert reinschreiben, um To-Dos voneinander zu unterscheiden,

auch wenn sie zufällig dann den gleichen Aufgabentext oder das gleiche Erstellungsdatum haben oder sowas. Es ist immer total hilfreich, so eine generische, allgemeingültige ID zu haben, die sich auch nicht ändert. Das zweite ist irgendeine Art von Aufgabentext, das habe ich jetzt mal Label genannt, auch in Form eines Strings. Das dritte ist das Erstellungsdatum der Aufgabe, das habe ich Created Add genannt. Dieses kleine Add-Suffix hinten, so als Indikator dafür, dass da so ein Datumsfeld drin steht. Und das würde ich hier auch in Form von einem Date-Objekt repräsentieren. Also nicht einfach nur ein String, wo ein Datum drin steht oder ein Timestamp,

sondern ich versuche, die allgemeingültigsten Datentypen für diese Felder zu finden. Und ein Date ist da sehr viel aussagekräftiger als vielleicht einfach nur ein Integer oder ein String, weil ein Date gleichzeitig in der Regel bedeutet, es ist auf jeden Fall schon mal ein valides Date. Während nur bei einem String kann ich ja auch Hallo Felix reinschreiben und das ist dann überhaupt kein Date. Und die letzte Eigenschaft, die ich habe, ist ein Completed-Add, auch mit einem Date drin, aber das kann null sein, um anzuzeigen, dass eben die Aufgabe noch nicht erfüllt ist, sondern ausstehend ist. Darf ich ein paar Nachfragen zu den Datentypen stellen?

Aber selbstverständlich. Vielleicht als allererstes mal, wir bauen wahrscheinlich eine reine Frontend-App oder hast du irgendwie eine API geplant oder wie ist da der Aufbau? Nee, es ist nur, guter Hinweis, nur Frontend, also TypeScript, sage ich mal. Aber zu dem Tech-Stack komme ich gleich nochmal. Und dann wirst du das irgendwie entweder einfach nur in einem State speichern oder vielleicht im Local Storage? Genau, für Local Storage habe ich mich jetzt entschieden, um auch so ein bisschen das speichern und laden abzubilden. Okay. Ich habe mir drei Sachen aufgeschrieben zu den Datentypen, weil das so Fragen waren, die in der Vergangenheit immer kamen.

Das erste ist die ID. Klassischerweise hat man eine numerische ID. Früher war das immer in MySQL mit so einem Auto-Increment. Und das hatte in manchen Anwendungen so ein bisschen Nachteil, dass man die erraten konnte und dann die URL zum Beispiel manipulieren konnte und da eine ID reingeben konnte, zum Beispiel ein anderes User-Profil aufrufen oder so.

Bist du grundsätzlich ein Fan von UU-IDs? Sind für dich ID-Strings? Sind das Integer? Wie bildest du das ab hier in der App? Also, das ist getrennt von hier in der App und generell. Wenn ich einfach generell drüber spreche, dann hast du vollkommen recht. Das Problem, in Anführungszeichen, mit numerischen IDs, die man hochzählen kann, ist, dass sie nicht so ganz sicher sind, beziehungsweise schwieriger sind.

Wenn ich zum Beispiel eine Anwendung mit Nutzern habe, dann ist der ID slash User slash 50 und dann kann ich mal slash User slash 1000 eingeben und bekomme entweder einen Autorisierungsfehler.

Dann weiß ich, den Nutzer gibt es, aber ich kann nicht darauf zugreifen oder ich bekomme einen Not-Found-Error. Dann weiß ich, okay, guck mal, die Anwendung hat nicht mal 1000 Nutzer. Also, ich kann dann anhand von so URLs, die ich errate, so ein bisschen checken, wie ist denn die Anwendung aufgebaut.

Vorausgesetzt natürlich, die Anwendung hat ein gutes Sicherheitskonzept. Sonst rufe ich ID User 8000 auf, der bin nicht ich, bekomme aber trotzdem seine Profile zugeschickt.

Also, das ist so ein bisschen das Gefährliche an IDs, die man einfach hochzählen kann. Muss man jetzt von Projekt zu Projekt unterscheiden, ob das dramatisch ist oder ob man das eh alles nur intern hat. Der Vorteil an IDs gleichzeitig ist, die sind super kurz. Also, Felix, wenn ich dir eine Nutzer-ID schicke, dann sage ich dir mal eben eine vierstellige Zahl. Die Alternative mit so einer UUID, die hat ja 32 Stellen, die sage ich dir jetzt mal nicht so schnell am Telefon durch oder so. Aber, um deine Frage zu beantworten, ich bin inzwischen großer Fan einfach von UUIDs. Da weiß man immer, okay, die sind genauso groß und man hat keine Probleme damit, irgendwie mit dieser Auto-Increment-Geschichte und sowas.

Wobei UUID statt Incremental-ID niemals eine Ausrede für schlechte Sicherheit sein sollte. Das denke ich auch. Ja, man merkt schon, ich könnte jetzt noch zehn Nachfragen stellen. Das wäre wahrscheinlich sogar auch Thema von einer eigenen Folge. Von daher lasse ich es dabei jetzt erstmal. Ich denke, ein paar Denkanstöße haben wir drin. Ich habe noch zwei weitere Sachen. Das eine ist, bei dem Datum hast du jetzt gesagt, du wählst ein Datumsformat. Früher hat man jetzt in der Datenbank auch gerne Timestamps verwendet. Ist das nur aktuell? Macht man das? Intern ist es ja letztlich ein Timestamp. Was wählst du da für ein Format am liebsten?

Was mir jetzt vielleicht nochmal generell bei der Ausstellung von dieser Entity wichtig ist, ist, dass wir nicht über eine Entity in TypeScript sprechen oder nicht über eine Entity in MySQL oder sonst irgendwas, sondern wir beide überlegen uns komplett in der grünen Wiese, ganz abstrakt, wie diese Entität aussieht. Und deswegen meine ich auch, als ich gesagt habe, Created-Ad mache ich mit einem Date, meinte ich nicht das JavaScript-Date-Objekt, sondern ich meinte irgendeine Art von Date-Konzept, was es bestimmt in der Sprache, die wir dann nachher benutzen. Weil es ist nämlich wichtig, dass man versucht, auf der grünen Wiese diese Entitäten zu überlegen,

ohne irgendwelche Tech-Stack-spezifischen Einschränkungen. Sondern ich überlege mir, was ist das bestmögliche Konzept, um die Realität abzubilden? Und erst im nachgelagerten Schritt beschäftige ich mich damit, wie ich das dann in dem Tech-Stack abbilde, wo ich es wirklich dann einsetze. Also zu der konkreten TypeScript-Implementierung von meiner To-Do-Entität komme ich nachher noch separat. Wunderbar, das reicht mir als Antwort. Und dann habe ich als allerletztes noch, du hast, glaube ich, kein Deleted-Status im Moment drin, also kein Gelösch-Status, wenn ich mich richtig erinnere. Wenn du einen hättest, stehst du eher auf einen Soft-Delete.

Will heißen, man löscht den Eintrag nicht tatsächlich, sondern man gibt nur eine Eigenschaft, zum Beispiel ein Datum in ein Deleted-Ad-Feld, das dann besagt, diesen Eintrag gibt es eigentlich nicht mehr. Oder bist du ein Fan von wirklichen Deletes? Oder kann man das vielleicht gar nicht so pauschal sagen? Wie immer kann man das nicht so pauschal sagen. Hat beides seine Vor- und Nachteile. Mit dem Soft-Delete hast du die Daten noch weiter in der Datenbank, aber sie sind unsichtbar. Das heißt, du kannst die wiederherstellen. Gleichzeitig füllen sie dir aber auch kontinuierlich deine Datenbank. Und wenn du dann trotz Soft-Delete das nicht regelmäßig aufräumst,

hast du nach zehn Jahren, in dem das Programm läuft, auf einmal zehn Jahre alte Datensätze, die einfach handfest Speicher wegfressen. Insbesondere, wenn du in der Tabelle komplizierte Sachen speicherst. Kann auch ein Sicherheits- und auch ein Datenschutzrisiko inzwischen sein. Sollte man natürlich auch mal bedenken dann an der Stelle. Genau, das kommt natürlich auch noch dazu. DSGVO und sowas. Du darfst Sachen nicht länger speichern, als dass du sie benutzt. Und wenn dann auf einmal Dinge in der Datenbank stehen, die schon zehn Jahre alt sind, ist nicht so ideal. Und ich kann mir vorstellen, viele machen das, um so ein bisschen so eine Historie zu haben,

um zu sehen, wie Dinge mal waren. Da kann ich vielleicht noch das Stichwort Audit in den Raum werfen. Also, dass man bei Datenbanken, sag ich jetzt mal als klassisches Beispiel, noch eine zusätzliche Tabelle hat, wo man Veränderungen an den Entities festhält, sodass man schauen kann, wie die sich über Zeit verändern. Weil ansonsten ist so eine Entity ja immer nur eine Momentaufnahme. Jetzt gerade sieht die so aus. Aber insbesondere für Fehlerbehebung oder sowas ist es häufig hilfreich zu sehen, okay, wie hat sich das denn entwickelt und wer hat wann da irgendwelche Änderungen vorgenommen. Früher haben wir immer gesagt, wir gehen beim Anwender vom DAO aus.

Kennst du den Begriff noch? Dümmster anzunehmender User. Ja, genau, so hieß das. Und aus dieser Idee raus kam dann auch, dass wir viele Soft-Deletes verwendet haben und gesagt haben, das kann natürlich mal sein, dass ein Anwender etwas löscht, was er nicht löschen wollte. Und wenn man dann den Kunden am Telefon hat und sagt, jo, ich komme wieder dran, dann ist das natürlich mal grandios. Kann man auch anders abwickeln mit Backups und so, die wir natürlich auch machen. Also, genau, müssen wir, glaube ich, gar nicht so viel näher darauf eingehen. Und dann vielleicht nochmal eben als Hinweis, wir reden zwar jetzt über eine To-Do-App,

die relativ klein ist und relativ konkret ist, aber insgesamt soll das natürlich stellvertretend sein, auch für größere Anwendungen. Und deswegen versuche ich hier und da auch nochmal eine Frage nach einem Konzept aufzumachen, das jetzt in einer To-Do-App eigentlich keinen Platz hat wie in einem Soft-Delete, aber vielleicht in einer größeren Anwendung sich, dass der eine oder andere schon mal gefragt hat, wie das denn da funktionieren würde. Auf jeden Fall. Und wenn das jetzt einigermaßen gut funktioniert mit dieser Front-End-To-Do-App-Präsentation, dann könnte ich mir auch vorstellen, das Ganze nochmal fürs Backend zu wiederholen.

Und da sind solche Konzepte wie Soft-Deletes und sowas ja dann sehr viel interessanter. Wunderbar. Also, wir kehren zurück an unserer To-Do-Entität, die wir uns jetzt erstmal, wie gesagt, auf der komplett grünen Wiese überlegt haben, ohne überhaupt zu wissen, dass das nachher eine Front-End-Anwendung mit TypeScript wird oder sonst irgendwas. Und haben uns diese To-Do-Entität mit diesen vier Eigenschaften überlegt. Und wichtig ist da schon, dass man bei diesen To-Dos möglichst simpel bleibt. Also, wir haben wirklich eine Entity, die heißt To-Do mit den Feldern ID, Label, Created-Ad und Completed-Ad.

Und man sieht schon, da habe ich versucht, möglichst keine Wortspiele reinzumachen. Also, dass ich es irgendwie, ja, mir fällt jetzt schon nichts ein, aber To-Do-Item nenne die ganze Entität. Oder das ID-Feld, nur ID nenne statt To-Do-ID oder sowas. Das sehen wir dann nachher, sage ich jetzt mal, oder vielleicht in der nächsten Folge, wenn wir tatsächlich die Komponenten zu diesen Konzepten bauen, dann wird um dieses Wort To-Do alles Mögliche drumherum gebaut, an Pre- und Suffixen. Und wenn wir dann schon einen komplizierten Grundnamen haben, dann kaskadiert das so durch und die Begriffe werden immer, immer länger.

Und wichtig, das habe ich bei dem Entitäten-Konzept auch erklärt, ist, dass wir hier Konzepte finden, die allgemein gültig sind. Also, nicht nur Felix und ich hier als Entwickler können über diese To-Do-Entität sprechen, sondern ich kann auch mit Menschen aus dem Vertrieb des Kunden sprechen, die noch nie eine Zeile Code gesehen haben, aber trotzdem wissen, wie eine Aufgabe ist und was das ungefähr für Eigenschaften hat und wie man darüber reden kann. Weil nur so stellt man sich ja, dass man ein gesundes Konzept findet, das auch nachhaltig die Realität des Kunden abbildet und wir nicht irgendwelche komischen technischen Konstrukte bauen,

die dann bei nächstbester Gelegenheit auseinanderfallen. Ja, ist ja jetzt sogar ein Live-Test, denn wir haben ja einige nicht-technische Hörer und ich glaube, die müssten eigentlich nachvollziehen können, was für Felder wir jetzt hier für diese Entität aufgemacht haben. ID als Identifier, also um das Ding zu identifizieren, den Text, das Label nennst du es, um die Beschreibung richtig reinzupacken, den Titel und dann ein Erstellungsdatum und das letzte habe ich vergessen. Achso, ob es erledigt wurde, genau. Das macht schon irgendwie Sinn, denke ich auch für jemanden, der jetzt mit Technik erstmal nichts zu tun hat.

Würdest du dir an der Stelle in der Konzeption hier schon Gedanken auch über das Design, über so ein grobes Frontend-Konzept auch machen? Jein, also so halb. Es kommt ein bisschen darauf an, wie kompliziert die Anwendung ist. Grundsätzlich bin ich der Meinung, dass sich aus den Entities und wie sie miteinander zusammenhängen, sich zwangsläufig schon ein gewisses UI aufdrängt, weil wir ja mit den Entitäten irgendwie sie darstellen und umgehen und bearbeiten müssen. Und das wird dann so eine klassische Crude-Anwendung. Und üblicherweise, wenn man nur so stumpf darüber nachdenkt, einige Erfahrungen hat,

dann hat man im Kopf schon ganz automatisch aus den Erfahrungen heraus, wie das so ungefähr aussehen könnte. Nun ist das natürlich üblicherweise nicht das, was sonderlich gut einen Innovations-Award in Webdesign gewinnt. Plus, nicht alle müssen das direkt im Kopf haben, so wie ich. Deswegen ist es wahrscheinlich für alle Beteiligten hilfreich, wenn man schon auf jeden Fall mal so ein UI baut. Das kann dann unterschiedlich ausgeprägt sein. Entweder nur so ein Wireframe, wo man mit einfachsten Formen anzeigt, wo welche Elemente liegen oder wirklich mit einem aufwendigen Konzept, das man dann auch vielleicht mit dem Kunden besprechen kann,

weil den interessiert ja wirklich nur, wie es aussieht und nicht, was technisch dahinter steckt. Und das ist ein super Stichpunkt, dass man das eben auch mit dem Kunden besprechen kann. Ich habe das in der Vergangenheit oft so gemacht, gerade auch bei dem Schweizer Kunden, den wir zum Beispiel gerade haben. Da haben wir viele Mockups gemacht und die habe ich jetzt da in Adobe XD gemacht. Das ist ja so, glaube ich, eingestellt. Gibt es bald nicht mehr. Viele machen das in Figma. Gibt aber auch sowas wie Balsamic-Mockups. Man kann aber auch einfach auf dem Papier mit dem Stift das aufzeichnen. Und in dem Moment, wo man so eine Idee

von einer Anwendung zu Papier bringt, bei einer To-Do-App ist es jetzt einfach, da hat man wahrscheinlich was im Kopf, aber in dem Moment, wo das viele Entities werden und man sich auch nicht sicher ist, mache ich jetzt eine eigene Administrationsseite oder kann ich das vielleicht in einem Pop-Up machen, also in einem Modalfenster oder anders, da macht es schon Sinn, denke ich, bei den allermeisten Anwendungen zumindest die komplizierten Teile oder vielleicht auch die ersten Teile mal in einem Mockup wirklich dann auf Papier in Anführungsstrichen zu bringen und das dann wirklich mit dem Kunden durchzusprechen

oder auch einfach mit den Kollegen. Und mir hilft das immer sehr, weil auf Basis von so einer ersten Ansicht, die noch gar nicht so wahnsinnig viel kann, schiebt man meistens schon oder verändert man noch ganz viele Ideen im Kopf und verbessert die Anwendung eigentlich schon, bevor man die erste Zeile überhaupt geschrieben hat. Genau. Und nur weil ich genau im Kopf habe, wie das aussehen soll, heißt das noch nicht, dass der Mensch links neben mir am Schreibtisch das auch hat und dann auf einmal in eine ganz andere Richtung losgaloppiert. Ganz genau. Deswegen ist es schon wichtig, da irgendwie so ein visuelles Konzept zu haben,

so eine Konzeptidee, mit der man einfach drüber reden kann, wo man vielleicht auch mal Ausdruck und Zeichnungen dran machen kann oder sowas. Also das ist auf jeden Fall hilfreich. Vielleicht machen wir das kurz an der Stelle für genau diese To-Do-App. Das habe ich jetzt so ein bisschen übersprungen. Aber vielleicht hilft das auch, den Leuten da draußen sich vorzustellen, wenn sie die Webseite jetzt nicht in Aktion sehen können. Ich glaube, die verlinken wir auch irgendwo in den Shownotes. Man stellt sich vor, eine relativ schlanke Seite, mittig ausgerichtet. Oben ist eine Leiste, wo man neue Aufgaben reinschreiben kann,

wirklich nur anhand eines kurzen Textes. Daneben ist so ein irgendein gearteter Button, mit dem ich das bestätigen und abschicken kann. Und darunter, unter diesem Eingabefeld, bekomme ich dann eine Liste mit den ganzen Aufgaben, die ich angelegt habe und kann die dann abhaken, vielleicht löschen und mir nochmal anschauen. Und alles sieht natürlich sehr modern und intuitiv aus. Genau. Damit ist das erste Kapitel abgeschlossen und wir kommen zu Kapitel 2 der Installation oder den Tech-Stack, nenne ich es mal. Was ich jetzt bei der Installation oder generell bei dem Tech-Stack ein bisschen überspringe,

ist die Wegfindung, warum man sich für diese Technologien entscheidet. Also wir haben jetzt allein aus unserer Firmenhistorie gemacht eine React-Anwendung, basierend auf TypeScript, benutzen dabei so Sachen wie Vite und ES-Lint, gehe ich gleich nochmal drauf ein, dann so ein paar Packages, die uns über die Jahre gute Dienste erwiesen haben für verschiedene Aspekte. Aber das ist natürlich auch an sich schon ein riesiger Podcast wert, wie man überhaupt zur Entscheidung für diesen Tech-Stack kommt. Warum nimmt man TypeScript und nicht JavaScript, warum nimmt man React und nicht Vue oder vielleicht eine

Backend-Entwicklung oder sonst irgendwas. Das würde jetzt allerdings hier so ein bisschen den Scope sprengen, deswegen gehe ich jetzt einfach mal davon aus, dass wir uns für den Tech-Stack schon entschieden haben. Wir benutzen inzwischen Bun statt Node oder NPM für alles, was mit so JavaScript-Runtimes zu tun hat. Deswegen ist jetzt der Befehl zum Erstellen eines neuen Projekts, da gehen wir jetzt mal ein bisschen rein, Bun Create, dann benutzen wir Vite als Bundler, benutzen das React-TS-Template und können dann einen Projektnamen spezifizieren. Ist das ein öffentliches Template, was man so verwenden kann,

sowas wie damals Create React App? Genau, das ist so eine Boilerplate, die eben schon ganz, ganz viele Dinge mitbringt, nämlich eine TypeScript-Konfiguration, eine Vite-Konfiguration, ESLint ist schon dabei, so ein All-in-One rundum-sorglos-Paket. Das hat ja so ein bisschen ein Shift stattgefunden von Create React App weg, das ist ja offiziell auch eingestellt, hin zum Beispiel nach Vite als so ein Asset-Bundler und für die Sachen, die man früher mit Node oder mit NPM gemacht hat, gibt es jetzt inzwischen andere Anbieter wie zum Beispiel Bun und das ist dann alles, will ich jetzt nicht zu sehr

ins technische Detail gehen, aber eine Frage von Performance und Zugänglichkeit, aber die API und die grundlegenden Konzepte sind alle das Gleiche. Da kann ich als Side-Note hier auch nochmal reinkippen, wir haben ja Projekte umgezogen auf weit und das war ein irrer Performance-Gewinn, den wir dadurch auch erzielen konnten. Genau, da gibt es ja ganz witzige Konzepte dahinter, da will ich jetzt nicht zu sehr reingehen. ES-Lint habe ich gerade schon angesprochen, das benutzen wir als Linting, da habe ich nachher ein komplett eigenes Kapitel dafür, nur dass wir es schon mal gehört haben. Die sonstigen

wichtigen Pakete, die wir so haben, gehe ich jetzt auch einmal durch. Wie gesagt, alles einzelne Kapitel später, nur dass man es schon mal gehört hat. Wir benutzen React, habe ich schon gesagt, Material UI für das ganze UI, Formic machen wir als Formstate-Händler, dann haben wir Jup zur Validierung, Signals, die Preact-Signals benutzen wir da als globalen Store, ES-Lint sagte ich schon und Y-Test für das Testing. Ist jetzt gar nicht schlimm, wenn die ganzen Begriffe nichts sagen, nur schon mal als Tech-Stack-Bingo, da gehe ich nachher einzeln drauf ein. Kapitel 3 der Projektbaum. Das ist jetzt

natürlich schon so ein bisschen auf diesen Tech-Stack gebrandet, den wir hier haben. Diese Bann- und Weit-Installation legt natürlich schon klassisch diesen Public-Ordner an und diesen Source-Ordner. Ich würde jetzt trotzdem vielleicht einmal kurz erklären, was so die grobe Unterscheidung ist innerhalb dieses Source-Ordners. Ich will jetzt nicht auf jede dieser 50 Dateien eingehen, die da in dieser Boilerplate mitgeneriert werden, nur grundsätzlich wie unser Projektbaum aussieht. So eine Komponente oder so eine Anwendung, jetzt mal ganz generell fürs Frontend gesprochen, das Backend vielleicht sogar

auch, gliedert sich bei uns in vier große Bereiche. Der erste Bereich, den habe ich jetzt mal Screens genannt. Da kommen die Bausteine rein, die direkt über die URL angesprochen werden. Und das ist so eine 1-zu-1 Repräsentation von eben URLs und als guter Einstiegspunkt, damit man zumindest schon mal weiß, grob, wo man unterwegs ist. Das heißt, wenn ich eine Home-Seite habe, würde ich da drinnen ein Home-Screen anlegen. Wenn ich eine User-Seite habe, dann vielleicht eine User-View. Ich kann auch ein bisschen überlegen, ob man das Page oder View oder Screen nennt. Aber das ist so das erste Konzept,

nämlich pro URL so Startseiten, auf die man draufkommt. Wichtig ist, dass die Einstiegspunkt dienen und Layout für andere Module sind. Module ist dann nämlich auch der zweite große Block und das ist so ein bisschen eigentlich das flexibelste Konzept, weil Module sind alle Bereiche in einer Anwendung, die sich mit einem Thema beschäftigen und dabei kann jedes Modul aus beliebig vielen Unterblöcken oder Bausteinen bestehen, die dieses Modul braucht, um zu funktionieren. Also, man könnte zum Beispiel sagen, wir haben ein Modul Login, das beschäftigt sich komplett alles, was mit diesem Login zu tun

hat und darin sind dann verschiedene Views oder vielleicht irgendwelche Helper, die diese Login-Mass gebrauchen, um zu funktionieren. Der dritte Baustein sind dann Components und die gehen so Hand in Hand mit diesen Modulen. Components, wie wir sie nennen, sind wirklich ganz kleine einzelne UI-Elemente, die ganz kleine Aufgaben erfüllen und von überall in der Anwendung wiederverwendet werden. Also klassisch Buttons oder Inputs oder so kleine Tab-Reiter oder sonst irgendwas. Also solche, die auch nicht wirklich eigene Logik mitbringen, sondern so wiederverwendbare Bausteine sind, die man überall in der

Anwendung dazu benutzen kann, um das tatsächliche Layout zusammenzubauen. Das wären aber jetzt nicht Funktionen wie so eine Datumsumwandlung oder technische Helper Funktionen? Genau, die kommen nämlich in die vierte Kategorie, das heißt jetzt bei uns einfach Utilities und das sind wirklich ganz normale JavaScript Funktionen, die allgemeingültige, ganz besondere, spezifische Aufgaben haben, die aber trotzdem allgemeingültig genug sind, dass sie von überall in der Anwendung benutzt werden können und nicht zum Beispiel nur auf ein Modul zugeschnitten sind. Das ist so die grundsätzliche Aufteilung

und das kann dann so ein bisschen variieren. Die Idee ist, dass die ganze Businesslogik in diesen Modulen drin steckt, weil alles, was mit dem Login zu tun hat, soll dann bitte auch im Login-Modul stattfinden und das Login-Modul wiederum setzt dann verschiedene Components ein, die aus diesem allgemeinen Components Verzeichnis kommen, um zum Beispiel das Nutzername Feld oder das Passwort Feld oder den Submit Button abzubilden und dieses Login-Modul wiederum gliedert sich ein irgendwo auf einem Screen, wo dieses Login-Modul angezeigt werden soll oder vielleicht auch auf verschiedenen Screens, wer weiß es

schon. Und dadurch hat man diese Hierarchie von Screens, keine Logik, nur Layout, hin zu Modulen, ganz viel Logik und fancy Stuff und dann wieder Components, die kaum eigene Logik mitbringen, sondern nur Kleinstaufgaben erfüllen. In unserem Projekt spezifisch für diese Kleinstkomponenten benutzen wir Material UI. Die haben ja so eine Riesenbibliothek von eben diesen Kleinstbausteinen, die wir verwenden und deswegen sind die jetzt bei uns nicht so unbedingt. Vielleicht generell habe ich jetzt ganz abstrakt nur über Bausteine und Module gesprochen. Das fasse ich jetzt mal als Wort Unit zusammen.

Also ein Baustein, der ein Konzept repräsentiert. Das wird jetzt vielleicht schon ein bisschen abstrakt, aber eine Unit könnte zum Beispiel ein Button sein oder eine Unit könnte auch ein Screen sein oder eine Unit könnte auch ein Modul sein mit wiederum weiteren Unterunits. Und was sich bei uns gut herausgestellt hat, ist, dass jeder Unit sein eigenes Verzeichnis bekommt und in diesem Verzeichnis gibt es eine Datei, die so heißt, wie das Verzeichnis und die Unit und die dient so als Public Einstiegspunkt, wenn man so möchte. Beispiel, wenn wir so eine eigene Button-Komponente bauen wollen würden,

würden wir ein Verzeichnis Button machen und darin eine Datei Button und dann zum Beispiel TSX als Endung für eine TypeScript React-Datei und die dient als Public Einstiegspunkt für diesen Button. Das heißt, wenn ich irgendwo in der Anwendung den Button benutzen möchte, dann importiere ich den aus Button Slash Button und setze den ein. Und alles andere, was in diesem Button Verzeichnis vielleicht noch drin ist, das ist Private in Anführungszeichen. Das heißt, nicht dafür gedacht, von irgendwo anders verwendet zu werden. Und das könnten zum Beispiel Testdateien sein, also Button.test. .tsx oder

vielleicht bei React so eine Storybook-Komponente oder Labels, die man da einzeln reinpacken kann oder vielleicht auch weitere Unterunits, die dann in Button drin sind, also Button Slash irgendwas Slash irgendwas und die sollten dann aber nicht öffentlich verwendet werden, sondern sind nur für diesen Button bestimmt. Und so kann ich schon anhand der Dateifade von bestimmten Dingern erkennen, ist es jetzt ein Public Baustein, den ich irgendwo in der Anwendung verwenden kann oder ist das schon gescoped nur auf diesen Button? Da haben wir glaube ich in der Folge 2 drüber gesprochen, wie benennen wir

Dinge, da geht es ja viel um diese Entitäten und und da war ein Beispiel meine ich was wir genommen haben, dass wir eine Liste hatten und dann ein List Item, was darunter ist, was aber letztlich nur von der Liste selbst verwendet wird. Genau, es gibt ja auf Dateiebene nicht so ein Public Private Konzept und damit es nicht so ein Riesenchaos wird, haben wir das so als Konvention eingeführt, damit direkt anhand des Dateifads

Wichtig ist auch in dem Zusammenhang das Konzept von Namespaces oder Modulen. Wir haben das vorhin gesprochen und das bildet so ein bisschen ab, was ich gerade gesagt habe zu diesen Units. Eine Unit ist gleichzeitig auch ein Namespace und das heißt, wenn wir wieder zurückkehren, dann ist alles, was in diesem Button Verzeichnis drin ist, auch im Namespace Button. Namespaces kennt man vielleicht aus klassischer objektorientierter Programmierung. Namespace kann aber auch tatsächlich einfach eine Dateifase sein und ein Namespace beschreibt einfach einen bestimmten Bereich, also einen bestimmten Pfad,

innerhalb dessen sich Konzepte ähneln. Das habe ich gerade anhand dieses Button Beispiels gemacht. Alles in diesem Button Verzeichnis ist im Namespace Button und deswegen ist alles da drin irgendwie mit dem Button verwandt. Da wird jetzt nicht noch einen Input reinkommen oder sonst irgendwas. Und wichtig auch bei diesen Namespaces, wenn es um die Benennung geht, ist, dass man da versucht, möglichst simpel die Dinge zu benennen und auch eben diesen Namespace zu berücksichtigen. Gehen wir mal in die Beispiel To-Do zurück, wo wir uns dann mit beschäftigen. Da wird es sicherlich irgendein To-Do Modul

geben. Und wir haben es schon vorhin gesagt, auch irgendeine Möglichkeit, ein To-Do zu createn. Das heißt, ich werde irgendeine Unit haben, die eine Kombination aus To-Do und Create hat. Und da ich aber schon in allem, was ich mache, in diesem Modul To-Do drin bin, also in dem Namespace, würde ich jetzt nicht hingehen und die Unit auch noch mal To-Do Create nennen. Dann wäre es im Namespace ja quasi doppelt, nämlich To-Do slash To-Do Create. Und weil es aber alles in diesem Namespace zusammengefasst ist, kann ich da wieder die einfachst mögliche Form wählen und hätte dann To-Do slash Create zum Beispiel.

Auch das wieder möglichst simpel die Benennung wählen und redundante Informationen vermeiden, weil das ist dann auch wieder so ein Effekt, der sich total rauskaskadiert, wenn man Modul in Modul und Modul hat. Wenn man da immer so einen zusammengesetzten Namen hat, dann wird es nachher einfach sehr unübersichtlich, wenn man da drei Hierarchien tief ist und irgendwelche Sachen benennen muss. Konkret übersetzt auf unser Projekt, um jetzt mal wieder in die Realität zurückzukehren, sieht das also wie folgt aus. Unser Projekt hat ein Public Verzeichnis, das ist von React so vor gesehen und dann dieses

Source Verzeichnis und in diesem Source Verzeichnis bilden wir diese Projekthierarchie haben, die ich gerade beschrieben habe, indem wir nämlich einen Modules Ordner haben, in dem wir wiederum ein To-Do Modul haben, dann haben wir ein Utils Verzeichnis mit Utilities, außerdem eine Main TSX und eine App TSX, das ist auch immer ganz hilfreich, insbesondere bei React, dass man sagt, Main TSX ist so der Einstiegspunkt für TypeScript, da kann man schon mal allgemeine Sachen machen und und weil wir eine sehr kleine Anwendung haben, ohne großartige Späße in der URL oder sonst, habe ich mir hier diesen

Screen Ordner gespart und auch den Components Ordner, weil wir das direkt von Material UI beziehen. Felix, da haben wir schon die ersten drei Kapitel überlebt. Ja, das war schon mal relativ viel an Info, zum Teil noch ein bisschen abstrakt, ich denke in den nächsten Kapiteln wird es dann ein bisschen konkreter, wenn es dann wirklich auch um Code geht und um konkrete Anwendungen. Genau, das wäre jetzt eine gute Gelegenheit, als Cliffhanger des Modul 4 anzukündigen, wo wir wirklich mal uns Gedanken machen, wie wir dieses To-Do Modul designen, mit den einzelnen Bausteinen, die es hat, mit den Actions,

die da zu tun sind, mit den Types vielleicht und dann auch mit den verschiedenen UI-Elementen, die wir da brauchen. Ich würde sagen, die sparen wir uns auf zum nächsten Mal. Das machen wir so, Kay, dann würde ich hier auch einen relativ harten Cut ansetzen und einfach auf die nächste Folge verweisen und freue mich schon, mit dir weiter einzusteigen, dann in Themen wie Validierung, Styling, Error Handling und so weiter und so fort. Sehr gut, dann bis jetzt gleich direkt im Anschluss. Wir hören uns, Kay.