WEBVTT

00:00:00.261 --> 00:00:14.214
Es ist eine Major Version, also TypeScript hat ja jetzt nicht diese, oh wow wir haben Breaking Changes mit einer Major Version Idee, sondern sie sagen TypeScripts Grundidee ist Breaking Changes zu verursachen, deswegen sagen sie einfach noch 4.9 ist 5.0 dran.

00:00:15.573 --> 00:00:22.298
Also so ein Typparameter kann ja schon sehr wortreich sein und wenn ich jetzt hier so sehe, Konz T, Extents Read Only, irgendwas?

00:00:22.631 --> 00:00:26.610
Ich bin da, wie sagt man das, Kampf geprüft. Ich schreibe Last.

00:00:26.943 --> 00:00:31.057
Also was da im generischen Umfeld passiert, das ist wild.

00:00:32.444 --> 00:00:35.414
Aber es ist so gut, du sagst so viel richtige Sachen. mach ich, ob ich das vermisse.

00:00:35.600 --> 00:01:00.560
Music.

00:01:00.737 --> 00:01:03.577
Hallo und herzlich willkommen zu Working Draft Revision 560.

00:01:03.577 --> 00:01:08.381
Heute am Start der Stefan. Hallo Servus. Und meine Wenigkeit der Peter.

00:01:08.858 --> 00:01:14.577
Was mag wohl das Thema sein, wenn die zwei sich alleine im Working Draft Studio einfinden?

00:01:14.577 --> 00:01:19.217
Jawoll, der Microsoft hat wieder gekreist und gebar uns eine neue TypeScript Version,

00:01:19.217 --> 00:01:20.977
speziell jetzt die Version 5.0.

00:01:20.977 --> 00:01:25.617
Peter und wir zwei ehemaligen Langzeiturlauber dachten uns, lassen wir doch mal die Tradition

00:01:25.617 --> 00:01:30.897
wieder auferleben und sprechen darüber, was es da so alles Neues gibt und ob uns das interessiert

00:01:30.897 --> 00:01:32.177
und wie wir das finden und so weiter.

00:01:33.011 --> 00:01:41.177
Genau. Es ist eine Major Version. Also TypeScript hat ja jetzt nicht diese Oh wow, wir haben Breaking Changes mit einer Major Version Idee, sondern sie sagen,

00:01:41.177 --> 00:01:46.977
TypeScripts Grundidee ist Breaking Changes zu verursachen. Deswegen sagen sie einfach noch

00:01:46.977 --> 00:01:54.217
4.9 ist 5.0 dran. Es erlaubt ihnen aber, troch diverses Verhalten von grundlegenden

00:01:54.217 --> 00:01:59.737
Features neu zu überdenken. Und ich glaube, von dem sehen wir diesmal einige Sachen. Oder zumindest,

00:02:01.143 --> 00:02:05.473
Okay, was würdest du sagen, fällt da so in die Kategorie rein?

00:02:05.968 --> 00:02:08.012
Decorators und Inams.

00:02:08.615 --> 00:02:12.953
Aber meinst du nicht, dass das mit den Decorators eher was damit zu tun hat, dass jetzt der

00:02:12.953 --> 00:02:17.273
ECMAScript-Standard sich mal aufgerafft hat? Ich hätte gemeint, das trifft sich gut.

00:02:17.986 --> 00:02:23.713
Das wäre meine Idee gewesen. Also Decorators, also gut, von vorne.

00:02:23.713 --> 00:02:28.553
Ich wollte gerade sagen, du als Klassenfeinschmecker solltest doch erstmal erklären, was Decorators sind.

00:02:28.553 --> 00:02:37.473
Genau, Decorators. anfangen. Wer von euch schon Angular 2 Plus geschrieben hat, kann sich vielleicht daran

00:02:37.473 --> 00:02:43.093
erinnern, dass Angular diese Decorator Syntax sehr stark verwendet hat. Du hast dieses Add.

00:02:43.364 --> 00:02:50.173
Something über einer Klasse, über eine Methode und kannst damit deine Klasse mit neuen Features

00:02:50.173 --> 00:02:54.093
ausstatten. Oder im Falle von Angular wird heute der Compiler aktiv und sagt, oh wow,

00:02:54.093 --> 00:02:57.613
das ist etwas, das muss ich ein bisschen anders behandeln und da muss ich ein paar zusätzliche

00:02:57.613 --> 00:03:02.493
Compiler-Dinge starten. Und das ist ja ein Feature, das kennt man aus anderen

00:03:02.493 --> 00:03:07.213
Programmiersprachen genauso. Also vor allem in C-Sharp und in Java,

00:03:07.213 --> 00:03:10.893
Java heißt es glaube ich Annotation, sind diese Sachen vorhanden.

00:03:10.893 --> 00:03:14.933
Du kannst einfach sagen, hey, dieses eine fällt, diese eine Methode, diese eine

00:03:14.933 --> 00:03:19.653
Klasse, ich behandle sie jetzt etwas anders, ich füge weitere Eigenschaften

00:03:19.653 --> 00:03:23.173
hinzu oder lese aus diesen Eigenschaften etwas Spezielles raus.

00:03:23.173 --> 00:03:26.573
Basierend auf dem Decoretor Pattern, das ist ein Pattern aus der objektorientierten

00:03:26.573 --> 00:03:32.253
Programmierung halt in Syntax gegossen. Das ist glaube ich der spannende Unterschied zum

00:03:32.253 --> 00:03:38.973
eigentlichen Software Pattern. Und das Thema war das, dieser Decorator, der trägt ja eine Geschichte

00:03:38.973 --> 00:03:43.573
mit sich. Das ist ja fantastisch, weil ursprünglich hat es niemand auf dem Schirm gehabt, außer Google

00:03:43.573 --> 00:03:47.213
für Angular und Angular hat gesagt, hey, lass uns doch unsere eigene Programmiersprache machen,

00:03:47.213 --> 00:03:55.573
AddScript, Add wegen diesem Decorator Add Symbol, mit der wir eben Decorators schreiben können und

00:03:55.573 --> 00:03:58.641
die für unser Framework Angular besonders dienlich sind.

00:03:58.803 --> 00:04:02.573
Und dann hat TypeScript, das TypeScript-Team, gesagt, hey, coole Idee,

00:04:02.573 --> 00:04:07.573
nur 90 Prozent eurer neuen Sprache sind TypeScript, es geht eigentlich wirklich nur um die Decorators.

00:04:08.021 --> 00:04:13.573
Lass uns doch zusammenarbeiten. Anders Heilsberg mit Kollegen ist runtergeflogen nach Mountain View,

00:04:13.573 --> 00:04:20.573
die haben sich mal zwei Wochen eingesperrt in einem Meetingraum und haben noch entschieden, passt, wir können Decorators experimentell unterstützen

00:04:20.573 --> 00:04:24.573
in TypeScript und es braucht keine neue Programmiersprache dafür.

00:04:24.846 --> 00:04:27.340
Und so ist TypeScript überhaupt einmal in Angular reingemandert.

00:04:27.439 --> 00:04:30.813
Und das Spannende war noch, was gesagt haben, hey, okay, Decorators sind das Tier, dass

00:04:30.813 --> 00:04:33.253
auch andere Framework-Hersteller, wie z.B.

00:04:33.253 --> 00:04:38.573
Ember, gemeint haben. Also, coole Idee, wollen wir jetzt auch für unsere Dinge, ist eh in TypeScript, d.h. wir

00:04:38.573 --> 00:04:43.853
brauchen dort nicht irgendwie andere Programmiersprache entdecken, aber Yehuda Katz vom Ember-Team

00:04:43.853 --> 00:04:45.885
hat gesagt, das muss ein sauberer Standard werden.

00:04:46.119 --> 00:04:49.818
War da ein Proposal gemacht und das Proposal liegt jetzt seit keine Ahnung, acht Jahren

00:04:49.863 --> 00:04:52.636
herum oder so. Es hat ewig gedauert.

00:04:52.681 --> 00:04:57.293
Was spannend ist, weil es hat tatsächlich für dieses eine Proposal in ECMAScript ja

00:04:57.293 --> 00:04:59.493
sehr sehr viele Real-World Beispiele gegeben.

00:05:00.351 --> 00:05:03.361
Großes Problem war, es hat sich mit der Modul-Syntax geclasht.

00:05:03.421 --> 00:05:07.058
Das heißt, die Modul-Syntax hat gesagt Export und dann etwas.

00:05:07.751 --> 00:05:12.041
Und die experimentellen Decorator haben gesagt, der Decorator kann über dem Export Keyword sein.

00:05:12.630 --> 00:05:16.641
Und die tatsächlichen ECMAScript Decorators haben gesagt, na ja, eher nach dem Export.

00:05:16.717 --> 00:05:21.321
Das war, glaube ich, dieser große, große Unterschied mit Ausnahme von einigen Details

00:05:21.321 --> 00:05:27.106
in wie solche Decorators implementiert werden sollen. Aber das war der große, große Unterschied.

00:05:27.304 --> 00:05:34.353
Naja, und das ist ja auch immer so Abwärtskompatibilitäts-Fragen mit zum Beispiel irgendwie so private Klassenfelder. Ja, genau.

00:05:34.659 --> 00:05:45.561
Wie spielt das zusammen, wie kann man sowas dekorieren? Also, es ist halt in sich, weil halt so eine Klasse in ECMAScript schon eine hart komplizierte Angelegenheit ist, extra schwierig, so was da noch anzuflanschen.

00:05:45.561 --> 00:05:50.961
Syntaktisch sicherlich, aber halt eben auch semantisch und das Ganze irgendwie zukunftssicher zu gestalten.

00:05:50.961 --> 00:05:55.688
Ich hatte mich ja zwischenzeitlich sogar mal zu der Annahme versteift, das wird eh niemals was.

00:05:56.057 --> 00:05:56.444
Ja.

00:05:56.840 --> 00:06:00.837
Aber es hat halt noch nur irgendwie eine Dekade gedauert und dann ist es was geworden. Ja.

00:06:01.261 --> 00:06:07.341
Das Spannende ist das, also ich weiß nicht, ich glaube, dass der Trend zu eher mehr Funktionen

00:06:07.341 --> 00:06:15.133
nutzen in JavaScript hat einfach das Proposal einschlafen lassen, da war einfach nicht mehr der Nutzen da.

00:06:15.341 --> 00:06:19.701
Und tatsächlich ist es aber nicht so doofes Feature, also gerade wenn man Klassen schreibt,

00:06:19.701 --> 00:06:25.101
wenn man meint, Klassen schreiben zu müssen, dann kann man damit doch einiges Tolles anstellen.

00:06:25.630 --> 00:06:31.021
Und jetzt sind die Decorators hier. Also Decorators sind in ECMAScript jetzt schon länger in Stage 3,

00:06:31.021 --> 00:06:35.421
deswegen ist das, was ich gemeint habe, ich glaube, dass das Scythe Script schon auf die 5.0 gewartet

00:06:35.421 --> 00:06:38.621
hat, bis das die Implementierung endlich landet, weil ich glaube, es ist schon seit über einem Jahr

00:06:39.025 --> 00:06:44.381
das Proposal dort, wo es sein soll. Und es ändert sich in Wirklichkeit nicht großartig viel für

00:06:44.381 --> 00:06:48.381
euch zu entwickeln. Es ist jetzt dem Standard entsprechend, das heißt ihr braucht dieses

00:06:48.381 --> 00:06:52.781
Experimental Decorators Feature nicht mehr. In der Nutzung ändert sich fast nichts. Ich glaube,

00:06:52.781 --> 00:06:59.621
in der Implementierung gibt es andere Methoden oder Funktionsschnittstellen. Ich kann das aber

00:06:59.621 --> 00:07:04.141
nicht genau sagen, weil ich einfach selbst nie Decorators geschrieben habe, weil ich selten

00:07:04.141 --> 00:07:10.941
Klassen schreibe. Na ja, es ist halt insofern, was als ECMAScript schon sich Mühe macht mit den.

00:07:11.469 --> 00:07:16.661
ECMAScript-Features, vor allen Dingen halt eben privaten Feldern nach Art eben von ECMAScript,

00:07:16.661 --> 00:07:21.741
nicht so sehr nach denen von TypeScript, sich da irgendwie zusammen zu finden. Dazu gehört halt

00:07:21.741 --> 00:07:26.181
eben auch dieses neue Accessor Keyword für Jetta und Zeta, die halt dann auf ein privates

00:07:26.181 --> 00:07:32.581
Feld zugreifen, was halt in der Welt von TypeScript, wo Privatheit eben per Compile-Time-Feature

00:07:32.581 --> 00:07:36.061
implementiert wird, einfach keine Rolle spielt und insofern ist das da alles nicht drin.

00:07:36.061 --> 00:07:42.707
Aber die generelle Idee, so aus Perspektive derjenigen, die das am Ende anwenden, ist

00:07:43.101 --> 00:07:44.101
es tatsächlich das Gleiche.

00:07:44.101 --> 00:07:47.261
Ich habe irgendwie ein Klassenfeature, die ganze Klasse oder eine Methode oder ein Feld

00:07:47.261 --> 00:07:51.988
oder weiß Gott was und da klatsche ich dann halt eben Annotationen, add irgendwas davor

00:07:52.366 --> 00:07:56.913
und die helfen dann diesen jeweiligen Features gewisse Funktionen über.

00:07:58.281 --> 00:08:07.091
Als Alternative zum guten alten Class A Extents B. Was ja so ein bisschen Häkeln mit Ofenhandschuhen ist.

00:08:07.091 --> 00:08:16.691
Also geht halt schon, macht halt keinen Spaß. Und da wird halt so das Versprechen von Wiederverwendbarkeit und Komposition besser eingelöst durch so einen Dekorator.

00:08:16.781 --> 00:08:22.803
Der ist im Prinzip einfach nichts weiter als eine Higher Order Function, die halt auf den Klasselementen operiert.

00:08:23.109 --> 00:08:26.091
Also bis da wieder eine Funktion schreibt, könnte ein Dekorator schreiben.

00:08:26.091 --> 00:08:29.651
Solange TypeScript nicht mitspielt, weil das Typing von diesen Dingern ist dann schon ein

00:08:29.651 --> 00:08:35.604
bisschen advanced. Aber ja, das ist jetzt da und das kommt und das wird und ja.

00:08:36.469 --> 00:08:38.629
Wenn man halt meint, Klassen schreiben zu müssen, sagst du, ne?

00:08:38.854 --> 00:08:42.771
Ja, also ich bin ja mittlerweile auch nicht mehr so ein Hardliner wie ich es früher war,

00:08:42.771 --> 00:08:46.451
weil es mir eigentlich mittlerweile sehr wurscht ist, wie jemand entwickelt.

00:08:46.451 --> 00:08:52.700
Es gibt ja Nutzen für Klassen. Wenn du komplexen State verwalten musst und es.

00:08:53.627 --> 00:08:58.651
Gut ist, diesen State über angehängte Methoden zu verwalten, bitte gar schon

00:08:58.651 --> 00:09:03.531
machen wir eine Klasse. Also absolut sinnvoll zum Beispiel Bilderobjekte oder

00:09:03.531 --> 00:09:08.171
Bilderklassen. Herrlich, wo du einfach nicht weißt, hey, gibt es irrsinnig viele

00:09:08.171 --> 00:09:12.487
Varianten, die noch zum finalen Objekt führen können. Mach ein Bilderpattern, wo

00:09:12.811 --> 00:09:15.931
du einfach mit jedem Methodencall etwas vom internen State änderst und dann hast du

00:09:15.931 --> 00:09:19.651
Bilder und du kriegst ein finales Objekt raus. Fantastisch, super, funktioniert sehr

00:09:19.651 --> 00:09:24.691
gut. Überleg halt, ob du diesen State brauchst. Also das ist etwas, was ich bei vielen meiner

00:09:24.691 --> 00:09:30.771
Kunden schrägstrich Kollegen, je nachdem wo ich gerade bin, mitbekommen ist, dass einfach die

00:09:30.771 --> 00:09:35.491
Klasse immer so das erste Mittel ist zu dem Skyfen. Einfach weil sie es so kennen. Und

00:09:35.491 --> 00:09:41.731
dann denkst du, hey cool, du laufst dort in State Maintenance Probleme rein, die du

00:09:41.731 --> 00:09:45.811
alle nicht brauchst, wenn du einfach schaust, hey du kriegst shit in, shit out. Also eine ganz

00:09:45.811 --> 00:09:53.811
Funktion. Du hast Inputparameter, du hast auch Inputparameter. Und man soll halt... also es gibt ja für

00:09:53.811 --> 00:10:00.291
jedes Werkzeug einen Verwendungs-Track und das ist nicht jeder Verwendungs-Track. Und genauso gibt es

00:10:00.291 --> 00:10:04.011
Funktionen, gibt es Dinge, die besser in Objekten, Dinge, die besser in Klassen, Dinge, die besser in

00:10:04.011 --> 00:10:11.571
Funktionen aufgehoben sind. Genau. Ja, also so als wichtigsten Anwendungsfall von Klassen würde ich

00:10:11.571 --> 00:10:15.571
einfach mal in den Raum werfen, irgendwelche anderen Tools, die mit Klassen arbeiten.

00:10:17.375 --> 00:10:22.425
Die Entscheidung ist ja nicht zu 100% dir überlassen, du musst ja mit irgendwas zusammenarbeiten.

00:10:22.632 --> 00:10:27.025
Und wenn du zum Beispiel jetzt hingehst und sagst, ich mach jetzt eine React-Anwendung, Gott bewahre.

00:10:27.548 --> 00:10:33.210
Dann würdest du wahrscheinlich einfach eine klassische Funktion schreiben, die halt irgendwelches JSX ausspuckt, weil das ist halt wie es da gemacht wird.

00:10:33.505 --> 00:10:36.397
Sagst du hingegen, ich möchte jetzt lieber Web-Components bauen.

00:10:37.504 --> 00:10:45.345
Dann wirst du um eine Klasse schlecht herumkommen. Also die Welt da draußen wirkt ja auf deinen Code sich auch aus, würde ich sagen.

00:10:45.345 --> 00:10:51.865
Das sind auch diese Workarounds, die mit diesen Takt-Template-Literals-Orbeten in Webcomponents nicht ausgegoren.

00:10:51.865 --> 00:10:54.985
Also da kommst du an der Klasse nicht vorbei. Das Spannende ist sogar, dass...

00:10:54.985 --> 00:10:56.985
Nicht ausgegoren, aber was Special Interest triggert.

00:10:57.615 --> 00:11:05.185
Das ist nur ein Edicated Guessing. Wir reden ja davon, dass ich mich sowieso nicht mehr auskenn und eigentlich nur versuche,

00:11:05.185 --> 00:11:08.185
klug zu scheißen. Aber das ist... Entschuldige.

00:11:08.823 --> 00:11:14.385
Also ich meine halt nur, so Workarounds, für was?

00:11:15.521 --> 00:11:20.202
Also, so die meisten Web Component Libraries, die ich so sehe, die versuchen halt Web Components

00:11:20.283 --> 00:11:24.334
zu verwenden anstelle von einem Single Page App Framework, a la Angular oder React.

00:11:25.603 --> 00:11:28.545
Und die bauen dann halt irgendwie so Tech Template Tutorials, da schreibt es halt eben

00:11:28.545 --> 00:11:31.305
HTML Fragment dran, dann fabriziert ihr das halt irgendwie, ne?

00:11:31.305 --> 00:11:33.237
Genau. Deine Output oder so. Ja, genau.

00:11:34.305 --> 00:11:37.630
Ist ja alles irgendwie ganz nett, aber das ist meines Erachtens einfach ein Kategoriefehler.

00:11:37.828 --> 00:11:43.305
Weil solche Konstruktionen sind eine Abstraktion über HTML Elemente, quasi ein Templating

00:11:43.305 --> 00:11:47.803
Mechanismus und Web-Components sind ein Mechanismus, um HTML-Elemente in die Welt zu setzen.

00:11:48.235 --> 00:11:48.640
Ja, ja.

00:11:49.522 --> 00:11:54.745
Korrekt. Und das kommt, glaube ich, aus der Ecke von React, wo du wirklich einfach die Idee ist,

00:11:54.745 --> 00:11:58.305
dass du HTML bündelst, weil du ja diesen Framework-Charakter hast.

00:11:58.425 --> 00:12:03.145
Und eigentlich sollte genau das, was du sagst, schon vorher erledigt werden.

00:12:04.718 --> 00:12:07.745
Bevor überhaupt die Web-Komponente greift. Ja, genau.

00:12:07.745 --> 00:12:13.810
Also was halt dem Web sozusagen fehlt, wäre halt ein Art Templating-Mechanismus.

00:12:14.269 --> 00:12:22.137
Also so Handlebars-mäßig. Das würde halt diese Aufgabe, die ja eine Relevante ist.

00:12:22.525 --> 00:12:25.225
Ich will halt einfach nur irgendwie sagen, es gibt da jetzt irgendwie so ein Widget und

00:12:25.225 --> 00:12:29.825
dieses Widget besteht halt irgendwie aus einem Diff mit drei Buttons drin, render das mal da rein.

00:12:29.825 --> 00:12:32.945
Dafür gibt es halt eben keine native Lösung und Web-Components kann man dazu verwenden,

00:12:32.945 --> 00:12:36.945
aber es ist halt einfach schon so ein bisschen wie, keine Ahnung, ich fahre jetzt mit meinem

00:12:36.945 --> 00:12:41.865
Ein kaufen je nach gegebenheit markt funktionieren aber so richtig optimal ist das nicht.

00:12:44.305 --> 00:12:50.465
Für. Ein mensch wie mich der schon lange weg ist vor dem thema da gab es doch mal ein proposal das genau das versucht hat umzusetzen,

00:12:51.719 --> 00:12:53.996
so handelbar style templates,

00:12:54.705 --> 00:12:59.565
Im handelbar style templates oder natürlich gibt es auch bemühungen die,

00:13:00.465 --> 00:13:02.785
jsx syntax einfach sozusagen zu domestizieren,

00:13:03.944 --> 00:13:07.785
ja Also einfach als alternative Funktur für Funktions.

00:13:07.785 --> 00:13:12.559
Da gab es ja sogar mal eine Implementierung von Firefox, nicht dieses...

00:13:13.792 --> 00:13:18.879
Ah, e-Eggmascript. Ja, e-Eggmascript, genau. Eggmascript vor XML oder so, genau.

00:13:19.860 --> 00:13:25.642
Genau. Gab's im Sinne von, das hat mal halt irgendwer mal aufgeschrieben, aber das ist

00:13:25.642 --> 00:13:29.642
glaube ich so aus den 2000ern, aus dem... Na, aber da gab's sogar eine Implementierung.

00:13:29.642 --> 00:13:33.606
Das ist nicht nur irgendwo eine Idee, sondern da gab's eine Implementierung. Ist wahrscheinlich schon längst wieder rausgefallen.

00:13:35.642 --> 00:13:39.642
Ja, ja, das ist auf jeden Fall nicht mehr aktuell. So, was haben wir denn hier noch?

00:13:39.642 --> 00:13:47.282
Ich hab letztens irgendwas gesehen, wo irgendwer was gebaut hatte, das finde ich jetzt eh nicht wieder, im Prinzip ein Proposal gebaut hat,

00:13:47.282 --> 00:13:51.882
wie man das in ECMAscript halt einbauen könnte. Man müsste halt irgendwie, also die Details entgehen

00:13:51.882 --> 00:13:56.282
mir da, weil ich da nicht tief genug drin stecke, aber de facto ist ja das JSX, so wie es heute ist,

00:13:56.724 --> 00:14:02.562
irgendwie relativ spezifisch auf React ausgerichtet in seiner ganzen Art und Weise,

00:14:02.562 --> 00:14:06.762
wie es funktioniert und wenn man das in Vue oder so verwendet, dann bringen halt diese ganzen

00:14:06.762 --> 00:14:11.282
Frameworks eine ganze Menge von Workarounds, damit hat irgendwie funktioniert. Aber so eine Art

00:14:11.282 --> 00:14:15.442
Mechanismus wäre halt glaube ich etwas was man mal machen könnte und was halt

00:14:15.442 --> 00:14:19.518
sicherlich auch sinnvoll wäre aber Web Components sind das halt eben nicht und

00:14:19.722 --> 00:14:24.202
deswegen ist das was du da so... deswegen war ich gerade so etwas etwas angepiekst

00:14:24.202 --> 00:14:29.882
von... Ja das stimmt. Du hast richtig mit der Ansage diese Workarounds greifen

00:14:29.882 --> 00:14:33.508
nicht, aber das Problem ist nicht dass die nicht funktionieren sondern das Das Problem ist, dass man das versucht.

00:14:33.760 --> 00:14:35.506
Die Ausgangssage ist falsch.

00:14:37.198 --> 00:14:42.048
Genau. Eine andere Sache, die ich spannend fand, Nobby, du hast dem gesagt, man macht den React

00:14:42.048 --> 00:14:47.218
halt einfach nur Funktionen DJ6 auspucken. Früher hat es auch noch Klassen gegeben, macht man mittlerweile nicht mehr.

00:14:47.470 --> 00:14:51.568
Aber früher war genau das in einer Komponente, in einer Klassenkomponente, du hast die Klasse

00:14:51.568 --> 00:14:54.368
geschrieben und du hast InternState verwaltet.

00:14:54.672 --> 00:15:02.008
Macht sich ja Sinn. Tatsächlich ist ja eigentlich dieser useState Hook, der jetzt existiert, der ja grausamst

00:15:02.008 --> 00:15:05.368
implementiert ist, wo du halt einfach nur Glück hast, dass du tatsächlich den State

00:15:05.368 --> 00:15:09.048
zurückkriegst oder intern halt wirklich sehr stark wuchführen musst, damit du

00:15:09.048 --> 00:15:13.289
wieder die Komponenteninstanz zum State rückführen kannst.

00:15:13.424 --> 00:15:19.608
Ist ja eigentlich abscheulich im Vergleich zu ich habe eine Klasse und mach einfach

00:15:19.608 --> 00:15:25.408
das Punkt x ist irgendwas. Also genau für solche Dinge wäre ja eigentlich

00:15:25.408 --> 00:15:34.368
eine Klasse das perfekte Mittel. Ja ja halt eben nicht, weil du halt eben Funktionalität nicht so gut teilen kannst. Also useState ist ein einmal implementierter

00:15:34.368 --> 00:15:39.288
unendlich oft recycelbarer Mechanismus. Das kannst du halt mit normalen Klassen nicht machen,

00:15:39.458 --> 00:15:46.808
es sei denn natürlich, Ustate wäre ein Dekorator. Ha! Bingo! Ah, cool und wieder zurückgeführt.

00:15:46.808 --> 00:15:51.968
Also, haha. Ich meine, ich meine, das ist ja genau das Ding. Die adressieren das gleiche Problem.

00:15:51.968 --> 00:15:55.808
Die beiden Mechanismen. Da machst du einfach add tracked drauf oder sonst irgendwas, fertig.

00:15:56.508 --> 00:16:01.168
Ja, genau. Und dann weißt du halt eben, ah, okay, ich muss halt irgendwie da Mechanismen generieren,

00:16:01.168 --> 00:16:04.808
um halt irgendwie diese private Variable zu ändern. Wenn die sich ändert, mache ich halt irgendwie

00:16:04.808 --> 00:16:09.808
meinen wie auch immer in der Klassenmethode implementierten Vergleich. So, entweder mache

00:16:09.808 --> 00:16:12.968
ich irgendwie einen Deep Compare oder ich mache halt so einen Shallow Check, weil Immutability und

00:16:12.968 --> 00:16:17.718
Zeug und dann weiß ich halt eben, ob ich mich neu rendern muss oder nicht. Wunderschön. Könnte ich

00:16:18.048 --> 00:16:21.968
mir vorstellen, dass das funktioniert, weil also ich glaube nicht, dass ich jemals in ReactUseFact

00:16:21.968 --> 00:16:25.688
richtig verwenden würde, wenn ich nicht irgendwie eher es lint hätte, dass mich permanent anplärt.

00:16:25.688 --> 00:16:30.408
Ja, ja, ja. Und wobei es dann die Brücke auch zwischen Framework Code und anderem Code einfach

00:16:30.408 --> 00:16:38.508
leichter, weil die Grenze zum Framework eindeutiger wird. Also dann brauchst du diese Use Effect

00:16:38.508 --> 00:16:42.388
Workarounds nicht, wie du gesagt hast, und dann kannst du auch imperativen Canvas Code

00:16:42.388 --> 00:16:44.490
zum Beispiel schreiben in einem deklarativen Universum.

00:16:44.688 --> 00:16:46.408
Halleluja, das wäre ja mal was.

00:16:46.688 --> 00:16:47.542
Ja, wow.

00:16:47.920 --> 00:16:52.768
Dieses witzige Weis, ich habe immer so diesen Softspot für die Ember Menschen, das ist

00:16:52.768 --> 00:16:57.188
ja das, was Ember eigentlich machen wollte. Aber sie haben halt einfach nicht das richtige

00:16:57.188 --> 00:16:58.120
Markthilm gehabt dazu.

00:16:59.569 --> 00:17:05.628
Nicht das richtige oder nicht genug? Das trau ich mir jetzt nicht sagen.

00:17:05.628 --> 00:17:09.607
Was haben die denn so an Corporate Backer?

00:17:09.715 --> 00:17:12.767
Also den von React kenn ich, der ist ziemlich groß und hat ziemlich tiefe Taschen.

00:17:13.685 --> 00:17:20.094
Ja, und da ist einfach das Outlet vor Skylight am kleinen Ruby und Rails Monitoring Shop.

00:17:21.841 --> 00:17:27.388
Wobei ja dann einer der größeren Backer LinkedIn war. Vielen Dank für's Zuschauen!

00:17:26.963 --> 00:17:31.113
Okay, groß. Und die aber jetzt auch mittlerweile Alternativen suchen, meine,

00:17:31.573 --> 00:17:37.253
meine noch. Ja, okay. War mir auch zum Beispiel gar nicht bekannt, was ja auch

00:17:37.253 --> 00:17:50.413
schon für sich spricht. Ja, das zeigt das Symptom wieder recht gut. Zu den Decorators hätte ich noch eine Anmerkung, wo ich glaube, dass das

00:17:50.413 --> 00:17:53.333
tatsächlich auch ganz eine ganz gute Rolle spielen könnte, weil jetzt unser

00:17:53.333 --> 00:17:58.213
hypothetisches State Management in React, das jetzt die Klassen wieder belebt,

00:17:58.213 --> 00:18:04.333
ich meine, das wäre ja eigentlich ganz gut, wäre ja relativ on-brand, was so JavaScript angeht.

00:18:04.449 --> 00:18:07.493
Klassen sind das Mittel der Wahl. Nee, Klassen sind jetzt doof und riechen nach Luluh. Nee,

00:18:07.493 --> 00:18:08.333
jetzt haben wir wieder Klassen.

00:18:08.500 --> 00:18:12.973
Man bittet ja, lass das Pendel schwingen. Wir brauchen das, ansonsten stirbt die

00:18:12.973 --> 00:18:16.813
Programmiersprache. Wenn es nicht ständig Meinungen gibt von Richtung 1 nach Richtung 2,

00:18:16.813 --> 00:18:18.447
dann schreibt keiner mehr JavaScript.

00:18:18.519 --> 00:18:21.613
So sieht es nämlich aus. Naja, also da glaube ich jetzt nicht unbedingt dran,

00:18:21.613 --> 00:18:24.362
dass das passieren wird. Die sind mit ihrem Krams hier schon ganz gut bedient und Zeug.

00:18:24.653 --> 00:18:29.933
Das ist nicht passiert genug. Ne, aber tatsächlich glaube ich, das könnte ein nützliches Werkzeug

00:18:29.933 --> 00:18:38.093
sein, um tatsächlich Web Components Library gestützt zu bekommen. Weil Web Components

00:18:38.093 --> 00:18:43.733
sind ja notwendigerweise Klassen. Man muss ja immer von HTML Element extenden, damit man halt

00:18:43.733 --> 00:18:48.453
irgendwie bei den Build-Ins, also sowas wie HTML Element und HTML Diff Element und Zeug,

00:18:48.453 --> 00:18:52.293
Die sind ja nicht wirklich Klassen, das sind ja irgendwelche Build-ins, aber wenn ich von

00:18:52.293 --> 00:18:54.501
denen extende, triggern die irgendwelche Logik.

00:18:54.690 --> 00:18:59.632
Und um mich halt irgendwie da ranzuklingen, muss ich halt eben das machen.

00:18:59.822 --> 00:19:05.907
Und bei den Decorators ist es halt, glaube ich, so, dass so HTML-NAS-Verhalten tatsächlich

00:19:06.006 --> 00:19:12.173
in Form von einer Microlibrary bereitgestellt werden könnte, die einfach nur besteht aus

00:19:12.173 --> 00:19:16.093
einem Haufen von Decorators, womit ich dann zum Beispiel sagen kann, es gibt hier irgendwie

00:19:16.093 --> 00:19:21.433
Excessor, irgendwie auf meinem HTML Element, ist jetzt irgendwie so ein Feld Disabled und da kann

00:19:21.433 --> 00:19:27.013
ich dann halt wirklich so Dinge machen wie, dass die entsprechenden Getter und Setter fabriziert

00:19:27.013 --> 00:19:31.253
werden und das Attributänderungsmonitoring und das alles einigermaßen einheitlich wird,

00:19:31.253 --> 00:19:36.293
dass ich einfach deklarieren kann. Ich habe jetzt hier zum Beispiel ein Attribut, so was wie Disabled

00:19:36.632 --> 00:19:41.813
und das ist ja eigentlich ein Boolshes Attribut. Also das ist entweder da oder nicht da, aber was

00:19:41.813 --> 00:19:44.167
Das ist dann zum Beispiel, wenn ich sowas sage wie Disabled gleich False.

00:19:45.166 --> 00:19:56.977
Wie will ich das bewerten also wenn man jetzt ganz nach der reinen leere geht würde man wahrscheinlich sagen das meint dass das ist ablet attribute gesetzt ist auf true weil es ist ja auf was gesetzt also es ist da.

00:19:57.516 --> 00:20:02.436
Möglicherweise will man das ja irgendwie komplizierter gestalten content edit ist ja auch so ein ding da drin oder.

00:20:03.378 --> 00:20:07.870
Attribute die halt mehr so eine art in am state haben mit drei möglichen werten oder so das ist alles.

00:20:08.167 --> 00:20:13.216
Irre kompliziert, auch irgendwie sowas, verarbeitet diese Zahl, dieses Attribut als Zahl.

00:20:13.216 --> 00:20:15.756
Ich kann ja jedes HTML-Attribut alles reinschreiben, was ich lustig bin.

00:20:15.882 --> 00:20:17.880
Käsekuchen, interpretiere das bitte schön als Zahl.

00:20:18.240 --> 00:20:24.407
Wie soll das gehen? Soll da noch der Number rauskommen oder soll da, wenn da noch der Number rauskäme, irgendwie null rauskommen oder irgendwie so Krams, ne?

00:20:24.560 --> 00:20:31.023
Wenn man das einmal schreibt, ist ja gut, aber wie recycle ich das in, wenn ich jetzt drei Komponenten habe und die haben alle drei Attribute?

00:20:32.005 --> 00:20:38.306
Das ist halt im moment wirklich nur möglich indem ich das alles von hand aufschreibe und in den jeweiligen gettern zettern attribut händler diese.

00:20:39.376 --> 00:20:43.616
Ganzen inputs durch entsprechende parsing funktionen durchschicken und wenn das

00:20:43.616 --> 00:20:47.216
alles dekorators werden dann wäre das echt weniger schlimm als es jetzt

00:20:47.216 --> 00:20:52.016
aktuell ist oder das klingt ja klassisch schreibe ich einfach drüber ad web

00:20:52.016 --> 00:20:55.816
component und dann macht das ding automatisch ein so ein define mit der

00:20:55.816 --> 00:20:59.616
component registry aber nur wenn es ist schon gecheckt hat bin ich definiert oder

00:20:59.616 --> 00:21:06.176
nicht und so zeug das könnte alles das ist genau das was litt macht nicht dieses komponent web

00:21:06.176 --> 00:21:11.417
component framework die machen genau das du kannst et custom element schreiben mit dem tag name und,

00:21:12.136 --> 00:21:19.296
die klasse drunter wird als custom element registriert oder du hast am property decorator mit dem wird,

00:21:19.762 --> 00:21:26.216
das mapping zwischen html und deiner dem steht einer klasse gemacht also die richtung gibt schon

00:21:26.216 --> 00:21:27.999
aber jetzt gibt es das halt nach tiefen Schauskripten.

00:21:28.656 --> 00:21:34.976
Erstens das und zweitens ist dieses Lit Zeug halt wieder ein komplett Buy-in, wo ich halt nicht nur ein paar Funktionen habe,

00:21:34.976 --> 00:21:36.976
sondern ich muss halt eben diese Klasse extenden von denen.

00:21:37.298 --> 00:21:38.973
Dieser Custom Element Decorator.

00:21:40.161 --> 00:21:43.258
Denn würde ich mir zutrauen, ihn in der nächsten halben Stunde zu schreiben.

00:21:44.113 --> 00:21:47.948
Und dann funktioniert er, dass du, wenn du da irgendein Element hast, das du ableitst, dass du das registrierst.

00:21:48.830 --> 00:21:52.368
Ja, das ist tatsächlich ein Zehntseiler, den habe ich hier irgendwo rumliegen.

00:21:52.674 --> 00:21:57.841
Cool, erster Framework Code ist da. Und dann hast du dann Bunch of Decorators und haust die rein und schreibst einfach schöner.

00:21:58.715 --> 00:22:01.514
Genau, und das ist halt eben kein Framework, sondern ist halt mehr so eine Art Lowdash.

00:22:01.586 --> 00:22:05.196
Also, greif in diesen Werkzeugkasten rein und du willst irgendwie einen Attribut haben,

00:22:05.430 --> 00:22:10.651
dass irgendwie sowas wie Content Editable ist, nimmst du das, willst das Ding als Custom Element definieren, nimmst du das.

00:22:10.651 --> 00:22:14.691
Aber es ist halt immer noch eine Web Component und du könntest jederzeit jede von diesen Funktionen ersetzen

00:22:14.865 --> 00:22:17.809
oder sein lassen, deine eigene daneben schreiben, das Ganze irgendwie rappen.

00:22:17.853 --> 00:22:25.487
Es wäre halt tatsächlich modular. Es wäre halt, ne, nach der Idee von useState, wo halt eben es auch Libraries von Hooks gibt da draußen für React,

00:22:25.776 --> 00:22:29.211
könnte es halt eben Libraries von Attributimplementierungen geben.

00:22:29.211 --> 00:22:31.891
Und das muss alles gar nicht groß zusammenspielen, weil es halt einfach nur,

00:22:32.527 --> 00:22:36.851
Dinge dekoriert, also Dinge, die ohnehin da sind, in das ohnehin vorhandene, in die

00:22:36.851 --> 00:22:39.971
ohnehin vorhandene Mechanik für Web Components einbindet. Und ich denke, das

00:22:39.971 --> 00:22:43.971
ist schon ziemlich was wert. Gekauft will ich haben.

00:22:43.971 --> 00:22:52.251
Absolut. Okay, ich arbeite halbwegs ich dran. Ja, bitte. Das erste, was du brauchst, ist ein Name und das

00:22:52.251 --> 00:22:58.051
zweite, was du brauchst, ist ein Gizabrepo und dann weiß ich's. Dann kommen nicht die Contributor.

00:22:58.598 --> 00:23:02.651
Ja, dann kommen die Contributors, dann haben die Bugs und dann muss ich das fixen.

00:23:02.651 --> 00:23:05.131
Und dann hab ich auch da Issues, wo drin steht, ist das schon tot?

00:23:05.131 --> 00:23:08.014
Und ich so, nee, ich hab halt nur auf was anderes zu tun.

00:23:08.140 --> 00:23:13.211
Das sollten Leute mit stabileren Nerven machen, als ich das bin.

00:23:13.370 --> 00:23:15.144
Aber, ja.

00:23:15.612 --> 00:23:23.507
Und dieses Interludium wurde Ihnen präsentiert von Burnout-Gefährdeten in 30ern, Anfang 40ern. So ist es.

00:23:24.533 --> 00:23:28.584
Aber, nächste Punkt. Nächster Punkt. Hey, Stefan. Ja.

00:23:29.160 --> 00:23:32.931
Wie viele Use Cases für das Keyword Konst gibt's in TypeScript? Go! Um...

00:23:34.328 --> 00:23:42.578
Gibt aber, ein spannendes Thema ist, also das const-Keyword existiert in JavaScript und in TypeScript.

00:23:42.578 --> 00:23:46.058
In JavaScript definiert es ein konstantes Binding.

00:23:46.229 --> 00:23:50.658
Das heißt, du hast jetzt nicht ein variables Binding, wo du den gleichen Namen neu zuweisen kannst,

00:23:50.658 --> 00:23:53.350
sondern du hast ein konstantes Binding. Das heißt, die Zuweisung ist erfolgt.

00:23:53.818 --> 00:23:58.238
Das heißt, du kannst nichts mehr ändern. Wenn du jetzt einen primitiven Datentyp hast, wird er nicht geändert.

00:23:58.418 --> 00:24:03.498
Wenn du einen komplexen Datentyp hast, wie ein Objekt oder Array, dann kannst du zu einem neuen Element ändern,

00:24:03.498 --> 00:24:05.498
aber nicht mehr vom Objekt auf etwas anderes.

00:24:06.378 --> 00:24:14.738
Das ist der JavaScript Teil und das gibt es auch in TypeScript als Typ Modifier und es gibt es als Typ Assertion.

00:24:15.538 --> 00:24:18.418
Da fällt mir gerade der deutsche Name dazu nicht ein, wo du sagen kannst,

00:24:18.418 --> 00:24:25.898
hey, dieses eine Objekt, dieses eine JavaScript Objekt oder diesen einen JavaScript Wert nennen wir mal so, behandle ich im Typ System

00:24:26.325 --> 00:24:27.810
als Literal Wert.

00:24:27.927 --> 00:24:39.498
Das heißt, TypeScript ist das so. du hast ein Typ und zu diesem Typ passt eine Menge an möglichen Werten und dieser Typ kann sehr breit

00:24:39.498 --> 00:24:44.258
sein, diese Menge kann sehr groß sein oder dieser Typ kann sehr schmal sein, also die Menge kann

00:24:44.258 --> 00:24:55.978
sehr klein sein und mit s-Konst fixierst du den Wert, den du gerade hast, als diesen einen Wertetyp.

00:24:56.239 --> 00:25:01.258
Das heißt, der kann keine andere Form annehmen. Zu dieser Menge ist nur ein einziger Wert kompatibel

00:25:01.258 --> 00:25:06.458
und das ist der, den du gerade definiert hast. Und das ist toll, das ist großartig, falls du

00:25:06.458 --> 00:25:12.098
wirklich auf diese Werte typen zugreifen willst, wenn du die tatsächlichen Strings, die tatsächlichen

00:25:12.098 --> 00:25:17.578
Nummern brauchst und nicht einfach jeden String oder jede Nummer, du entsprechende Keys vielleicht

00:25:17.674 --> 00:25:24.058
brauchst von deinem Objekt, dann hilft es, dass du einfach sagen kannst, hey, mit s-Const hat dieser

00:25:24.058 --> 00:25:26.458
Wird die Bedeutung, dass er sich nicht ändert?

00:25:27.918 --> 00:25:32.230
Und ist dem Typ-System auch als Rotkrist zu behandeln. Genau.

00:25:32.401 --> 00:25:41.128
Und dieses Konst-Schlüsselwort aus dem Typ-System findet jetzt Einzug in GenericType-Parameters.

00:25:42.043 --> 00:25:44.728
Das sind Generics, wo du sagen kannst, hey, du hast hier dieses eine T,

00:25:44.728 --> 00:25:46.841
diesen generischen Typ.

00:25:46.949 --> 00:25:51.688
Aber wenn dieser Typ kommt, dann behandle ihn als Konstant.

00:25:52.608 --> 00:25:55.488
Das geht teilweise schon mit primitiven Werten sehr, sehr gut, wo du einfach sagst,

00:25:55.488 --> 00:26:01.362
du fügst jetzt tatsächlich den literal string Stefan zum Beispiel ein für dieses t, dann ist

00:26:01.648 --> 00:26:04.963
es auch dieser Wert und es kann nur mehr Stefan sein und es kann nicht string werden unter.

00:26:06.328 --> 00:26:10.808
Gewissen Voraussetzungen. Wenn du dort noch jetzt zum Beispiel ein String Array hast, du hast jetzt

00:26:10.808 --> 00:26:15.168
Stefan und Peter in einem Array, dann merkt TypeScript Theo es ist doch eher ein String Array,

00:26:15.387 --> 00:26:21.048
weil das ist wahrscheinlich das nächste was du machen möchtest. Und mit const t kannst du jetzt

00:26:21.048 --> 00:26:26.368
hey, nein, wenn ich dort das Array-Steffen und Peter reingebe, dann behandle ich das auch als

00:26:26.368 --> 00:26:33.168
das Array-Steffen und Peter. Das ist so die Idee. Und es gibt aber ganz coole Use Cases dafür.

00:26:33.168 --> 00:26:38.448
Eine, die ich gesehen habe ist zum Beispiel, du hast einen React-Router, jetzt haben wir wieder

00:26:38.448 --> 00:26:42.608
in dieser Ecke gelandet, wo du halt deine ganzen Routes definierst in einer Funktion,

00:26:42.608 --> 00:26:47.008
defineRoutes, da hast du mit einem const t die ganzen Routen definiert und dann willst du eine

00:26:47.008 --> 00:26:50.848
Methode schreiben oder eine Funktion schreiben, wo du von einer auf die andere dich bewegen kannst,

00:26:51.396 --> 00:26:57.688
über JavaScript, dann kannst du halt dort ein Autocomplete kriegen für genau die Einträge,

00:26:57.688 --> 00:26:59.894
die du Daten eingegeben hast. Ist recht nett.

00:27:01.794 --> 00:27:05.935
Hab ich was vergessen? Ja, Konstiganz.

00:27:06.244 --> 00:27:14.524
Okay, cool. Ah, ja gut. Ja. So, wenn ich vergessen bin, hab ich verdrängt.

00:27:14.524 --> 00:27:22.804
Wir können später nochmal was über ihn am reden. Aber ich meine, die wichtigen Use Cases, die wirklich Menschen nutzen, sind tatsächlich

00:27:22.804 --> 00:27:27.124
ja die, die Konstvariable und die Konst Assertion und das jetzt Konst im Typparameter, was

00:27:27.124 --> 00:27:32.924
das ja im Prinzip bloß ein Mechanismus ist, dass man den Effekt von S-Konst kriegt, ohne

00:27:32.924 --> 00:27:36.516
dass diejenigen, die das am Ende aufrufen, das immer dahinschreiben müssen.

00:27:37.002 --> 00:27:43.524
Ist ja im Prinzip bloß sozusagen eine Justage der Typ-Inferenz.

00:27:43.524 --> 00:27:47.524
Normalerweise würde ja die Typ-Inferenz sagen, irgendwie, hey, hast du dir ein Wert reingesteckt?

00:27:47.524 --> 00:27:50.685
Ich interpretiere den jetzt mal so großzügig, wie ich kann.

00:27:51.414 --> 00:27:54.524
Das ist ja das Type-Widening und S-Konst macht ja im Prinzip das Gegenteil.

00:27:54.524 --> 00:27:58.644
Interpretiere das so engstirnig, wie ich kann. Also Array von drei Strings ist halt eine Liste

00:27:58.644 --> 00:28:03.244
von exakt den drei Strings in der Reihenfolge und nichts anderes. Aber dazu muss ich ja

00:28:03.244 --> 00:28:06.624
als Const irgendwo da reinschreiben und wenn eine Funktion will, dass irgendwelcher Input so

00:28:06.624 --> 00:28:11.644
engstirnig interpretiert wird, kann das jetzt halt eben in Typparameter wandern und dann steht

00:28:11.644 --> 00:28:19.924
halt eben das Const auch noch möglicherweise da oben drin. Genau. Ja, ist, sagen wir so, ist, ja.

00:28:21.068 --> 00:28:29.044
Ja finde ich gut also ich habe ich hatte noch keine use cases dafür aber jetzt wo ich es hier

00:28:29.044 --> 00:28:35.884
was das zu fallen use cases sein das ist immer gutes zeichen wenn ich vorher keinen leidensdruck

00:28:35.884 --> 00:28:38.901
hatte und dann plötzlich wird er entwickelt indem ich erstmal was sehe.

00:28:41.179 --> 00:28:46.789
Frage ich mich ob da wirklich ein problem gelöst wird oder sozusagen hier hier hast

00:28:46.789 --> 00:28:51.189
ein problem und die lösung verkaufe ich dir gleich mit also ich sehe das gerade bei diesem

00:28:51.189 --> 00:28:56.869
feature eher so es macht einfach sinn oder es ergibt sinn dass das ding auch in generic

00:28:56.869 --> 00:29:01.589
type parameters landet es ist es macht das typ system meiner meinung stimmig meiner meinung

00:29:01.589 --> 00:29:06.949
noch stimmiger weil warum soll soll nicht die gleichen regeln innerhalb von generischen typ

00:29:06.949 --> 00:29:08.456
wie Brameter gelten wie außerhalb.

00:29:09.437 --> 00:29:14.949
Und deswegen macht es für mich absolut Sinn. Das ist eine ganz, ganz saubere Lösung dafür, dass es,

00:29:15.253 --> 00:29:17.584
dass ein fehlendes Puzzleteil dazu gebracht worden ist.

00:29:17.949 --> 00:29:24.678
Ja, und das macht natürlich auch einen möglichen Verwirrungspunkt für weniger informierte Nutzerinnen und Nutzer weg,

00:29:25.101 --> 00:29:28.459
den du dann ja nicht mehr sagen musst. Schreibt es konstanter, dann funktioniert es.

00:29:29.044 --> 00:29:33.949
Ja. Dass es ja nicht offensichtlich ist und nicht alle haben auf dem Schirm, was das tut.

00:29:33.949 --> 00:29:38.669
Sozusagen die Arbeit verfrachten zu denen, die unter diesen Umständen halt arbeiten wollen,

00:29:38.669 --> 00:29:50.069
also Autoren der Funktion, macht halt insofern schon Sinn. Es macht es halt tatsächlich auch

00:29:50.069 --> 00:29:55.509
relativ, sagen wir mal, macht es halt relativ wortreich. Also so ein Typ Parameter kann ja

00:29:55.509 --> 00:30:00.269
schon sehr wortreich sein. Und wenn ich jetzt hier so sehe, Konst T, Extents Read Only, irgendwas.

00:30:01.236 --> 00:30:06.709
Ich bin da, wie sagt man das, kampfgeprüft, ich schreibe Last. Also was da im generischen

00:30:06.709 --> 00:30:09.680
Umfeld passiert, das ist wild.

00:30:13.488 --> 00:30:21.978
Generic Constraint plus Cent plus Sync plus Tick Static. Und du brauchst eigene Zeile dafür und es gibt Sündtags, dass du das in eigene Zeile packen kannst.

00:30:22.140 --> 00:30:26.298
Also du wirst irgendwann mal.

00:30:27.037 --> 00:30:34.938
Irgendwann freust du dich, wenn du ein einfaches Konstigstens schreiben kannst. Also, ja.

00:30:35.688 --> 00:30:41.138
Kleine Typ-Systeme haben alle für und wieder. Absolut. Ja, ich würde tatsächlich auch sagen, das ist sozusagen,

00:30:41.178 --> 00:30:46.258
auch wenn ich persönlich nicht vom Hocker gehauen werde, weil ich vorher keinen Leidensdruck hatte,

00:30:46.298 --> 00:30:49.641
würde ich zumindest sagen, für die meisten Entwicklerinnen und Entwickler,

00:30:50.098 --> 00:30:52.338
hat das keinen Effekt, und das ist gut so.

00:30:52.378 --> 00:30:57.284
Die meisten werden davon profitieren, ohne das sozusagen im Arbeitsspeicher ihres Hirns haben zu müssen.

00:30:57.658 --> 00:30:58.094
Mhm.

00:30:59.697 --> 00:31:03.778
Das ist was anderes als Decorators, das ist ein Feature, mit dem man sich auseinandersetzen muss.

00:31:03.955 --> 00:31:05.778
Mit hier hast du weniger Notwendigkeit,

00:31:05.778 --> 00:31:15.818
überall es konntest, hinter zu schreiben und das ist ja eigentlich gut. Genau. Cool. Cool. So, das sind

00:31:15.818 --> 00:31:23.178
wohl glaube ich die beiden Flagship-Features aus dieser Release. Ja, ich schaue gerade auch über diese Liste drüber.

00:31:23.178 --> 00:31:32.898
Es gibt, das sind die beiden Flagship-Features, es gibt dann sehr viel Compiler-Fu oder so Projektzeug,

00:31:32.898 --> 00:31:38.178
wo du die Projekte besser konfigurieren kannst und Tooling, wie auch immer,

00:31:38.178 --> 00:31:40.778
also dass du bessere Unterstützung im VS Code und so weiter hast.

00:31:40.778 --> 00:31:43.698
Aber es gibt einen Feature, der ist noch sehr sehr interessant,

00:31:43.698 --> 00:31:48.258
ist eben diese 5.0 Veröffentlichung rechtfertigt meiner Meinung nach.

00:31:49.254 --> 00:31:53.269
Und das sind diese Inums. Und ich glaube, über das möchte ich noch mal ganz kurz reden. Schließ los.

00:31:53.765 --> 00:31:59.384
Also Inums sind ja ein bisschen so, kommt davon, woher du kommst natürlich, aber Inums sind

00:31:59.384 --> 00:32:04.064
ein sehr gern gesehenes Feature, je nachdem, woher du kommst, weil sie erlauben dir, dass

00:32:04.064 --> 00:32:09.344
du mit einer schönen Syntax mehrere Varianten, also mehrere Ausprägungen eines Typs definieren

00:32:09.344 --> 00:32:15.184
kannst. Es gibt Nummern-Inums und String-Inums in TypeScript. Nummern-Inums ist halt wirklich

00:32:15.184 --> 00:32:18.924
Enumeration so im klassischen C-Sinne, wo du jetzt sagst, du startest bei 0 und zählst

00:32:18.924 --> 00:32:23.484
weit hoch und hinter einem sprechenden Namen steckt halt ein Zahlenwert und das kannst

00:32:23.484 --> 00:32:28.464
du verwenden, um diverse Dinge zu lösen. Oder die String-Enam sagt einfach hinter einem.

00:32:29.369 --> 00:32:33.844
Feld oder hinter einem Property oder hinter einer Ausprägung steckt ein Stringwert und

00:32:33.844 --> 00:32:40.063
das kannst du dann so lösen. Das kann man nicht mischen. Und eigentlich schöne Syntax mit,

00:32:40.504 --> 00:32:44.424
Kunst innen, das ist eben das fehlende Kunst, verschwindet das sogar nachher nach dem Typ,

00:32:44.789 --> 00:32:49.424
nach dem Type Check, also nach dem Compile Schritt ist das weg und da hast du eigentlich

00:32:49.424 --> 00:32:55.344
keine Spuren mehr davon. Aber sie kommen mit einigen Einschränkungen mit, bis jetzt. Oder

00:32:55.344 --> 00:33:01.184
sagen wir so nicht mit einigen Einschränkungen, mit einigen eigenen Eigenschaften, genau Eigenheiten,

00:33:01.184 --> 00:33:07.984
die einfach im Sinn vom TypeScript Typ System nicht mehr richtig sind oder herausstechen,

00:33:07.984 --> 00:33:14.064
sagen wir mal so. Punkt Nummer eins bei den Number Enums, sie sind nicht Hypsif. Das ist das,

00:33:14.064 --> 00:33:19.664
was mich einmal total vom Hocker g'haut hat, weil du kannst dort beliebige Zahlen definieren,

00:33:19.664 --> 00:33:24.644
aber du kannst dann, wenn du irgendwo ein Enum als Funktionsparameter erwartest, einfach jede

00:33:24.644 --> 00:33:29.584
x-beliebige Nummer reingeben, weil in der originalen Spezifikation für Enums vorgesehen ist,

00:33:30.251 --> 00:33:35.424
dass du auch mit diesen rechnest. Dass du sagst, du machst jetzt eine Bitmaske und machst Bitvergleich

00:33:35.424 --> 00:33:39.984
zwischen Eintrag A und Eintrag B und da kommt dann eine Zahl aus, die du nicht definiert hast,

00:33:39.984 --> 00:33:43.104
aber die muss genauso gut funktionieren. Okay.

00:33:44.132 --> 00:33:48.462
Spannende Use-Kits hat es sicher mal gegeben, aber der Punkt von TypeScript war,

00:33:48.462 --> 00:33:51.982
damit Sie diesen Use-Kits unterstützen können, lasst mir einfach jede beliebige Zahl zu.

00:33:51.982 --> 00:33:55.313
Das heißt, Number-Inams nicht typsicher.

00:33:55.970 --> 00:34:00.813
Also das eine. Das andere String-Inams, wo jetzt zwischen hinter jedem Wert ein Stringwert steht.

00:34:02.209 --> 00:34:05.612
Das sind die einzigen nominellen Typen in TypeScript.

00:34:05.819 --> 00:34:08.822
Also TypeScript hat aus Druck für Redes Typsystem, das heißt, so wie der Wert gleich ist,

00:34:08.822 --> 00:34:11.622
geht man davon aus, dass auch der Typ gleich ist, das passt.

00:34:11.733 --> 00:34:15.482
Wenn du aber jetzt zum Beispiel in eine String-Innam schreibst,

00:34:15.482 --> 00:34:21.942
die heute zwei Ausprägungen hat, ab, und dann schreibst du eine zweite String-Innam auch mit einer Ausprägung ab,

00:34:21.942 --> 00:34:23.535
dann sind die nicht zueinander kompatibel.

00:34:24.102 --> 00:34:28.730
Und das ist wie gesagt das einzige nominelle Feature in TypeScript.

00:34:29.567 --> 00:34:35.877
Und bricht halt einfach auch mit der Idee vom strukturierten Typ-System.

00:34:36.142 --> 00:34:38.942
Jetzt gibt es Änderungen in den Innams.

00:34:38.942 --> 00:34:45.822
Wir einführen natürlich auch Runtime-Artifakte aus TypeScript und Tux, die jetzt keine ECMAScript-Entsprechung haben,

00:34:45.822 --> 00:34:49.422
was normale Inams ja machen. Die Pulsat sind ja wirklich eine Runtime-Lookup-Table.

00:34:49.597 --> 00:34:52.874
Ist auch nicht mehr in dem Vibe, den TypeScript heutzutage verfolgen möchte.

00:34:53.477 --> 00:34:59.662
Genau. Genau, weil TypeScript ja nur diese dünne Leer an Typinformation ist. Ist ganz richtig.

00:35:00.003 --> 00:35:07.800
Es gibt jetzt ein paar Änderungen. Zum einen, Number-Inams sind jetzt nicht mehr oder können jetzt nicht mehr.

00:35:09.231 --> 00:35:12.342
So breit genutzt werden wie vorhin. Das heißt, wenn du eine NumberInnum hast,

00:35:12.342 --> 00:35:16.782
dann muss auch tatsächlich ein Innam-Wert reingegeben werden. Das ist einmal das eine,

00:35:16.782 --> 00:35:20.422
das passiert. Das ist schon mal richtig, richtig gut. Und das andere, das passiert,

00:35:20.422 --> 00:35:25.542
das auch sehr spannend ist, ist, dass die Einträge einer Innam, egal ob das jetzt NumberInnum oder

00:35:25.542 --> 00:35:32.342
StringInnum ist, jetzt als Einträge eines Union-Types zu werten sind. Das heißt,

00:35:32.556 --> 00:35:37.982
die können jetzt als Typ wiederverwendet werden. Das heißt, es ist ganz easy, dass du noch einen

00:35:37.982 --> 00:35:42.182
Union-Type schreibst, der auf die gleichen Felder zugreift und mit denen noch kompatibel ist.

00:35:42.422 --> 00:35:46.982
Aber ist ein Inam als eine Auflistung von Werten nicht das Gleiche wie eine Union,

00:35:47.319 --> 00:35:49.642
was eine Auflistung von Werten ist? Ja.

00:35:51.244 --> 00:35:53.058
Meine Meinung nach schon. Warum würde ich das dann machen wollen?

00:35:53.058 --> 00:35:59.378
Das verstehe ich nicht ganz. Also die lösen beide das gleiche Problem.

00:35:59.643 --> 00:36:04.018
Eine Union und ein Inam lösen das gleiche Problem. Warum brauche ich denn denn Inams?

00:36:04.018 --> 00:36:04.775
Also für was sind die gut?

00:36:05.027 --> 00:36:08.018
Eigentlich für nichts. Die sind eine Relikt aus alter Zeit.

00:36:08.018 --> 00:36:14.178
Aber die Änderungen, die jetzt dort sind, gleichen sich schrittweise dem Verständnis

00:36:14.178 --> 00:36:15.299
vom Typ-System heute an.

00:36:15.587 --> 00:36:16.865
Das ist das, was ich eigentlich damit sage.

00:36:17.218 --> 00:36:20.618
Und darum finde ich die Änderung gut. Ich würde immer noch keine Inams nehmen.

00:36:20.618 --> 00:36:22.978
Es gibt einen Pattern, das kann ich gerne in die Schau-Notizen packen.

00:36:24.178 --> 00:36:30.818
Das ich ja in meinem Blog beschreibe, wo du mit einem JavaScript-Wert und einem davon abgeleiteten Typen

00:36:31.215 --> 00:36:34.298
das gleiche Verhalten erzeugen kannst, aber du 100 Prozent beim Typ-System bist

00:36:34.298 --> 00:36:38.407
und die gleichen Eigenschaften hast und die gleichen Features hast und die gleichen Typechecks hast.

00:36:38.542 --> 00:36:45.618
Und das Schöne ist jetzt mit dieser Änderung in Inams ist der Unterschied zwischen diesen Dingen nicht mehr so groß.

00:36:46.138 --> 00:36:49.338
Du hast immer nur die nominellen Features und das kann tatsächlich etwas sein,

00:36:49.338 --> 00:36:53.098
wo ich mir denke, okay, das will ich, wenn ich sicherstellen will, dass es einen Unterschied

00:36:53.098 --> 00:36:59.658
gibt zwischen Inam A und Inam B, dann ist die Inam das einzige, mit dem du das machen kannst.

00:37:00.535 --> 00:37:06.738
Aber ansonsten ist die Angleichung zwischen diesen Welten besser. Und wenn du irgendwo

00:37:06.738 --> 00:37:11.538
Inam Union Werte erwartest, dann kannst du auch von einer Inam, die vielleicht schon in deinem

00:37:11.538 --> 00:37:15.258
Code existiert, leichter hingehen. Also der Migrationsschritt ist meiner Meinung nach.

00:37:15.258 --> 00:37:20.498
Und deswegen bin ich happy, dass dieses Feature kommt. In Wirklichkeit hätte ich gern ein

00:37:20.498 --> 00:37:26.098
Feature, das man sagt, disallow Enums im Compiler und sie verschwinden. Das wäre das Allerbeste.

00:37:27.236 --> 00:37:32.338
Aber zudem lassen sie es nicht hin. Weil, meine Meinung nach, werden sie zu stark genutzt.

00:37:32.338 --> 00:37:37.738
Also ich habe Projekte, die ich sehe, wo Enums teilweise den Compiler in die Knie zwingen,

00:37:37.738 --> 00:37:41.978
einfach nur durch deren bloße Existenz. Ach, sind die so aufwendig?

00:37:42.701 --> 00:37:44.458
Ja, wir haben ihn mit 2000 Einträgen.

00:37:46.311 --> 00:37:52.001
Autogeneriert für irgendeinem Code Generator. Aber wäre eine Union mit 2000 Einträgen dann besser?

00:37:52.001 --> 00:37:57.121
Ja, wäre besser wegen der Syntax, weil nicht sofort alle Einträge evaluiert werden müssen,

00:37:57.121 --> 00:38:00.328
sondern nur der Typ Check interessant ist. Aber wenn du eine Inam definierst,

00:38:00.688 --> 00:38:05.639
dann muss die ganze Inam gepasst werden, damit überhaupt mal bekannt ist, was da ist.

00:38:07.223 --> 00:38:10.921
Und weil du ja Syntax zur Verfügung stößt, mit der du das nutzt.

00:38:11.130 --> 00:38:13.993
Und das ist einfach bei 2000 Strings in einer Union ganz was anderes.

00:38:14.209 --> 00:38:17.648
Also da muss ich einfach sagen, hey da ist der Typcheck schon, bin ich dort drinnen.

00:38:17.963 --> 00:38:22.627
Der Ray includes ist halt so schnell wie dein Compiler. Aber das Ganze aufzubereiten, puh, schwierig.

00:38:23.158 --> 00:38:27.443
Meistig aus Erfahrung, hat für irrsinnig viel Diskussion gesorgt in einem Projekt, in dem ich mal wieder da war.

00:38:27.641 --> 00:38:34.851
Okay, finde ich gut. Ich nehme gerne immer weitere Munition gegen Inams zur Hand.

00:38:36.427 --> 00:38:43.431
Damit ich da pro Union argumentieren kann. Nehme ich gerne mit, war mir gar nicht klar, aber ist logisch.

00:38:43.890 --> 00:38:54.323
Kunst ändert auch nichts dran. Das ist nämlich auch witzig. Also die Inam frisst einfach Kompilzeit, egal ob so Kunst Inam ist oder nicht.

00:38:55.242 --> 00:38:59.361
Das ist interessant. Das hätte ich jetzt auch nicht unbedingt erwartet, aber macht ja immer noch irgendwie Sinn,

00:38:59.361 --> 00:39:04.091
auch wenn es halt ein Artifakt macht. Das ist jetzt das einzige, was Kunst Inam tut. Ich kenne ihn auch.

00:39:07.359 --> 00:39:11.446
Das sind meine Two-Sense dazu. Also ich bin froh, dass das Ding existiert.

00:39:11.609 --> 00:39:17.297
Also diese Annäherung existiert. Es macht sicher einige Dinge einfacher und es sorgt nicht mehr für so viele Verwirrungen.

00:39:17.387 --> 00:39:22.849
Also das war eigentlich das größte Problem, wo du gehst halt dann innerhalb deiner Inam

00:39:22.849 --> 00:39:26.649
aus, wenn du zum Beispiel das Which-Case-Statement machst bei einer Number-Inam, dann musst

00:39:26.649 --> 00:39:30.849
du jeden Case betreuen und dann hast du halt bei einer Inam mit drei Einträgen, hast

00:39:30.849 --> 00:39:35.609
du halt nur drei Cases und das Problem ist aber, dass von oben viel, viel mehr reinkommen kann.

00:39:35.609 --> 00:39:40.169
Bitter, dass du diese Typ-Sicherheit nicht hast. Ja. Weil das willst du ja von TypeScript,

00:39:40.169 --> 00:39:44.849
zu dem existiert es. Und das kann ich dir nicht bitten und das ist halt traurig.

00:39:45.285 --> 00:39:50.489
Ja gut, okay. Dann wärme ich mich so langsam gegenüber dem Feature auf. Ich meine, das löst

00:39:50.489 --> 00:39:54.129
immer noch ein Problem, das am besten Fall gar nicht da ist, aber das kann man sich ja nicht

00:39:54.129 --> 00:39:57.049
ausprobieren. Aber hey, du weißt, du kennst die Ursprünge von TypeScript, das war jetzt sehr

00:39:57.049 --> 00:40:00.769
stark angelehnt. Ein Objekt orientierte Programmiersprachen, wie es hier schafft.

00:40:00.769 --> 00:40:02.768
Wunsch für Java-Entwickler, die jetzt Web machen müssen.

00:40:03.074 --> 00:40:11.489
Ja, genau. Und ich meine, wer hat's denn geschrieben? Das war irgendwie vorherzusehen und das ist ja

00:40:11.489 --> 00:40:18.369
jetzt nicht das Problem, sage ich jetzt mal. Und das Problem ist, wirst du auf lange Sicht damit

00:40:18.369 --> 00:40:23.369
umgehen und da hat es ja schon viele, viele Annäherungen gegeben. Namespaces haben nimmer

00:40:23.369 --> 00:40:27.689
die Wertigkeit wie vorher, Modules haben nimmer die Wertigkeit wie vorher, da gibt es jetzt einfach

00:40:27.689 --> 00:40:31.129
die ECMAScript Modules, die Triple Slash Directives haben nicht mehr die Wertigkeit wie

00:40:31.129 --> 00:40:35.289
vorher und jetzt endlich haben Inams auch nicht mehr die Wertigkeit wie vorher. Es ist eine weitere

00:40:35.289 --> 00:40:41.249
Annäherung und das ist immer das Beste, um über kurz oder lang wegzukommen davon und deswegen ist

00:40:41.249 --> 00:40:47.369
gut, dass es jetzt per Default in 5.0, sind es vorhin von Inams ändert, weil noch jeder und

00:40:47.369 --> 00:40:53.689
jede hoffentlich merkt, dass der Einsatz einer Inam es wahrscheinlich nicht wert ist. Also notwendige

00:40:53.689 --> 00:40:57.509
Vorarbeit für möglicherweise eines Tages wirklich das Compiler-Flag.

00:40:57.509 --> 00:40:59.709
Genau, das wäre meine Hoffnung.

00:41:02.282 --> 00:41:08.932
Gut, die restlichen Features, so irgendwie JS-Doc und so Zeug, haut mich jetzt auch nicht vom Hocker,

00:41:08.932 --> 00:41:09.932
irgendwie exportiert.

00:41:09.932 --> 00:41:14.129
Na, in guter Style, danke schön. Vielleicht mal verwenden, irgendwie so Multi-Extension-Config-Files,

00:41:14.309 --> 00:41:16.132
ist ja auch nur, was man sowieso haben möchte.

00:41:16.132 --> 00:41:23.132
Ja, mit dem Release von dieser Revision, also wenn ihr das hört,

00:41:23.132 --> 00:41:25.580
sollte das TypeScript 5.0 veröffentlicht sein.

00:41:26.291 --> 00:41:30.632
Falls ihr es anders seht, falls ihr große Inams-Fans seid, lasst es uns wissen.

00:41:30.632 --> 00:41:34.152
Verfolgt uns auf Twitter und wenn es das noch gibt zu dem Zeitpunkt, wir nehmen das

00:41:34.152 --> 00:41:38.512
deutlich vor der Veröffentlichung aus, also wer weiß was sich der Elmo bis dahin

00:41:38.512 --> 00:41:44.992
noch ausdenkt. Ansonsten gibt es uns ja auch noch auf Mastodon und unseren Slack-Channel Community Draft gibt es noch. Also lasst uns wissen,

00:41:44.992 --> 00:41:49.312
überzeugt uns davon, dass Inams voll gut sind und wir komplett falsch liegen.

00:41:49.312 --> 00:41:51.875
Ich wäre sehr interessiert an diesbezüglichem Input.

00:41:54.711 --> 00:41:59.716
Stefan, es war mir wieder ein großes großes Vergnügen. Ja, es war ein Volksfest.

00:42:00.184 --> 00:42:06.612
Danke fürs Zuhören. Wir sehen uns dann in dieser Konstellation nächstes Quartal wieder, wenn es dann um TypeScript 5.1 geht.

00:42:06.918 --> 00:42:09.754
Bis dahin, danke fürs Zuhören und Tschüssi.

00:42:10.105 --> 00:42:10.735
Ciao!

00:42:29.343 --> 00:42:38.872
Das passt. Also ich hab so ein fancy neues Mikro. Und das steht jetzt auf so einem Stand und da muss ich immer ganz nahe hingehen, damit man mich auch anständig versteht.

00:42:39.191 --> 00:42:43.188
Und ich hoffe das passt. Und die darf nicht so am Sessel hin und her rutschen.

00:42:43.521 --> 00:42:47.464
Ach so, ein bisschen Rassel und Ambience und so Knarz kommt da schon rüber.

00:42:47.806 --> 00:42:49.400
Okay. Das ist wahrscheinlich das Bewegen.

00:42:50.129 --> 00:42:53.991
Das ist wahrscheinlich... also ich habe jetzt gerade auch das Mikrofon gestreichelt, weil ich Staub entfernt habe.

00:42:54.036 --> 00:42:58.032
Das ist natürlich auch Knarz. Das muss ja sein. Das wäre dann das hier.

00:42:58.456 --> 00:43:02.432
Ja, genau. Man muss das Mikrofon ja streicheln, damit es hinterher schön zart wird.

00:43:02.669 --> 00:43:06.512
Genau, ganz genau. Ich streichle jetzt nicht mehr, es ist genug gestreichelt.

00:43:06.828 --> 00:43:08.098
Gut.

00:43:08.862 --> 00:43:13.792
Jetzt sind drei Minuten drin und schon eine ganze Outtake Sendung geschafft.

00:43:13.792 --> 00:43:17.752
Ich glaube, so viel haben wir jetzt ja gar nicht mit aufgezeichnet.

00:43:17.752 --> 00:43:23.512
Außerdem, was erwartest du auch, wenn hier die beiden Clowns vom Dienst in der Sendung sind?

00:43:24.599 --> 00:43:28.352
Ah ja. Verdammt. Ja, es ist cool, dass ich wieder mal dabei bin.

00:43:28.352 --> 00:43:35.512
Ich bin eh so komplett weg eigentlich davon, weil Kinder und alles und alles eigentlich.

00:43:35.512 --> 00:43:40.560
Das ist jedes Problem. Ja, ich war ja auch weg, aber...

00:43:41.748 --> 00:43:48.238
Irgendwann haben dann die Katastrophen aufgehört sich sozusagen aufzutürmen und nachdem dann sozusagen

00:43:48.635 --> 00:43:51.713
genug davon abgetragen war, dass man auch mal wieder was anders machen konnte,

00:43:51.918 --> 00:43:55.089
geht auch mal wieder was in Richtung Podcast.

00:43:55.467 --> 00:43:57.736
Ich hab keine Ahnung wann dieser Zeitpunkt bei mir sein wird.

00:43:57.799 --> 00:44:01.998
Vor allem diese regulären Mietungen. So auswärtig wie das geht, das passt.

00:44:01.998 --> 00:44:11.050
Aber ich sehe bei meinen Kindern keine Chance, dass die Abendrituale sich zu meinen Gunsten in den nächsten Jahren verändern werden.

00:44:11.374 --> 00:44:14.597
Ja und das muss ich heute mal fressen.

00:44:15.200 --> 00:44:22.060
Ja ich mein man könnte ja hin und wieder auch mal bei äh also zur Diskussion stellen, ob vielleicht ein anderer Zeitslot, ein anderes Aufnahmeregime vielleicht...

00:44:22.591 --> 00:44:26.849
Ja aber da bin ich tatsächlich auch, sag mal, der weakest link und das ist okay.

00:44: