WEBVTT

00:00:00.017 --> 00:00:04.357
Ich habe ja die heretische Position eingenommen, dass nicht zwingend jedes Webprojekt

00:00:04.357 --> 00:00:07.057
mit React gemacht sein muss. Kannst du mir dieses Wort kurz erklären?

00:00:07.577 --> 00:00:12.637
Die vom Glauben abgefallenen, die man irgendwie ans Kreuz oder ähnliche Dinger

00:00:12.637 --> 00:00:16.137
befestigen sollte. Die philosophische Frage dahinter ist, wer ist denn jetzt

00:00:16.137 --> 00:00:17.277
vom Glauben abgefallen?

00:00:18.677 --> 00:00:20.557
Ich kann mich hier um die eigentlich wichtigen Dinge kümmern.

00:00:20.957 --> 00:00:24.897
Der Kiki seufzt schon die ganze Zeit. Ich glaube, ihm liegt echt was am Herzen gerade.

00:00:25.777 --> 00:00:29.477
Ich muss ja dazu sagen, dass ich eventuell in dieser Liste der Themen vorhin

00:00:29.477 --> 00:00:32.857
explizit das Thema Type Assertions aufgenommen habe. Ich finde schön,

00:00:32.957 --> 00:00:34.037
dass wir außerdem hingekommen sind.

00:00:46.967 --> 00:00:50.187
Euro in den Hut werfen. Aus euren Beiträgen und den gelegentlichen Werbeblöcken

00:00:50.187 --> 00:00:53.667
bezahlen wir Domains, Server, diverse Software-Abos und natürlich das Honorar

00:00:53.667 --> 00:00:55.187
unserer Audio-Producerin.

00:00:55.507 --> 00:00:57.547
Danke euch allen für eure treue Unterstützung.

00:01:02.387 --> 00:01:08.567
Revision 694. Hallihallo Hallöle und herzlich willkommen zu Working Draft Revision 694.

00:01:08.887 --> 00:01:11.367
Heute sind am Start der Stefan.

00:01:11.967 --> 00:01:16.247
Hallo Servus. Keine Sorge, wir haben auch einen Gast, nämlich den Kiki. Moin, Kiki.

00:01:16.767 --> 00:01:19.627
Moin. Und meine Wenigkeit, der Peter.

00:01:19.987 --> 00:01:23.247
Und weil wir einen Gast haben, wissen wir, es ist nicht das übliche,

00:01:23.467 --> 00:01:26.007
die gleichen zwei alten Männer drehen um immer das gleiche Thema,

00:01:26.227 --> 00:01:29.387
sondern drei alte Männer drehen um immer das gleiche Thema.

00:01:31.487 --> 00:01:37.187
Keine Sorge, jetzt ist TypeScript Plus. Plus React, TypeScript und React.

00:01:37.367 --> 00:01:38.827
Minus mal Minus ergibt bekanntlich Plus.

00:01:39.127 --> 00:01:44.767
Und unter dieser Prämisse dachten wir, machen wir hier einfach mal so ein Mikro-Glücksrad.

00:01:45.327 --> 00:01:50.407
Es gibt ja leider keine React-Spezifikation und von TypeScript gibt es ja auch keine.

00:01:50.667 --> 00:01:53.467
Also habe ich buchstäblich die letzten 20 Minuten damit verbracht,

00:01:53.567 --> 00:01:57.387
Google zu fragen, gib mal Liste von React-Features, gib mal irgendwie so Liste

00:01:57.387 --> 00:02:00.607
von TypeScript-Features und habe die hier in so einen Google-Doc reingehauen.

00:02:00.887 --> 00:02:06.047
Und wir losen jetzt einfach hier eine Zahl aus und schauen einfach mal,

00:02:06.567 --> 00:02:08.407
was wir da so als Stichwortgeber nehmen.

00:02:09.807 --> 00:02:14.847
Ich würde sagen, das machen wir. Stimmt's? So, wie kriege ich jetzt eine Zufallszahl

00:02:14.847 --> 00:02:16.487
hin? Ich schätze mal, ich frage einfach Google, oder?

00:02:17.487 --> 00:02:21.927
Number between. Du kannst einfach Chat-TVD fragen. Ich kriege das aber tatsächlich

00:02:21.927 --> 00:02:26.347
auch raus, ohne drei Seen auszutrinken. Pass auf, hold my beer.

00:02:28.007 --> 00:02:31.547
Zahlen kann der ja nicht so gut. Wie viele Entry haben wir dann?

00:02:32.767 --> 00:02:36.267
76. Pass auf, pass auf. Ich habe eingegeben, number between.

00:02:36.907 --> 00:02:40.767
Und dann sagt mir die KI-Übersicht, dieses brillante Tool.

00:02:41.867 --> 00:02:47.967
Eine Nummer zwischen 1 und 76 könnte theoretisch jede Zahl zwischen 2 und 75 sein.

00:02:49.182 --> 00:02:52.802
Das ist wahr. Das ist streng genommen nicht verkehrt.

00:02:53.182 --> 00:02:55.902
Andererseits verstehe ich auch nicht, wie man die Frage, die ich jetzt hier

00:02:55.902 --> 00:02:59.762
in die Suchbox gestellt habe, so interpretieren kann, dass ich erklärt bekommen

00:02:59.762 --> 00:03:04.822
muss, was das Konzept von so einem Intervall ist. Ich weiß es nicht.

00:03:05.262 --> 00:03:07.742
Aber es gibt numberrandomgenerator.org. Nehmen wir doch den.

00:03:07.782 --> 00:03:12.122
Also während du das jetzt gemacht hast, habe ich im Terminal den Node-Reppel

00:03:12.122 --> 00:03:17.162
aufgerufen, habe mathrandom mal 76 plus 1 eingegeben und wir sind bei 16.

00:03:18.342 --> 00:03:22.482
Okay, zufälligerweise sind wir jetzt bei 16. Wunderbar, das ist doch exakt das,

00:03:22.542 --> 00:03:24.442
was mein Zufallszahlen-Generator ausgespuckt hat.

00:03:24.802 --> 00:03:28.722
Also müssen wir jetzt über 16 reden. Ah, das ist super.

00:03:29.302 --> 00:03:33.722
Das ist ein React-Hook, von dem ich tatsächlich heute zum ersten Mal was erfahren habe.

00:03:34.022 --> 00:03:37.622
Ich mache das ja schon länger nicht mehr, außer wenn ich halt irgendwie exorbitant gut bezahlt werde.

00:03:39.022 --> 00:03:42.042
UseDebugValue. Was ist denn das? Weiß das jemand? Ja.

00:03:43.205 --> 00:03:50.785
Ja, der ist schon bei mir vorbeigeflattert, aber ich habe ihn tatsächlich noch nie aktiv verwendet.

00:03:52.705 --> 00:03:56.185
Für mich war er zu spät da, glaube ich, wenn ich mich nicht vertue.

00:03:56.285 --> 00:03:58.785
Oder ich habe ihn damals sicher geguckt bekommen. Ich wollte den mal haben und

00:03:58.785 --> 00:04:01.125
bin dann irgendwann, wie viele Jahre später, darüber gestolpert.

00:04:01.245 --> 00:04:05.265
Also Grundidee, wenn ich mich nicht vertue, ist, React hat ja diese wunderschönen DevTools.

00:04:06.045 --> 00:04:09.005
Komplett unterbewertetes Feature, sollten viel mehr Technologien mit sich bringen,

00:04:09.125 --> 00:04:12.225
damit man nicht immer nur die Chrome DevTools aufmacht und den großen AI-Button sieht.

00:04:13.205 --> 00:04:16.565
Und man kann damit in eigenen Komponenten oder nur eigenen Hooks,

00:04:16.585 --> 00:04:20.485
bin ich mir nicht sicher, Informationen in diesen Dev-Tools rendern.

00:04:21.265 --> 00:04:24.605
Wenn ich mich nicht vertue, nur Strings, das finde ich wiederum so ein bisschen schade.

00:04:24.725 --> 00:04:27.665
Ich fände es total geil, wenn ich da ein kleines Panel reinrendern könnte und

00:04:27.665 --> 00:04:31.405
tolle Features machen. Also wenn ich da eine React-Komponente am besten übergeben könnte.

00:04:32.085 --> 00:04:33.985
Aber ich glaube, das ist so die Grundidee, oder?

00:04:35.145 --> 00:04:38.485
Tatsächlich ist es genau das. Also du kriegst dann in den React-Dev-Tools,

00:04:39.705 --> 00:04:49.825
Also wenn du auf eine Komponente klickst, im Hooks-Pendel genau diese Information angezeigt.

00:04:54.085 --> 00:04:59.485
Und zwar der Name des Hooks, den du schreibst, mit der String-Information, die du angeben willst.

00:05:01.065 --> 00:05:06.485
Okay, das ist also ein fancy Konsole-Log-Statement. Ja, also wenn du direkt auf die Dev-Tools raus.

00:05:09.925 --> 00:05:13.045
Entschuldigung, aber wenn ich Konsole-Log mache, dann gehe ich auch in die Dev-Tools.

00:05:13.145 --> 00:05:16.325
Ich gehe in ein anderes Panel, aber an sich ist es das doch, oder?

00:05:16.945 --> 00:05:20.305
Ja, natürlich, aber du hast halt, wenn du in dem Konsole-Log drinnen bist,

00:05:20.505 --> 00:05:22.705
hast du halt nicht die Zugehörigkeit zur Komponente.

00:05:22.785 --> 00:05:25.625
Da ist ja dann der Konsole-Log wieder ein bisschen umfangreicher.

00:05:25.865 --> 00:05:30.645
Aber ja, also es ist Convenience-Function für die React-Dev-Tools.

00:05:31.065 --> 00:05:34.425
Ja, für die React DevTools. Ich meine halt nur, du hast durchaus den Kontext

00:05:34.425 --> 00:05:36.845
von der Komponente, wenn deine Komponente keine React-Komponente ist.

00:05:36.925 --> 00:05:39.665
Wenn das irgendwie ein Diff ist oder so, kannst du das Ding ja mit reinschreiben

00:05:39.665 --> 00:05:43.565
in einem Konsole-Log und dann kannst du ja aus der Konsole das Ding inspizieren.

00:05:44.065 --> 00:05:46.845
Also, ganz so magisch ist es ja nicht.

00:05:47.485 --> 00:05:51.525
Also könnte man schon machen, aber ich finde halt schon so, diese Zuordnung

00:05:51.525 --> 00:05:55.705
im Komponentenbaum ist halt schon ein Benefit, also wenn du Komponente 30 Mal

00:05:55.705 --> 00:05:58.825
auf der Seite verwendet hast, dass du dann schnell rausfinden kannst, welche davon ist es.

00:05:59.265 --> 00:06:02.705
Und natürlich hast du recht, dass man da auch das DOM-Element irgendwie in der

00:06:02.705 --> 00:06:04.705
Konsole ausgeben müsste, könnte, Entschuldigung.

00:06:05.285 --> 00:06:10.125
Dafür müsstest du aber gefühlt erstmal eine Rev verwenden, um dieses Element zu bekommen.

00:06:10.465 --> 00:06:13.905
Und eventuell ist die Komponente noch gar nicht gerendert und dann ist das Element

00:06:13.905 --> 00:06:16.865
noch nicht da und das geht überhaupt nicht und um den DevTools geht's.

00:06:17.305 --> 00:06:21.145
Jaja, du musst halt nur verstehen, ich habe ja die heretische Position eingenommen,

00:06:21.365 --> 00:06:24.445
dass nicht zwingend jedes Webprojekt mit React gemacht sein muss.

00:06:24.585 --> 00:06:25.905
Kannst du mir dieses Wort kurz erklären?

00:06:27.145 --> 00:06:32.445
Heretiker? Ja. Die vom Glauben abgefallenen, die man irgendwie ans Kreuz oder

00:06:32.445 --> 00:06:37.045
ähnliche Dinger befestigen sollte. Die philosophische Frage dahinter ist,

00:06:37.045 --> 00:06:38.905
wer ist denn jetzt vom Glauben abgefallen?

00:06:40.645 --> 00:06:41.625
Ach, weißt du.

00:06:43.385 --> 00:06:46.885
Eine Browser-Extension zu bauen um irgendwie besseres Debugging zu machen,

00:06:47.425 --> 00:06:51.105
sobald du es gemacht hast und nicht gerade im Prozess des Browser-Extension-Bauens

00:06:51.105 --> 00:06:52.585
bist, ist halt schon cool.

00:06:54.395 --> 00:06:58.675
Das kann schon wirklich sehr viel Wert erschaffen. Es ist halt nur ein absolut

00:06:58.675 --> 00:07:01.675
unerträglicher Prozess, das halt

00:07:01.675 --> 00:07:04.535
zu machen, also in der Umsetzung der Browser-Extension zu programmieren.

00:07:04.655 --> 00:07:07.395
Das ist eine Strafe. Aber wenn es fertig ist und funktioniert, ist cool.

00:07:08.395 --> 00:07:10.095
Das stimmt schon. Da stimme ich dir zu.

00:07:11.215 --> 00:07:16.395
Ich möchte aber jetzt auf die Revision zurückweisen, die wir zu dritt schon

00:07:16.395 --> 00:07:19.815
mal gemacht haben, die 689, wo wir ja auch darüber gesprochen haben,

00:07:20.615 --> 00:07:24.215
dass wir uns in React immer in einer Parallelwelt befinden.

00:07:24.655 --> 00:07:30.115
Das heißt, wir haben ja sämtliche Dinge entweder nochmal oder anders oder parallel

00:07:30.115 --> 00:07:32.495
zu denen, die tatsächlich im Browser existieren.

00:07:32.615 --> 00:07:36.195
Es gibt ein synthetisches Event-System, es gibt einen virtuellen DOM.

00:07:36.935 --> 00:07:41.355
Und deswegen brauchst du wahrscheinlich auch ein anderes Console-Log,

00:07:41.575 --> 00:07:44.375
um die Information richtig anzuzeigen oder zugehörig anzuzeigen.

00:07:44.555 --> 00:07:49.475
Also alle Dinge, die du sagst, Peter, die passen, wenn ich nicht in diese Parallelwelt eintauche.

00:07:49.655 --> 00:07:53.575
Aber jetzt, wo ich im Upside-Down bin, das kleine Popkultur-Referenz,

00:07:54.655 --> 00:07:59.515
wer es nicht mitgekriegt hat, vielleicht brauche ich dann genau das und darum finde ich es gut.

00:07:59.715 --> 00:08:02.235
Also genauso, wie der Kiker das gesagt hat, hey, cool, DevTools gibt es dafür,

00:08:02.515 --> 00:08:05.575
das passt. Und wenn ich dann als Entwickler oder Entwicklerin die Möglichkeit

00:08:05.575 --> 00:08:07.575
habe, dass ich oder eingreifen kann, finde ich es auch gut.

00:08:08.315 --> 00:08:11.655
Ich würde jetzt noch eine Frage an der Stelle Richtung Peter mal werfen,

00:08:11.735 --> 00:08:15.555
weil ich bin ja nur in der richtigen Welt, also da, wo es React und dergleichen

00:08:15.555 --> 00:08:19.555
gibt und nicht so bei Web-Components und den ganzen Zukunftstechnologien.

00:08:21.435 --> 00:08:26.815
Schön. Wenn ich eine Web-Component entwickle und die 30 Mal auf meiner Seite

00:08:26.815 --> 00:08:31.695
einbinde und ich ein Console-Log einbaue,

00:08:32.895 --> 00:08:39.275
was ausgeführt wird, bevor die DOM-Elemente erzeugt werden, weil ich möchte,

00:08:39.655 --> 00:08:43.395
du kannst mir gleich sagen, das geht nicht, weil ich irgendwie möchte, rausfinden möchte,

00:08:44.675 --> 00:08:47.235
warum liegt das Ding mir um die Ohren, warum rendert es gar nicht, was auch immer.

00:08:49.228 --> 00:08:53.868
Wie kann ich rausfinden, welche Verwendung auf der Seite das verursacht?

00:08:53.948 --> 00:08:55.088
Kann ich das herausfinden?

00:08:55.628 --> 00:08:58.908
Ich habe immer das DOM-Element, in dem ich die Web-Component einbinde.

00:09:00.768 --> 00:09:03.868
Pass auf, pass auf. Ich komme auf dein Angebot zurück, zu sagen, das geht nicht.

00:09:05.508 --> 00:09:07.228
Weil die Web-Component ist das

00:09:07.228 --> 00:09:12.068
DOM-Element. Es gibt halt keinen virtuellen Rapper um das Ding drumherum.

00:09:13.528 --> 00:09:18.268
Es herrscht halt eine 1-zu-1-Identität zwischen deiner Web-Component und dem

00:09:18.268 --> 00:09:20.668
Ding, das du renderst. Das Ding, das du erinnerst, ist die Komponente.

00:09:20.808 --> 00:09:25.148
Es gibt halt nicht mehr dieses darüber geordnete Konstrukt der React-Komponente zum Beispiel.

00:09:26.208 --> 00:09:29.588
Ich könnte jetzt widersprechen und dann in die Detaildiskussion einsteigen,

00:09:29.628 --> 00:09:31.428
aber das hilft nicht. Insofern würde ich das weglassen.

00:09:31.728 --> 00:09:33.968
Ich bin mir ziemlich sicher, dass du nicht widersprechen könntest.

00:09:33.968 --> 00:09:37.608
Also du kannst es versuchen, aber...

00:09:38.788 --> 00:09:41.188
Ich habe ja keine Ahnung davon. Ich glaube, es ist nicht hilfreich.

00:09:42.708 --> 00:09:46.148
Das Ding ist halt wie so ein Diff. Von dem Diff gibt es halt auch nur so der

00:09:46.148 --> 00:09:49.008
Diff an sich. Und da gibt es halt keinen Zinnober drumherum.

00:09:49.228 --> 00:09:51.748
Und eine Web-Component ist nichts weiter als ein Fancy-Diff,

00:09:51.828 --> 00:09:53.308
das du dir selber zusammengestrickt hast.

00:09:53.988 --> 00:09:59.468
Und alles, was halt für ein Diff gilt, gilt halt genauso für den Fancy-Kiki-Renderer 2000.

00:10:02.048 --> 00:10:05.988
Wenn wir von Web-Component reden, reden wir eigentlich von, nicht eigentlich,

00:10:06.128 --> 00:10:10.428
sondern geht es immer um dieses Custom-Elements-Gedöns, was wir erzeugen. Richtig.

00:10:10.928 --> 00:10:15.108
Das ist meines Erachtens der Sprachgebrauch. Die API kann eine andere sein,

00:10:15.188 --> 00:10:17.848
weil man kann da irgendwie Abstraktionen drumherum bauen, wenn man sehr gerne

00:10:17.848 --> 00:10:20.748
NPM bedient, aber man kann es auch nackt machen, wenn man auf Schmerzen steht.

00:10:20.848 --> 00:10:21.728
Man kann es so oder so machen.

00:10:22.228 --> 00:10:27.748
Wenn ich jetzt ein Custom Element aufrufe, was es nicht gibt, was passiert dann so?

00:10:28.868 --> 00:10:32.768
Aufrufe verwende. Du postulierst einfach, es gäbe ein Kiki-Renderer 2000,

00:10:32.888 --> 00:10:34.208
ohne irgendwelchen Code dafür zu schreiben.

00:10:34.468 --> 00:10:37.228
Kannst du bitte aufhören, Begriffe zu verwenden, wo ich die ganze Zeit nachfragen

00:10:37.228 --> 00:10:38.268
musste? Ich postuliere.

00:10:38.808 --> 00:10:41.748
Du benutzt einfach einen HTML-Tag, den es nicht gibt. Ja, genau. Was passiert dann?

00:10:42.488 --> 00:10:45.848
Browser sagt, habe ich noch nie gesehen. Ich mache dann HTML-Unknown-Element

00:10:45.848 --> 00:10:48.968
drauf. Graus, das hat ungefähr den Feature-Umfang von einem Span.

00:10:51.245 --> 00:10:54.585
Man kennt das ja vom Browser. Du gibst dem was, was er nicht kennt.

00:10:54.785 --> 00:10:58.005
Wenn das so in HTML drin ist, unbekanntes Attribut, unbekanntes Element,

00:10:58.445 --> 00:11:00.045
kennt man ja auch irgendwie von Tippfehlern her.

00:11:00.265 --> 00:11:02.785
Ich habe mal irgendwie H7 geschrieben versehentlich oder sowas.

00:11:03.085 --> 00:11:05.625
Dann macht er halt eben einfach weiter und sagt so, ich tue mal so,

00:11:05.685 --> 00:11:06.985
als wäre es ein Span und habe das nicht gesehen.

00:11:07.225 --> 00:11:10.325
Und wenn ich der Fall fest überzeugt bin, ich habe jetzt gerade meine Web Component

00:11:10.325 --> 00:11:14.005
H7 geschrieben, aber irgendwie wird der Code nicht aufgerufen, wie debugge ich das?

00:11:15.525 --> 00:11:18.985
Da kannst du ganz einfach nachgucken ob das Ding in der Custom Element Registry

00:11:18.985 --> 00:11:23.085
drin ist das ist einfach ein Objekt ist es ja offensichtlich nicht sonst würde

00:11:23.085 --> 00:11:25.665
es ja da eingebunden werden wie.

00:11:29.945 --> 00:11:31.905
Ich drifte in eine komplett andere Richtung ab,

00:11:35.065 --> 00:11:38.365
die Ursache dafür kann halt nur sein dass du das nicht in die Registry reinsteckst

00:11:38.365 --> 00:11:41.525
also guckst du halt eben wo werden Sachen in die Registry reingesteckt und warum

00:11:41.525 --> 00:11:44.285
passiert das mit meinem Kollegen halt nicht Wahrscheinlich, weil irgendwie ein

00:11:44.285 --> 00:11:46.665
Modul nicht geladen wurde, solcherlei Kisten.

00:11:47.585 --> 00:11:51.365
Aber das ist alles super basic, ne? Das kann mir durchaus einfach passieren.

00:11:51.445 --> 00:11:54.365
Also gibt es keine Typsicherheit, keine startische Code-Analyse,

00:11:54.485 --> 00:11:58.245
die irgendwie sowas überprüft, dass ich da nur Web-Components aufrufe,

00:11:58.445 --> 00:12:00.205
für die ich auch ein Custom-Element registriert habe?

00:12:00.985 --> 00:12:06.445
Gibt es jetzt nicht. Ich wäre es relativ trivial zu machen, weil es gibt da

00:12:06.445 --> 00:12:08.945
eine CSS-Pseudo-Klasse.

00:12:09.365 --> 00:12:12.145
Das ist ja keine startische Code-Analyse mehr. Das ist dann ja...

00:12:13.145 --> 00:12:16.545
Nee, nee, das halt nicht. Statische Grundanalyse geht ja eh nicht,

00:12:16.625 --> 00:12:21.125
weil die Idee ist ja, du operierst ja auf der nackten Ebene der Webplattform

00:12:21.125 --> 00:12:25.265
selber und da müsste man ja tatsächlich berücksichtigen, sämtliches JavaScript,

00:12:25.505 --> 00:12:27.165
sämtliches TypeScript, sämtliches HTML,

00:12:28.225 --> 00:12:30.825
und was du sonst noch so an lustigen Nebenwirkungen da drin hast,

00:12:30.885 --> 00:12:35.345
du könntest ja in deinem HTML ein Skript drin haben mit einem Eval-String,

00:12:35.485 --> 00:12:38.965
der ein Modul lädt, wo dann die Web-Component sich drin manifestiert und das

00:12:38.965 --> 00:12:41.605
ist halt eben nicht so generalisiert statisch lösbar.

00:12:41.745 --> 00:12:45.385
Was ich halt machen würde, ist, es gibt die CSS-Pseudoklasse Defined.

00:12:45.505 --> 00:12:48.705
Die trifft halt zu auf Elemente, die definiert und bekannt sind.

00:12:48.905 --> 00:12:52.545
Und man kann sich ja ganz einfach mit Notch Defined irgendwas basteln,

00:12:52.625 --> 00:12:55.785
was Alarm schlägt, sobald irgendein Element darauf matcht.

00:12:57.648 --> 00:13:03.168
Ja, ich finde das schade. Habe ich nicht kommen sehen, aber wir sind ja gar

00:13:03.168 --> 00:13:05.028
nicht in der Web Components vs. React Folge.

00:13:05.188 --> 00:13:08.248
Die gab es ja schon, oder? Ich weiß nicht, ob es die schon in der Form gab.

00:13:08.608 --> 00:13:11.148
Außerdem muss ich das ja nicht auslesen. Du kannst ein Web Component bauen und

00:13:11.148 --> 00:13:13.848
du kannst ja irgendwie mit Preact oder mit React zum Beispiel,

00:13:13.928 --> 00:13:17.088
wenn du zu viele Kilobytes zu verschleudern hast, kannst du ja das Innenleben

00:13:17.088 --> 00:13:18.168
mitgestalten. Ist ja kein Problem.

00:13:19.108 --> 00:13:24.228
Ach, kurzer Einwurf. Wir sind immer in der Web Components vs.

00:13:24.368 --> 00:13:26.408
React Episode. Ach so, okay.

00:13:26.988 --> 00:13:30.028
Also wenn ich dabei bin, jedenfalls. Ja, okay.

00:13:31.448 --> 00:13:34.168
Also wenn du Components haben willst und du willst sowas mit Schattesanalyse

00:13:34.168 --> 00:13:36.788
haben, dann musst du halt eben einfach einen Überbau konstruieren,

00:13:36.948 --> 00:13:42.788
der React gleich halt eben sagt, ich bin halt nur durch zum Beispiel TypeScript steuerbar.

00:13:42.968 --> 00:13:45.688
Und dann kannst du halt eben sagen, innerhalb dieses Realitätstunnels,

00:13:45.788 --> 00:13:48.208
den du da konstruiert hast, kann ich Schattesanalyse machen.

00:13:48.408 --> 00:13:53.068
Aber so in der Naturversion, wo halt irgendwie alles kann und nichts muss,

00:13:53.488 --> 00:13:55.308
da kannst du halt eben auch keine Schattesanalyse draufbauen,

00:13:55.308 --> 00:13:59.048
weil du halt eben nicht notwendigerweise statisch analysierbares Material hast.

00:14:01.308 --> 00:14:05.848
Ja, danke. Wieder was über Web-Components gelernt. Ich habe jetzt Type-Safe-Web-Components

00:14:05.848 --> 00:14:07.948
in Google eingegeben und seitdem geht es mir deutlich schlechter.

00:14:07.988 --> 00:14:11.628
Deswegen würde ich einfach wieder zu Usd-Mark-Mail zurückkehren wollen.

00:14:11.668 --> 00:14:13.468
Das ist, als würdest du sagen, Type-Safe-HTML.

00:14:13.568 --> 00:14:17.048
Das funktioniert halt eben nicht. Das ist irgendwie... Aber also...

00:14:19.482 --> 00:14:22.982
Ich dachte, wir sind aus dem Zeitalter raus, wo wir einmal...

00:14:22.982 --> 00:14:25.202
Wie hieß denn dieser Check? Der hieß nicht Self-HTML?

00:14:25.722 --> 00:14:29.502
Das war die Doku. Wie hieß dieser Validator, den wir alle immer benutzt haben?

00:14:29.742 --> 00:14:34.522
Der ganz normale HTML-Validator? Der hatte doch so einen Namen vor 15 Jahren, nicht?

00:14:35.762 --> 00:14:39.062
Der W3C-Validator. Ist ja wirklich einfach nur so. Das ist ja langweilig.

00:14:41.202 --> 00:14:45.402
Aber ich meine, den gibt es auch noch, nicht nur vor 15 Jahren,

00:14:45.462 --> 00:14:47.542
den kannst du heutzutage immer noch haben und der kann dir immer noch sagen,

00:14:47.642 --> 00:14:49.862
dass dein HTML passt oder nicht passt.

00:14:50.162 --> 00:14:53.302
Aber die Frage ist ja, was bedeutet denn nicht passen?

00:14:53.922 --> 00:14:57.022
Also weil du kannst ja sagen, mein Programmcode ist falsch, aber das kann sich

00:14:57.022 --> 00:14:59.102
ja ausprägen auf viele verschiedene Weisen.

00:14:59.282 --> 00:15:03.042
Das kann sein, dass das Ding abstürzt oder halt irgendwie was falsch darstellt,

00:15:03.122 --> 00:15:06.142
die Pixel sind verschoben oder alles halt eben zwischendrin.

00:15:06.142 --> 00:15:10.242
Und der Fehlermodus von HTML ist halt irgendwie tatsächlich zu sagen,

00:15:10.482 --> 00:15:14.722
okay, ich habe hier ein Passerror, nicht wie stürze ich ab, das wäre XHTML gewesen,

00:15:15.082 --> 00:15:16.682
sondern der ist, okay, welchen,

00:15:17.382 --> 00:15:21.562
Fehlerkorrekturmechanismus fahre ich jetzt an, damit ich weiter dieses Dokument verarbeiten kann.

00:15:21.802 --> 00:15:24.962
Es gibt ja nicht wie in XML dieses Dokument ist nicht wohlgeformt,

00:15:25.002 --> 00:15:28.242
weil da irgendwie ein Quote fehlt, sondern da rollt einfach der HTML-Panzer

00:15:28.242 --> 00:15:30.262
immer weiter und lässt sich durch nichts aufhalten.

00:15:33.922 --> 00:15:34.402
Ich,

00:15:36.806 --> 00:15:41.206
Finden wir das gut? Mal ganz kurz. Sagen wir mal so,

00:15:42.226 --> 00:15:44.626
es hat halt historisch bedingt, glaube ich, mehr Sinn gemacht,

00:15:45.046 --> 00:15:50.666
als halt dieser ganze Webkram nicht nur die Domäne von irgendwelchen Turbonerds

00:15:50.666 --> 00:15:52.826
waren, die sich überhaupt solche Fragen stellen, wie wir jetzt gerade,

00:15:53.566 --> 00:15:56.406
sondern wo halt irgendwie auch der Hobby ist, der einfach irgendwie nur so Beef

00:15:56.406 --> 00:16:00.006
mit seinem Bürgermeister hatte, einfach mal eine Webseite irgendwie, wo haben wollte.

00:16:00.286 --> 00:16:03.586
Da war das halt, glaube ich, schon noch viel notwendiger als jetzt.

00:16:04.106 --> 00:16:06.486
Also, glaube ich, egal. Ich meine, wer Wer das nicht haben will,

00:16:06.566 --> 00:16:09.586
der kann ja theoretisch immer noch mit XML zu Werke gehen.

00:16:09.906 --> 00:16:13.466
Das ist ja dann validierbar und legt sich sofort die Karten,

00:16:13.586 --> 00:16:14.806
sobald irgendwo mal was nicht passt.

00:16:15.066 --> 00:16:18.546
Das geht ja. Man kann ja heutzutage tatsächlich XHTML-Dokumente raushauen.

00:16:18.826 --> 00:16:19.966
Das macht halt nur keiner.

00:16:20.566 --> 00:16:23.666
Und so denke ich halt eben auch, in der Theorie finden das, glaube ich,

00:16:23.686 --> 00:16:25.886
mehr Leute gut, als es in der Praxis passiert.

00:16:25.986 --> 00:16:29.486
Weil wenn das in der Praxis irgendwer gut fände, dann wäre nicht alles mit Doctype

00:16:29.486 --> 00:16:32.806
HTML versehen, sondern dann wären das alles XHTML-Dokumente.

00:16:35.286 --> 00:16:38.966
HTML5 ist ja die DOM-Struktur das ist ja was die Spezifikationen beschreiben

00:16:38.966 --> 00:16:43.426
und es gibt zwei Serialisierungen dieser DOM-Struktur das eine ist HTML,

00:16:43.606 --> 00:16:48.566
die andere ist XML aber die deserialisieren am Ende zum gleichen In-Memory-Baum-Modell,

00:16:49.086 --> 00:16:52.366
das heißt jeder von uns könnte sofort hingehen und könnte XHTML-Dokumente bauen

00:16:52.366 --> 00:16:54.986
dann wäre alles super strikt und statisch und hast du nicht gesehen,

00:16:55.546 --> 00:17:00.646
das macht halt keiner und das zeigt mir, dass das irgendwie glaube ich niemanden so wirklich kümmert.

00:17:03.965 --> 00:17:07.445
So, und wenn du nach meiner Meinung fragst, wie finde ich das, würde ich sagen,

00:17:08.005 --> 00:17:10.345
das ist halt irgendwie so, als würdest du mich fragen, wie finde ich denn den

00:17:10.345 --> 00:17:13.965
aktuellen Wert der Gravitationskonstante, weißt du, das ist halt so und das

00:17:13.965 --> 00:17:18.125
kriegen wir auch nicht mehr geändert und muss man sich halt mit abfinden und

00:17:18.125 --> 00:17:19.545
die Rakete entsprechend dimensionieren.

00:17:21.185 --> 00:17:22.505
Da bin ich ausgeschicken.

00:17:26.305 --> 00:17:28.945
Ich hätte zwei Dimensionen, über die ich mal sprechen wollte,

00:17:28.965 --> 00:17:30.185
würde mal gucken, ob das sinnvoll ist.

00:17:30.985 --> 00:17:33.965
Zwei Dimensionen kriege ich noch hin. Schieß los. Ich fange mal mit dem,

00:17:34.025 --> 00:17:35.165
glaube ich, einfacheren an.

00:17:35.425 --> 00:17:40.265
Das ist das erste Thema gewesen, nämlich dieses Type-Safe-HTML oder so.

00:17:41.205 --> 00:17:46.545
Und letztendlich auch dein CSS-Selektor. In meiner Welt ist es so,

00:17:46.685 --> 00:17:53.865
dass statische Code-Analyse sinnvoll ist, weil sie ermöglichen,

00:17:54.165 --> 00:18:00.365
schnell auf potenzielle Fehler hinzuweisen, dass sie potenziell Effizienz beim

00:18:00.365 --> 00:18:03.025
Entwickeln erhöhen, weil du eben nicht erst in den Browser gehen musst,

00:18:03.085 --> 00:18:07.205
sondern dass direkt in deiner IDE rot unterklingelt wird, wenn du es falsch schreibst. 100 Pro.

00:18:07.845 --> 00:18:13.365
Und die CI-Pipeline nicht 48 Stunden läuft, sondern halt nur 48 Sekunden und so weiter.

00:18:14.265 --> 00:18:17.565
Und insofern muss ich sagen, finde ich es immer schön, je mehr ich statisch analysieren kann.

00:18:17.685 --> 00:18:22.565
Und ich erinnere mich damals zu AngularJS 1 Zeiten, dass mich das total frustriert

00:18:22.565 --> 00:18:26.785
hat, dass da eben alles so super dynamisch war, ähnlich wie du das jetzt gerade

00:18:26.785 --> 00:18:28.165
von Web Components schilderst,

00:18:29.245 --> 00:18:32.605
dass man eben nicht schon im Compile-Schritt oder was auch immer,

00:18:32.685 --> 00:18:35.685
den es wahrscheinlich in deiner Welt gar nicht gibt, schon im Compile-Schritt

00:18:35.685 --> 00:18:38.945
sicherstellen kann, dass das, was man aufruft, tatsächlich existiert.

00:18:41.028 --> 00:18:45.488
Ja, also ich gehe 100% mit, dass in einer Welt, die so funktionieren würde,

00:18:45.748 --> 00:18:47.568
sich viele Fehler vermeiden ließen.

00:18:49.268 --> 00:18:54.728
Nur der Naturzustand des Webbrowsers ist halt nicht diese Welt und du musst

00:18:54.728 --> 00:18:57.908
sie halt eben mit Aufwand erzeugen und dann kommen wir wieder zu React,

00:18:57.988 --> 00:18:59.048
wo das ja tatsächlich so ist.

00:18:59.048 --> 00:19:04.768
Da wird alles durch ein JavaScript-Nabelöhr durchgedrückt und das hat halt so

00:19:04.768 --> 00:19:07.368
diverse Nachteile, aber das hat halt unter anderem den Vorteil,

00:19:07.748 --> 00:19:11.688
dass es halt eben tatsächlich ein Regelwerk gibt, sie alle zu knechten.

00:19:11.688 --> 00:19:16.248
Du kannst halt irgendwie alles so weitgehend der Kontrolle von TypeScript unterwerfen

00:19:16.248 --> 00:19:20.628
und damit halt eben diverse Fehler einfangen und bezahlst halt eben damit,

00:19:20.728 --> 00:19:23.928
dass du halt nicht direkt mit der Plattform redest, sondern halt immer so Dinger

00:19:23.928 --> 00:19:27.108
brauchst, die halt eine Brücke herstellen zwischen dem,

00:19:27.448 --> 00:19:29.508
wie es wirklich ist und dem, wie du es gerne hättest.

00:19:30.528 --> 00:19:33.728
Und das ist halt eben dann so der Trade-off. Wie geht man damit um mit diesem Delta?

00:19:34.088 --> 00:19:37.328
Entweder man macht so Embrace the Chaos. Das wäre jetzt so meins.

00:19:37.608 --> 00:19:40.788
Oder man sagt halt eben, hier muss man Ordnung einziehen. Und du schwingst den

00:19:40.788 --> 00:19:44.068
großen Besen und sagst, das geht jetzt alles hier durch dieses Nadelhör durch.

00:19:44.508 --> 00:19:48.248
Das ist halt eben Abstraktion, die ermöglicht. Ist ja ganz normales Programmier-Dings.

00:19:48.328 --> 00:19:49.388
Das ist alles irgendwie chaotisch.

00:19:49.708 --> 00:19:52.468
Lass mal da was drumherum basteln, was das Ganze irgendwie ordnet.

00:19:52.688 --> 00:19:54.828
Ist ja sinnvoll, ist ja etabliert. Kannst du machen.

00:19:56.388 --> 00:20:01.588
Ich habe dich gerade gefragt, finden wir das gut. Die historische Herleitung,

00:20:01.708 --> 00:20:04.208
warum Browser jegliches HTML schlucken.

00:20:06.072 --> 00:20:09.092
Und die Tatsache, dass man sich leichter bei den Bürgermeister beklagen kann,

00:20:09.212 --> 00:20:12.572
das ist also Demokratisierung des Webs quasi, spitze.

00:20:14.932 --> 00:20:20.732
Aber wenn du heute den Browser des Web 5.0 sind wir wahrscheinlich gerade entwickeln

00:20:20.732 --> 00:20:26.032
würdest, würde der immer noch kaputtes HTML schlucken oder nur XHTML?

00:20:27.092 --> 00:20:30.032
100 pro würde der kaputtes HTML schlucken, besser als alle anderen.

00:20:30.832 --> 00:20:34.172
Das ist halt so die Grundvoraussetzung. Das ist das Eintrittsgeld,

00:20:34.232 --> 00:20:35.812
das du bezahlen musst, um überhaupt teilzunehmen.

00:20:36.072 --> 00:20:39.212
Das Ding ist halt, wenn du einen Browser hast, der kein kaputtes HTML schluckt,

00:20:39.512 --> 00:20:41.952
ist der instantan ein schlechterer Browser als alle anderen,

00:20:42.052 --> 00:20:44.992
weil der halt in der Lage ist, weniger Webseiten darzustellen als die Konkurrenz.

00:20:45.052 --> 00:20:47.052
Ja, aber du bist ja jetzt im Web 5.0.

00:20:47.252 --> 00:20:50.172
Da gibt es ja das alte Web. Das alte Web ist ja langweilig. Das interessiert

00:20:50.172 --> 00:20:52.132
dich ja gar nicht. Du erfindest ja gerade alles neu.

00:20:53.512 --> 00:20:59.972
Okay. Wenn ich es neu erfinden würde, würde ich mir wahrscheinlich was Neues ausdenken.

00:21:00.612 --> 00:21:04.032
Aber was Neues zu erfinden, scheint mir halt mehr oder minder ausgeschlossen.

00:21:04.032 --> 00:21:07.732
Also das halte ich für eine derart hypothetische Kiste.

00:21:07.952 --> 00:21:12.092
Das würde ich so ins Bücherregal in das gleiche Fach so mit der sowjetischen

00:21:12.092 --> 00:21:15.992
Fantastik reden, wo halt so die Gen-Engineers irgendwelche Drachen wiederbeleben,

00:21:16.092 --> 00:21:18.412
mit denen man dann durchs Universum fliegt. Okay, okay, okay.

00:21:18.532 --> 00:21:22.672
Ich habe es heute mit Vergleichen, die nicht funktionieren. Das habe ich im

00:21:22.672 --> 00:21:23.872
Termin vorher schon erfahren.

00:21:25.772 --> 00:21:29.192
Ich hätte vielleicht einen besseren Vorschlag. Okay.

00:21:29.472 --> 00:21:34.172
Wir führen einen neuen Header ein, so wie Strict Transport Security,

00:21:34.312 --> 00:21:37.912
der sagt, wenn unter dieser Domain falsches HTML kommt, wirft das bitte weg.

00:21:40.200 --> 00:21:43.400
Den Heller brauchst du nicht. Du brauchst nur den Content-Type umzuschalten

00:21:43.400 --> 00:21:47.880
auf Application XML. Da hast du das bei dir. Es sei denn, meine Anwendung läuft amok.

00:21:49.240 --> 00:21:54.040
Also mir geht's Was bedeutet amoklaufen? Der Tomcat, falls man es heute noch

00:21:54.040 --> 00:21:58.100
benutzt, ist abgeschmiert und irgendwas anderes antwortet komisch.

00:21:58.180 --> 00:22:01.720
Irgendein Anleitver hat sich dazwischen geklemmt in die Kommunikation. Ich habe keine Ahnung.

00:22:02.960 --> 00:22:06.120
Du willst also sagen, wenn in einer Applikation kein gültiges Zeug ausspuckt,

00:22:06.180 --> 00:22:09.420
ist kaputt. Und ich möchte gerne, dass der Browser sich dessen bewusst ist.

00:22:09.620 --> 00:22:13.700
Also, dass der Der Browser weiß, diese Website hier spricht XHTML und wenn sie

00:22:13.700 --> 00:22:16.100
das nicht tut, dann ist was schiefgelaufen, dann wirft das bitte weg.

00:22:17.000 --> 00:22:19.800
Mach deinen Content-Type. Wenn du den Content-Type-Hater so setzt,

00:22:20.220 --> 00:22:23.700
dann nimmt der Browser zum Parsen deines Dokuments den XML-Parse und wenn daran

00:22:23.700 --> 00:22:25.400
was nicht passt, dann ist es. Vielleicht sollte ich erklären,

00:22:26.500 --> 00:22:30.520
warum ich da so drauf, warum ich von dieser Seite rankomme.

00:22:30.580 --> 00:22:35.160
Also mein Gedanke ist, dieses Browser-Schlucken jeder Art von kaputtem HTML

00:22:35.160 --> 00:22:39.920
ist ja durchaus Wegbereiter für die ein oder andere Sicherheitslücke.

00:22:40.020 --> 00:22:40.940
Im Web gewesen.

00:22:42.240 --> 00:22:46.840
Und willst du da schon einsteigen?

00:22:48.040 --> 00:22:50.980
Ich weiß nicht, ob das bei HTML der Fall ist. Ich kann es nicht ausschließen.

00:22:52.200 --> 00:22:56.380
Ich glaube, es ist mehr so, dass, sagen wir mal, Design-Schwächen,

00:22:56.520 --> 00:23:00.020
wie irgendwie, dass du in einen On-Click-Händler beliebiges JavaScript reinschreiben

00:23:00.020 --> 00:23:03.780
kannst, wo das dann irgendwelchen Blödsinn-E-Welt, aber das ist ja kein ungültiges HTML.

00:23:04.480 --> 00:23:07.620
Ungültiges HTML ist in meinem Kopf mehr sowas wie, du machst eine Table auf,

00:23:07.680 --> 00:23:11.300
aber ein Diff zu und der Browser stürzt daran nicht ab, sondern sagt halt eben,

00:23:11.420 --> 00:23:12.800
ah, das kenne ich schon, das mache ich weiter.

00:23:15.210 --> 00:23:19.090
Oder dein Body Tag fehlt oder irgendwie im Header ist ein P oder sowas.

00:23:19.290 --> 00:23:20.530
Das ist ja ungültiges HTML.

00:23:21.270 --> 00:23:24.710
Viele der Angriffe, auch die mit dem erwähnten On-Click gerade,

00:23:26.330 --> 00:23:27.530
funktionieren halt aber nur,

00:23:27.830 --> 00:23:33.450
weil Browser am Ende das daraus resultierende kaputte HTML akzeptieren.

00:23:34.370 --> 00:23:35.710
Ja gut, das kann natürlich sein.

00:23:36.810 --> 00:23:40.490
Wenn du sozusagen an einer Stelle was kaputt machst, damit das mit evaluiert

00:23:40.490 --> 00:23:43.170
wird, was du an anderer Stelle auch noch reinjuckst, das kann ich mir vorstellen.

00:23:43.170 --> 00:23:47.390
Du hast natürlich recht, dass saubere Trennung von Code und Daten irgendwie

00:23:47.390 --> 00:23:49.390
auch ein schöner Anfang gewesen wäre.

00:23:50.210 --> 00:23:54.150
Aber trotzdem dieses, wir probieren mal einfach rum.

00:23:55.950 --> 00:23:58.170
Ich muss gestehen, dass es bei mir gerade auch mehr ein Bauchgefühl ist.

00:23:58.170 --> 00:24:02.310
Also dieses Beispiel mit, man bricht damit aus dem HTML raus und dann bleibt

00:24:02.310 --> 00:24:05.010
da halt ein kaputtes HTML stehen und Browser schlucken, dass das existiert ja

00:24:05.010 --> 00:24:05.730
durchaus in der Realität.

00:24:05.810 --> 00:24:09.370
Aber ich habe so ein allgemeines Bauchgefühl, dass dieses, wir probieren mal

00:24:09.370 --> 00:24:11.990
wild rum, wenn etwas nicht genau den Anforderungen entspricht,

00:24:12.070 --> 00:24:14.990
ob wir das nicht irgendwie doch noch auswerten können, dass das immer mal wieder

00:24:14.990 --> 00:24:17.750
viel bereiter für Sicherheitslücken war.

00:24:18.710 --> 00:24:21.990
Und deswegen habe ich da so ein, das wäre irgendwie cool, wenn wir es nicht

00:24:21.990 --> 00:24:23.950
mehr hätten und einen Header,

00:24:24.110 --> 00:24:27.610
den wir setzen, der eben dafür sorgt, dass bei weiteren Besuchen das immer noch

00:24:27.610 --> 00:24:32.010
abgelehnt wird, würde das Problem deutlich mehr mitigieren als so der Content-Type-Header,

00:24:32.110 --> 00:24:33.710
der halt nur für diese eine Response gilt.

00:24:37.850 --> 00:24:39.930
Verstehe ich jetzt den Unterschied zwischen diesen beiden Header nicht?

00:24:39.930 --> 00:24:44.470
Weil in dem Moment, wo ein Angreifer da ist, sage ich jetzt mal,

00:24:46.890 --> 00:24:49.130
will ich mich darauf verlassen können, dass der Browser weiß,

00:24:49.230 --> 00:24:53.150
dass er das bei uns so interpretieren soll und nicht darauf spekulieren,

00:24:53.210 --> 00:24:56.190
dass in dieser Response auch noch der richtige Header mitgeschickt wird.

00:25:00.861 --> 00:25:04.661
Ich kann mir gerade das Szenario nicht zusammenreimen. Also mit dem richtigen Header halt.

00:25:04.881 --> 00:25:08.161
Weil ich meine, Stand jetzt schaffen es ja alle Web-Server auf diesem Planeten

00:25:08.161 --> 00:25:11.461
völlig problemlos zu sagen, hier Content-Type-Text HTML.

00:25:12.041 --> 00:25:14.981
Und ich glaube, durch relativ einfache String-Substitutionen könnte man sie

00:25:14.981 --> 00:25:17.581
dazu bringen, dass sie dann sagen, Content-Type-Application-XML.

00:25:17.941 --> 00:25:21.161
Und dann wären wir in der Welt, wo halt ungültiger Code nicht mehr akzeptiert

00:25:21.161 --> 00:25:24.701
wird. Das müsste halt nur jemand machen, der darauf Wert legt.

00:25:28.201 --> 00:25:33.401
Wie verhalten ein Browser sich, wenn ich keinen Content-Type-Header mit liefere? Das weiß ich nicht.

00:25:33.701 --> 00:25:38.241
Hätte ich auch gesagt. Und insofern würde ich behaupten, dass nicht jeder Web-Server

00:25:38.241 --> 00:25:39.881
diesen Content-Type setzt.

00:25:40.781 --> 00:25:44.001
Na gut, aber ich meine, wir gehen ja von der Prämisse aus, dass wir jetzt operieren

00:25:44.001 --> 00:25:48.141
unter der Älgide vom strikten Kiki, wo ja ordentliche Entwicklung,

00:25:48.201 --> 00:25:51.241
mechanische Analyse schon mal Ausgangsposition ist.

00:25:51.361 --> 00:25:54.581
Und dann würde ich ja auch mal unterstellen, dass dir kein Server ins Haus kommt,

00:25:55.041 --> 00:25:58.241
den halt ich irgendwie mit 16 Jahren zusammengeschustert habe und der tatsächlich

00:25:58.241 --> 00:25:59.101
keinen Content-Type hat.

00:26:00.861 --> 00:26:04.321
Ich bin ja aber gerade in der Situation, etwas ist mit dem System nicht in Ordnung,

00:26:04.381 --> 00:26:08.941
weil es jemand angegriffen hat, weil Tomcat zu viel RAM braucht, weil weiß ich nicht was.

00:26:09.181 --> 00:26:13.041
Und in der Situation kann ich mich auf diese Annahmen oder will ich mich auf

00:26:13.041 --> 00:26:15.221
so wenige dieser Annahmen verlassen müssen, wie möglich.

00:26:18.694 --> 00:26:22.974
Okay, was du also gerne hättest, wäre ein Browser, der tatsächlich kaputtes HTML nicht akzeptiert.

00:26:23.134 --> 00:26:26.054
Du willst nicht für dein Projekt ein Opt-out machen und sagen,

00:26:26.274 --> 00:26:29.914
so hier, alles, was meine Agentur liefert, ist jetzt irgendwie Application XML,

00:26:30.074 --> 00:26:32.394
sondern du willst, dass die Clients tatsächlich nicht in der Lage sind,

00:26:32.574 --> 00:26:35.134
kaputtes HTML so zu verarbeiten, wie sie es im Moment tun.

00:26:35.134 --> 00:26:39.754
Ich bin fein damit, wenn ich ausopten muss, aber das soll dann bitte für meine

00:26:39.754 --> 00:26:45.174
Domain persistierbar sein, ähnlich wie bei diesem Ding mit meiner Domain bitte

00:26:45.174 --> 00:26:48.754
nur noch bei TRS 1.2 aufrufen.

00:26:54.214 --> 00:26:56.814
Eigentlich war ich bei der Frage, ob du das für eine gute Idee hältst oder nicht.

00:26:59.354 --> 00:27:04.374
Ich glaube die Ziele von Qualität und Stabilität lassen sich auf anderem Wege

00:27:04.374 --> 00:27:08.134
einfacher erreichen und deshalb würde ich vorschlagen die Ressourcen anderswohin

00:27:08.134 --> 00:27:10.994
zu konzentrieren, ergo keine so besonders brillante.

00:27:10.994 --> 00:27:11.814
Dann bleiben wir einfach dabei,

00:27:11.914 --> 00:27:14.594
dass wir UseDebugValue verwenden und dann lass das Problem auch weg.

00:27:16.054 --> 00:27:21.014
Ja genau, ne ConsoleLog oder hier DebuggerStatements in den Code reinbauen,

00:27:21.094 --> 00:27:25.974
dass du so, dass du alles neu kompilieren musst und fancy DevTools benutzen kannst. Ja okay.

00:27:29.014 --> 00:27:33.674
Okay, wollen wir ein neues Thema uns picken? Ja, Nummer zwei, yay.

00:27:35.015 --> 00:27:38.895
Moment, mache ich wieder den Zufallsgenerator. Ich habe meine Konsole immer

00:27:38.895 --> 00:27:42.755
noch offen und ich drücke einfach die gleiche Zeile nochmal rein. Und wir sind bei 42.

00:27:43.995 --> 00:27:47.135
Klar, sicher sind wir bei 42. Natürlich, ich glaube, das sind nicht die einzigen

00:27:47.135 --> 00:27:50.215
Zeilen, die ich ausspucken kann. Is valid element?

00:27:51.315 --> 00:27:55.275
Ist das eine Überleitung, oder? Wir haben die ganze Zeit über HTML-Validität

00:27:55.275 --> 00:27:57.895
gesprochen. Wir haben jetzt tatsächlich die Funktion Is valid element?

00:27:58.255 --> 00:28:02.055
Nein, nein, nein. Das guckt, ob der Value, den du da reinsteckst,

00:28:02.155 --> 00:28:03.835
ein gültiges React-Element ist.

00:28:04.215 --> 00:28:07.015
Also ich muss jetzt erstmal unterbrechen. Als ich hier gerade geguckt habe,

00:28:07.035 --> 00:28:11.635
was die Nummer 42 war, stand da was komplett anderes und die 44 war leer.

00:28:11.855 --> 00:28:14.995
Und jetzt ist das von der 42 in die 44 gerutscht und da ist was Neues.

00:28:15.135 --> 00:28:17.175
Ich glaube, Peter hat sehr bewusst.

00:28:17.855 --> 00:28:21.095
Also ich kann tatsächlich sagen, das Dokument hat sich in der letzten Zeit nicht

00:28:21.095 --> 00:28:24.135
geändert. Ich glaube, das dürfte bei dir noch ein Update-Problem gewesen sein.

00:28:24.295 --> 00:28:27.535
Aber das hat bei mir jetzt schon immer so ausgeschaut. Ich hasse das Internet.

00:28:30.495 --> 00:28:33.855
Aber die wichtigere Frage ist, Hast du auch Hass auf isValidElement?

00:28:34.675 --> 00:28:37.515
Nee, ich glaube, dass ich das um ehrlich zu sein habe, auch super selten.

00:28:37.635 --> 00:28:41.275
Ich glaube, dass im Kontext von React Children Map habe ich das mal benutzt

00:28:41.275 --> 00:28:42.655
und dann halt es auf und irgendwie.

00:28:42.835 --> 00:28:45.975
Also, wenn du Children angibst, willst du natürlich auch überprüfen,

00:28:46.015 --> 00:28:47.775
ob das Elemente sind, damit du die renderst?

00:28:48.355 --> 00:28:51.435
Eventuell, aber ich bin mir nicht sicher. Also, wenn du euch diese Funktion

00:28:51.435 --> 00:28:52.415
auch noch nie verwendet.

00:28:52.995 --> 00:28:56.915
Also, ich bin beeindruckt, dass es die Funktion gibt. Ich habe die nun nie verwendet.

00:28:57.035 --> 00:29:00.075
Ich finde das total cool und ich habe gerade gesehen, dass Legacy ist.

00:29:00.175 --> 00:29:02.315
Das heißt, wahrscheinlich sollte man es dann eh nicht mehr verwenden.

00:29:04.831 --> 00:29:08.411
Peter, kennst du das? Nö, tatsächlich habe ich das auch beim Zusammenstellen

00:29:08.411 --> 00:29:09.751
der Liste hier zum ersten Mal gesehen.

00:29:09.991 --> 00:29:13.471
Aber natürlich wandert mein seltsames Gehirn jetzt direkt schon mal los.

00:29:13.851 --> 00:29:16.991
Und er fühlt sich erinnert an Array is Array.

00:29:17.551 --> 00:29:21.531
Das gibt es ja auch. Und das hat ja diese wunderbare magische Eigenschaft,

00:29:21.631 --> 00:29:26.211
dass es dir ja sagen kann, in Browsing-Context 2 angewendet auf ein Array aus

00:29:26.211 --> 00:29:28.551
Browsing-Context 1, jupp, das ist 1.

00:29:28.931 --> 00:29:32.751
Das braucht nicht wie Instance-Off den Constructor und das Objekt aus dem gleichen

00:29:32.751 --> 00:29:36.871
Browsing-Context zu haben. Das kann über Frame-Grenzen hinweg und Ähnliches, dir das ja sagen.

00:29:37.891 --> 00:29:41.471
Musste ich letztens tatsächlich mal basteln, also sowas extrem Ähnliches aus

00:29:41.471 --> 00:29:44.391
ganz anderen Gründen, aber letztlich so die gleiche Problematik.

00:29:44.831 --> 00:29:47.111
Musste das also zu Fuß mal implementieren, sowas in der Richtung.

00:29:47.351 --> 00:29:50.451
Und jetzt frage ich mich natürlich, ob dieser Kollege auch Cross-Browsing-Kontext

00:29:50.451 --> 00:29:52.911
funktioniert. Wahrscheinlich nicht, weil er braucht ja keiner.

00:29:53.831 --> 00:29:55.571
Aber es wäre natürlich ein Flex, wenn es das könnte.

00:29:56.631 --> 00:30:02.671
Das Ding geht ja wirklich nur wieder auf die Parallelwelt. React los, ist valid element.

00:30:03.171 --> 00:30:05.711
Ja gut, aber die Parallelwelt kannst du ja implementieren, wie du willst.

00:30:05.771 --> 00:30:09.691
Und du kannst sie ja auch so implementieren, dass sie Cross-Browsing-Kontext-Vergleiche richtig macht.

00:30:10.211 --> 00:30:12.631
Also was ich jetzt nicht kaum sehen habe, ist, dass ich jetzt den Quellcode

00:30:12.631 --> 00:30:16.391
von React gucke, während dieser Post-Cast-Folge. Ich bin auch gerade dabei.

00:30:17.131 --> 00:30:20.311
Da ist es. Type of Object, das darf nicht in der Nähe sein.

00:30:22.211 --> 00:30:26.771
React Element Type, das klingt was zu alles, dollar dollar, type of.

00:30:28.210 --> 00:30:32.710
Das ist die Parallelwelt-Type-Off von React. Ja, das ist super.

00:30:32.830 --> 00:30:34.830
Einfach irgendwie ein F-Fix davor packen und dann passt das schon.

00:30:34.890 --> 00:30:35.750
Das hätte von mir sein können.

00:30:36.030 --> 00:30:40.170
Ja, ich finde es sehr schön. Also die Dokumentation sagt ja auch,

00:30:40.250 --> 00:30:43.090
dass es wirklich Elemente überprüft und nicht Nodes.

00:30:43.370 --> 00:30:46.510
Also du kannst ja einen Text-Node zum Beispiel haben und solche Sachen.

00:30:47.170 --> 00:30:49.110
Auch in React? Auch in React.

00:30:50.010 --> 00:30:52.750
Also es gibt React-Nodes und React-Elements. Das weiß ja jeder,

00:30:52.830 --> 00:30:59.170
der übrigens die React-JSX-Typen auf... die es noch mal gesehen hat.

00:31:00.870 --> 00:31:07.470
Und was ja wieder diesen Parallelweltgedanken unterstützt, ich glaube das einzige

00:31:07.470 --> 00:31:09.910
Thema ist, über das ich in der heutigen Episode reden werde.

00:31:11.050 --> 00:31:15.010
Aber es ist herrlich, oder? Also es ist ja wirklich eine genaue Spiegelung von

00:31:15.010 --> 00:31:17.010
dem, was wir nachher tatsächlich in den Browser haben wollen.

00:31:17.450 --> 00:31:23.790
Und sie referenziert hat auch die Nummer 42, was natürlich schön ist,

00:31:23.830 --> 00:31:25.350
weil es bei uns auch die Nummer 42 war.

00:31:27.530 --> 00:31:31.650
Frage an der Stelle, Symbol4 liefert in zwei verschiedenen Browser-Kontexten

00:31:31.650 --> 00:31:32.630
ein anderes Ergebnis, oder?

00:31:32.950 --> 00:31:36.770
Das gleiche. Das gleiche. Dann halte ich es für möglich, dass es funktioniert,

00:31:36.990 --> 00:31:38.190
weil sie nutzen Symbol4.

00:31:38.610 --> 00:31:42.890
Bin mir noch nicht ganz sicher, was dieses $-Type-of ist, ob das tatsächlich

00:31:42.890 --> 00:31:48.230
irgendwie bei irgendeiner Form von Serialisierung verloren geht,

00:31:48.270 --> 00:31:51.690
aber auf den ersten Blick glaube ich, das ist einfach eine reguläre Property und klappt.

00:31:52.390 --> 00:31:56.430
Ja, sehe ich genauso. Also dieses Symbol4 ist halt so das einzige Ding,

00:31:56.530 --> 00:32:00.330
womit man tatsächlich nicht Objekte, aber Symbols halt draufbeschwören kann,

00:32:00.510 --> 00:32:04.770
die dann in unterschiedlichen Frames das gleiche referenzieren.

00:32:04.870 --> 00:32:08.710
Das heißt, das Ding wäre tatsächlich Cross-Browsing-Kontext-Vergleichs-safe.

00:32:08.990 --> 00:32:11.590
Ich frage mich halt, ob das jemals irgendwer benutzt hat.

00:32:12.150 --> 00:32:15.990
Ich war ja letztens in so einem Workshop von dir, in dem es auch um Symbols

00:32:15.990 --> 00:32:19.890
und Cross-Browser-Kontext ging. Also wahrscheinlich hast du das da auch erwähnt. Ja.

00:32:20.910 --> 00:32:26.870
So ein Bissl macht es aber auch das Konzept von Symbols kaputt, oder? Nö.

00:32:28.120 --> 00:32:36.520
Wo ist der Benefit von Symbol 4 gegenüber dem String, den ich dem Symbol 4 übergebe?

00:32:36.780 --> 00:32:40.480
Kack jetzt, in einem öffentlich aufgezeichneten Podcast oute ich mich als dumm.

00:32:40.560 --> 00:32:42.160
Das ist wirklich ungeschickt von mir. Nein, nicht als dumm.

00:32:42.420 --> 00:32:46.380
Du hast recht, auf eine gewisse Weise. Du outest dich nur, dass du die nötige

00:32:46.380 --> 00:32:50.760
Referenz nicht griffbereit hast, weil die nächsten Developers wissen ja nicht

00:32:50.760 --> 00:32:54.140
alles, sondern die wissen, wo sie es holen müssen.

00:32:54.880 --> 00:32:58.020
Ja, ich weiß, dass Peter fragen muss. Zum Beispiel das und zum anderen ist es

00:32:58.020 --> 00:33:02.100
ja auch schon mal ein Zeichen von einer gewissen Brillanz überhaupt zu erkennen,

00:33:02.300 --> 00:33:04.840
dass es da eine semantische Überschneidung gibt und dass es sich vielleicht

00:33:04.840 --> 00:33:05.960
lohnt herauszuarbeiten.

00:33:06.240 --> 00:33:09.160
Gibt es da einen Benefit? Wo sind die Gemeinsamkeiten? Wo sind die Unterschiede?

00:33:09.320 --> 00:33:10.620
Das musst du ja auch erstmal erkennen.

00:33:11.420 --> 00:33:15.940
Also erstmal, grundsätzlich ist so, ja, du kannst mit dem String,

00:33:16.020 --> 00:33:18.900
wenn du den String hast und du im JavaScript drin bist, kannst du das gleiche

00:33:18.900 --> 00:33:19.760
Symbol heraufbeschwören.

00:33:19.840 --> 00:33:24.140
Du hast halt nicht mehr dieses Privacy-Feature, wenn die Variable irgendwie

00:33:24.140 --> 00:33:25.560
in der Closure steckt, kommst du nicht mehr ran.

00:33:25.760 --> 00:33:31.400
Und insofern ist es tatsächlich so, dass so ein registriertes Symbol ein etwas seltsamer String ist.

00:33:32.400 --> 00:33:36.400
Was sind die Benefits? Benefit Nummer eins, definitionsgemäß non-enumerable.

00:33:36.400 --> 00:33:41.240
Das Ding wird dir also nicht in einer For-In-Schleife oder Object-Keys oder sowas entgegenfallen.

00:33:41.920 --> 00:33:46.180
Und zum anderen ist es so, es kann halt nicht versehentlich heraufbeschworen

00:33:46.180 --> 00:33:49.240
werden, indem ich diesen String in ein Formularfeld eintippe.

00:33:51.406 --> 00:33:53.986
Wenn du sagst, hallo hier Peter, ich habe eine neue Web-App gevibecodet,

00:33:54.066 --> 00:33:57.346
probier mal aus, dann kannst du dir sicher sein, dass mein Vorname unterstrich

00:33:57.346 --> 00:33:59.146
unterstrich proto unterstrich unterstrich lautet.

00:33:59.406 --> 00:34:03.186
Einfach nur um rauszufinden, ob da denn alles irgendwie ordentlich funktioniert

00:34:03.186 --> 00:34:07.086
oder ob man da irgendwie durch komische Eingaben was kaputt machen kann und

00:34:07.086 --> 00:34:08.266
das kann ich halt mit Symbols nicht mehr machen.

00:34:08.866 --> 00:34:15.186
Ich finde es ja sehr spannend, dass Sie zwar auf der, also bei diesem Dollar-Dollar-Type-off-Property

00:34:15.186 --> 00:34:21.086
zwar auf der Assignment-Seite mit Symbols arbeiten, aber nicht Dollar-Dollar-Type-off

00:34:21.086 --> 00:34:22.546
auch als Symbol abbilden.

00:34:23.366 --> 00:34:25.026
Das würde sich echt anbieten, weil

00:34:25.026 --> 00:34:28.546
dann hast du nämlich genau den ganzen Enumerationsblödsinn nicht mehr.

00:34:30.614 --> 00:34:36.574
Bei Dollar-Dollar-Type-Off kannst du enumerieren. Ja, die Frage ist halt,

00:34:36.674 --> 00:34:38.614
also weil solche APIs sind ja quasi,

00:34:40.074 --> 00:34:43.774
also es ist ja nicht so, dass privat und nicht privat so ein Binary ist,

00:34:44.814 --> 00:34:48.834
weil du hast ja so Dinge wie Debugbarkeit.

00:34:49.014 --> 00:34:49.794
Also du schreibst irgendwie so

00:34:49.794 --> 00:34:53.494
ein React-Node irgendwie in die Konsole und dann willst du ja irgendwie,

00:34:54.114 --> 00:34:57.834
also dann ist es ja schon ersichtlicher, wenn du im Debug-Modus bist und wo

00:34:57.834 --> 00:35:01.134
dann die Variablen-Namen nicht minifiziert sind, dass du da erkennen kannst,

00:35:01.314 --> 00:35:02.434
okay, Dollar, Dollar, das ist irgendein

00:35:02.434 --> 00:35:05.194
internes Ding. Das habe ich nicht versehentlich da reingeschrieben.

00:35:05.534 --> 00:35:08.394
Das heißt überall immer das Gleiche. Ich habe da so eine grobe Idee von.

00:35:08.894 --> 00:35:11.954
Das ist halt viel sprechender, als wenn du da diesen komischen Zahlen,

00:35:12.274 --> 00:35:16.994
nee, diesen Symbol Klumpatsch da hast, der halt mit einem Symbol-Key da einhergeht.

00:35:17.134 --> 00:35:18.714
Ja, da kann dann auch eine Description drinstehen.

00:35:19.214 --> 00:35:21.674
Aber die ist dann halt zum Beispiel auch immer da und wird halt eben nicht dann

00:35:21.674 --> 00:35:24.254
wegminifiziert, wenn du das kompilierst und so.

00:35:24.514 --> 00:35:28.254
Also ich glaube, da gibt es halt schon so Überlegungen, wenn du an so einem

00:35:28.254 --> 00:35:31.054
großen Rad drehst wie React, wo du dann wirklich überlegst, okay,

00:35:31.754 --> 00:35:37.334
es gibt Gestaltungsüberlegungen für die APIs, die normale Menschen nicht benutzen

00:35:37.334 --> 00:35:40.014
sollen, aber diese Überlegungen betreffen halt die normalen Menschen.

00:35:40.234 --> 00:35:43.914
So wie du halt irgendwie auch überlegst, was ist irgendwie das beste Warnschild,

00:35:43.994 --> 00:35:47.634
das ich da aufklebe, auf irgendwie, was gefährlich ist. Okay, das verstehe ich.

00:35:49.294 --> 00:35:54.734
Ich hätte auch noch die These, dass im Zweifelsfall dieses Dollar oder Type

00:35:54.734 --> 00:35:57.154
of Älter ist als Symbols. Bestimmt.

00:35:58.934 --> 00:36:05.034
Aber ist auch noch eine These also ich muss gestehen diese Datei React.js,

00:36:05.134 --> 00:36:09.634
Element.js könnte ich jetzt auch noch länger lesen das ist schon extrem unangenehm,

00:36:09.674 --> 00:36:11.694
was hier passiert ist wieso unangenehm?

00:36:13.174 --> 00:36:16.194
Ich weiß nicht, wo ich anfangen soll nimm irgendwas?

00:36:17.034 --> 00:36:22.134
Da wird halt an ein paar Stellen den String zurückgegeben dieser String ist,

00:36:22.894 --> 00:36:25.874
Spitze Klammer auf, Pünktchen, Pünktchen, Pünktchen Spitze Klammer zu.

00:36:27.986 --> 00:36:33.726
Ich habe Fragen, wann dieser String jemals eine sinnvolle Rückgabe ist.

00:36:34.126 --> 00:36:39.026
Das scheint nur Dev-Mode eventuell. Nee. Nehme ich zurück.

00:36:40.186 --> 00:36:44.046
Ich verstehe also, ich fühle mich beeindruckt, wie ich überhaupt kein Wort von diesem Code verstehe.

00:36:44.446 --> 00:36:47.286
Wie hier Sachen passieren, die ich noch nie gemacht habe, dass hier eine Auflistung

00:36:47.286 --> 00:36:49.946
von JavaScript-Engines an Variablen dran steht.

00:36:50.526 --> 00:36:55.226
Dann bin ich hier über so ein No-Inline-Annotation gestolpert.

00:36:56.726 --> 00:37:03.566
Wo ich Vermutungen habe, was sie tun könnte, aber zuletzt habe ich davon gehört,

00:37:03.666 --> 00:37:07.586
als ich mich mit GCC befasst habe und das habe ich jetzt nicht in JavaScript-Code kommen sehen.

00:37:07.986 --> 00:37:10.026
Und weißt du, was du denn als nächstes machen solltest?

00:37:10.706 --> 00:37:17.066
Dann machst du mal React zu, nimmst dir Preact und liest mal den Code. Der ist schöner, oder?

00:37:17.646 --> 00:37:20.546
Nein, aber Größenordnungen weniger.

00:37:21.426 --> 00:37:25.226
Größenordnungen weniger schön oder weniger schlimm? Ich würde ihn nicht notwendigerweise

00:37:25.226 --> 00:37:29.126
als weniger schlimm, wenn man jetzt so irgendwie die Ästhetik-Überlegungen von

00:37:29.126 --> 00:37:31.906
irgendwelchen Normies da anlegt, würde ich jetzt so nicht sagen.

00:37:32.066 --> 00:37:36.406
Das ist jetzt nicht irgendwie, also weil die halt eben schon echt ziemlich brutal darauf hin optimieren.

00:37:36.686 --> 00:37:39.806
Wir hatten ja auch, glaube ich, mal jemanden aus dem Pre-Act-Team,

00:37:40.066 --> 00:37:42.806
der darüber erzählt hat, wie sie halt eben das so hinkriegen.

00:37:42.926 --> 00:37:45.866
Also wie sie den Code schon so schreiben, dass sie dem Minifier zuarbeiten,

00:37:46.586 --> 00:37:49.726
damit er auch immer schön nur so und so viele Variablen macht.

00:37:49.806 --> 00:37:52.486
Ich meine, der älteste Trick ist natürlich irgendwie zu sagen,

00:37:52.906 --> 00:37:54.846
Wenn ich ein leeres Array haben will, mache ich nicht Eck hier,

00:37:54.946 --> 00:37:56.866
Klammer auf, Eck hier, Klammer zu, weil es sind ja zwei Zeichen,

00:37:57.126 --> 00:38:00.406
sondern ich mache einen Variablen-Namen namens empty Array, weil empty Array

00:38:00.406 --> 00:38:02.786
kann runtergekürzt werden zu einem Zeichen von dem Minifier.

00:38:03.686 --> 00:38:06.266
Solche Überlegungen sind da halt eben im Code drin und ich weiß nicht,

00:38:06.386 --> 00:38:10.006
Gigi, ob das jetzt wirklich dann deinen ästhetischen Überlegungen zuträglich

00:38:10.006 --> 00:38:10.946
ist, wenn man sowas macht.

00:38:12.146 --> 00:38:18.406
Aber es ist halt unglaublich wenig. Code? Oder schlimm? Code.

00:38:20.190 --> 00:38:23.770
Und nicht irgendwie jetzt obfuskiert oder irgendwie midifiziert mit Trollung,

00:38:23.850 --> 00:38:26.590
sondern tatsächlich halt eben mit Überlegung und Bedacht.

00:38:27.010 --> 00:38:30.130
Das ist jetzt wirklich so rein auf der ästhetischen Ebene. Das sieht halt genauso

00:38:30.130 --> 00:38:31.970
wie Line Noise aus wie irgendwie Rust Code.

00:38:32.530 --> 00:38:35.630
Kann man jetzt dann finden, wie man möchte. Aber es ist halt auf jeden Fall

00:38:35.630 --> 00:38:38.730
einfach schon sehr viel krass, was halt eben alles in React drin ist und was

00:38:38.730 --> 00:38:39.890
in Preact nicht drin ist.

00:38:40.050 --> 00:38:44.510
Und dann ist es halt trotzdem so in erster Nährung 99 Prozent gegeneinander austauschbar.

00:38:45.230 --> 00:38:47.670
Da fängt man dann an drüber nachzudenken, was macht man hier eigentlich?

00:38:48.470 --> 00:38:52.490
Ich bin immer noch auf der RealCodebase hängen geblieben.

00:38:55.150 --> 00:38:57.630
Ich habe jetzt auch reingeschaut und die, glaube ich, schaltest du wieder weg.

00:39:00.570 --> 00:39:04.690
Genau. Hey, wollen wir nicht vielleicht lieber auf eine zufällige Zahl umschalten? Ja, natürlich.

00:39:04.870 --> 00:39:10.510
Sehr gerne. Also ich werfe diesen Zufallsgenerator wieder an und die sind bei 69.

00:39:12.050 --> 00:39:20.550
69. Nice. Und damit entern wir Typescript-Land. wenn ich mich nicht ganz täusche ah ist das schön,

00:39:22.135 --> 00:39:24.915
Go off, King. Nein, was will ich dazu sagen?

00:39:26.035 --> 00:39:31.395
Was ausgewählt wurde, ist unknown. Und unknown ist das etwas striktere any.

00:39:32.775 --> 00:39:38.155
Also man muss sich das TypeScript-Typ-System so vorstellen, dass du versuchst,

00:39:38.295 --> 00:39:42.995
in jedem Wert, der existiert, in einer Wertemenge zu klassifizieren.

00:39:43.255 --> 00:39:45.595
Also du kannst sagen, dieser eine Wert ist zum Beispiel ein String,

00:39:46.035 --> 00:39:47.595
dieser andere Wert ist eine Number.

00:39:48.195 --> 00:39:53.055
Dann gibt es verschiedene Objektwerte, die man mit entsprechenden Objekttypen klassifizieren kann.

00:39:53.235 --> 00:39:56.675
Und die bewegen sich alle in einer ganzheitlichen Menge.

00:39:56.955 --> 00:40:01.835
Und die Aufgabe vom Typsystem in TypeScript ist, dass du in dieser Menge richtig

00:40:01.835 --> 00:40:07.195
navigierst, um richtig zu validieren, ob dieser Wert auch dieser einen Teilmenge davon entspricht.

00:40:08.495 --> 00:40:12.415
Und da gibt es jetzt zwei Typen, die die gesamte Menge darstellen.

00:40:13.435 --> 00:40:17.915
Jeder Wert ist kompatibel zu diesem Typ. Das eine ist Any und das andere ist Unknown.

00:40:17.915 --> 00:40:21.415
Und dann ist ein bisschen so ein Ausbruch gewesen aus TypeScript,

00:40:21.655 --> 00:40:24.715
um mit dem, was in JavaScript tatsächlich passiert, auch umgehen zu können,

00:40:24.815 --> 00:40:25.775
weil in JavaScript passiert halt

00:40:25.775 --> 00:40:32.775
einmal sehr viel, das am Typsystem aktiv entgegenwirrt, sagen wir mal so,

00:40:33.355 --> 00:40:39.555
und heißt das, dass jeder Typ zu Any-Kompatibel oder jeder Wert ist zu Any-Kompatibel

00:40:39.555 --> 00:40:44.635
und du kannst auch, so wie dieser Wert mit Any-Kompatibel ist,

00:40:44.855 --> 00:40:46.375
auch alles damit machen.

00:40:46.375 --> 00:40:49.995
Du kannst dir das Property aufrufen, du kannst ihn in jede Funktion reinstecken,

00:40:50.095 --> 00:40:51.555
du kannst einfach alles damit tun.

00:40:51.995 --> 00:40:56.395
Und weil das nicht besonders sicher ist, gibt es den Alternativtyp unknown.

00:40:57.275 --> 00:41:01.935
Unknown lässt dich gar nichts machen. Es ist zwar auch jeder Typ und jeder Wert

00:41:01.935 --> 00:41:06.635
mit unknown kompatibel, das heißt, jeder Typ ist eine Teilmenge von unknown,

00:41:07.535 --> 00:41:11.175
aber du darfst nicht, also eigentlich gar nichts damit machen,

00:41:11.275 --> 00:41:15.455
bevor du nicht konkreter angibst, welcher Subtyp das ist, indem du entsprechende

00:41:15.455 --> 00:41:20.335
Typeguards ausführst, wie, keine Ahnung, Type of String oder Property in irgendwas,

00:41:20.595 --> 00:41:22.475
also die ganzen Dinge, die man halt macht, um.

00:41:23.746 --> 00:41:26.686
Sich bewusster zu sein, welcher Typ dann tatsächlich dahinter steht.

00:41:26.906 --> 00:41:29.906
Und ich habe das sehr cool gefunden, also ich habe das jetzt schon einige paar

00:41:29.906 --> 00:41:32.966
Mal präsentiert, wie jetzt der Unterschied zwischen Annie und Unknown ist und

00:41:32.966 --> 00:41:34.226
wie sich das im Typsystem verhält.

00:41:35.266 --> 00:41:38.626
Und einer hat es ganz gut auf den Punkt gebracht, wie er gesagt hat.

00:41:41.866 --> 00:41:47.566
Tatsächlich widerspricht Annie somit dem Liskowschen Substitutionsprinzip,

00:41:47.746 --> 00:41:52.726
wo du eben sagen kannst, du kannst Dinge von einem, ich kann es nicht rezitieren

00:41:52.726 --> 00:41:54.446
in diesem Fall, Aber es geht darum,

00:41:54.746 --> 00:41:59.446
alles, was beim Übertyp möglich ist, soll auch beim Subtyp möglich sein.

00:41:59.826 --> 00:42:01.766
Ich glaube, das ist die Kernaussage davon.

00:42:02.726 --> 00:42:05.446
Mit Any stimmt das nicht, weil du kannst Dinge auf Any ausführen,

00:42:05.546 --> 00:42:07.666
die nicht auf den Subtypen ausführbar sind.

00:42:08.986 --> 00:42:13.386
Mit Anon bist du auch wieder in diesem Substitutionsprinzip drin.

00:42:13.726 --> 00:42:16.346
Das heißt, das entspricht wieder dem Substitutionsprinzip.

00:42:17.666 --> 00:42:22.606
Ich fand das extrem aufregend, auf welchem Niveau du gerade Anon erklärt hast.

00:42:22.606 --> 00:42:25.986
Und neigte schon zu dem Begriff akademisch und war jetzt drauf und dran,

00:42:26.066 --> 00:42:28.246
in diese Lisskopf-Diskussion einzusteigen.

00:42:28.406 --> 00:42:32.086
Das wäre dann noch akademischer und ich will deswegen nur in einem Satz dazu sagen.

00:42:34.099 --> 00:42:38.139
Ich glaube, ich würde nicht die Annahme treffen, dass alles andere ein Subtyp von Annie ist.

00:42:38.299 --> 00:42:41.719
Und in dem Moment, wo man diese Annahme nicht trifft, ist es auch wieder kein

00:42:41.719 --> 00:42:43.319
Widerspruch zu Gliscope.

00:42:43.939 --> 00:42:47.179
Also technisch schon in der Anwendung würde ich es auch nicht machen.

00:42:48.199 --> 00:42:51.219
Ich würde es andersrum sagen. Ich würde sagen, dass Annie ein Subtyp von allem

00:42:51.219 --> 00:42:55.399
anderen ist und nicht alles andere ein Subtyp von Annie. Naja,

00:42:55.459 --> 00:42:55.999
aber das stimmt ja nicht.

00:42:57.099 --> 00:43:03.119
Weil jeder beliebige Wert, den du nimmst, ist kompatibel zu Annie. Warte.

00:43:03.659 --> 00:43:08.159
Und das bedeutet nicht, meiner Meinung nach bedeutet das nicht,

00:43:09.139 --> 00:43:17.659
dass jeder beliebige Typ ein Kind von Annie sein muss, sondern das wäre auch

00:43:17.659 --> 00:43:19.139
andersrum der Fall, oder?

00:43:20.479 --> 00:43:23.099
Ja, das ist aber jetzt glaube ich ein assoziativer Typ, das heißt,

00:43:23.199 --> 00:43:25.699
du kannst halt quasi die... Nein, ist schwierig.

00:43:26.199 --> 00:43:28.499
Ja, ich glaube, das war der Partner. Ich glaube, es ist schwierig,

00:43:28.599 --> 00:43:32.019
weil tatsächlich... Also in meiner Blitzbirne ist Annie halt einfach ein Opt-out

00:43:32.019 --> 00:43:33.459
aus, was immer TypeScript da macht.

00:43:34.739 --> 00:43:39.659
Du hast zu versichten, du hast zum einen das Typsystem und wie die Typen angeordnet

00:43:39.659 --> 00:43:43.999
sind und du hast halt ganz klar der Obertyp über allem.

00:43:45.259 --> 00:43:49.539
Die Frage ist aber das, wie verhält es sich bei den Typchecks? nachher nicht.

00:43:50.039 --> 00:43:54.879
Und da ist tatsächlich dieser Cop-out. Da ist dieses, okay, was immer passiert,

00:43:55.399 --> 00:43:58.419
vertrau mir, ich mache das Richtige oder auch nicht, was auch immer.

00:43:58.799 --> 00:44:02.939
Und du deaktivierst sämtliche Checks, die der TypeScript gibt.

00:44:03.059 --> 00:44:05.539
Also das ist der tatsächliche Effekt davon. Genau.

00:44:06.159 --> 00:44:08.919
Von einem Ende. Das du eben bei anderen nicht hast. Aber in der Typ-Hierarchie

00:44:08.919 --> 00:44:11.139
ist trotzdem Ende noch über allen anderen Typen.

00:44:11.319 --> 00:44:17.439
Du hast ja auch unten Subtypen, die Subtypen von allen anderen Typen sind. Wie zum Beispiel Never.

00:44:17.859 --> 00:44:23.479
Also Never ist die leere Menge, da hast du keinen Wert drinnen und das ist tatsächlich

00:44:23.479 --> 00:44:27.179
eine Teilmenge von jeder anderen Menge und hat halt andere Regeln.

00:44:27.559 --> 00:44:30.679
Also da kannst du halt davon ausgehen, dass du, wenn du never hast,

00:44:30.859 --> 00:44:37.959
was ja per Definition keinen Wert hat, dann kannst du diese auch, wie ich rede es jetzt.

00:44:40.068 --> 00:44:44.328
Ich erkläre es gar nicht. Naja, ich kann... Warum ist es einfach so nicht?

00:44:44.748 --> 00:44:47.728
Ich kann gleich mal erklären, warum es dir so schwer fällt, das zu erklären.

00:44:48.668 --> 00:44:52.108
Ja, weil ich mein Chart nicht dabei habe. Das ist ein sehr visuelles Thema.

00:44:52.548 --> 00:44:57.268
Meine Analogie ist, ist immer das, never ist ja quasi die Null.

00:44:57.908 --> 00:45:00.488
Im Sinne von, das ist leer, da ist nichts.

00:45:01.488 --> 00:45:05.728
Und die Null ist ja tatsächlich... Die Leermenge, das ist wichtiger als wie

00:45:05.728 --> 00:45:08.108
Null, weil tatsächlich hast du ja null als Wert in gewissen Typen auch.

00:45:08.388 --> 00:45:11.048
Ja, ja, aber Indem ich Null als Wert habe, ist es ja ein Wert,

00:45:11.168 --> 00:45:12.008
ergo ist Null, nicht Null.

00:45:12.588 --> 00:45:14.468
Das Einzige, was wirklich nichts ist, ist ja never.

00:45:16.848 --> 00:45:20.408
Und ich finde halt eben sehr erhellend, wenn man sich halt irgendwie mal vor

00:45:20.408 --> 00:45:23.528
Augen führt, dass die Null ja tatsächlich etwas ist, was ja erstmal irgendwer

00:45:23.528 --> 00:45:27.148
erfinden musste. und dass halt irgendwie Weltreiche, wie irgendwie so die alten

00:45:27.148 --> 00:45:31.248
Römer und Konsorten, wunderbar klargekommen sind, ohne eine Null zu haben.

00:45:31.568 --> 00:45:34.808
Die haben halt keine, sagen wir mal, Operationen durchgeführt,

00:45:34.868 --> 00:45:38.388
die haben keine Mathematik und ähnliches betrieben, wo sie die Null für brauchten.

00:45:38.748 --> 00:45:41.348
Das haben halt die Araber gebraucht, die halt fancy Geometrie betrieben haben

00:45:41.348 --> 00:45:45.508
und von denen haben wir uns das halt hinterher geklaut, aber du kannst wunderbar

00:45:45.508 --> 00:45:47.788
den ganzen Tag klarkommen, ohne Null zu haben.

00:45:47.928 --> 00:45:51.348
Du musst nicht irgendwo aufschreiben, ich hab null Kühe, weil du hast halt keine

00:45:51.348 --> 00:45:54.068
Kühe, da ist halt nichts, da musst du nicht irgendwie ein Symbol für haben.

00:45:54.228 --> 00:45:56.748
Das brauchst du halt eben dann, wenn du halt irgendwie anfängst,

00:45:57.088 --> 00:46:00.028
okay, bescheuerte Edge-Cases zu machen, die eine Funktion, die immer eine Exception

00:46:00.028 --> 00:46:01.788
schmeißt, warum würde man das haben wollen?

00:46:02.028 --> 00:46:05.088
Oder halt eben, wenn du so Typ-Level-Programmierung machen willst und du willst

00:46:05.088 --> 00:46:07.688
irgendwie Dinge filtern, indem du sie auf Never-Maps.

00:46:07.868 --> 00:46:12.108
Aber das ist ja tatsächlich schon eine Meta-Ebene entfernt von dem,

00:46:12.188 --> 00:46:14.868
was man als normaler Mensch macht, wo man nämlich sagt, das ist ein Array aus

00:46:14.868 --> 00:46:16.808
Zahlen oder ein Array aus Fuß oder was auch immer.

00:46:17.388 --> 00:46:22.688
Und deswegen ist das halt immer so ein Kampf, das irgendwie einzuordnen in die

00:46:22.688 --> 00:46:24.588
Welt der real existierenden Dinge.

00:46:27.431 --> 00:46:30.791
Ich möchte aber noch kurz was dazu sagen, was der Hanses gesagt hat.

00:46:30.931 --> 00:46:36.491
Und zwar, ich verstehe, warum du das denkst, weil du kannst jetzt jeden Wert,

00:46:36.631 --> 00:46:39.111
der Any ist, zu jedem anderen Typ zuordnen.

00:46:39.411 --> 00:46:46.191
Und du kannst jeden anderen Typ zu einem Typ vom Typ Any zuordnen. Also das geht auch.

00:46:46.571 --> 00:46:49.671
Von dem her kannst du Any da beliebig einsetzen. Und du hast da die Idee,

00:46:49.831 --> 00:46:53.591
wo ist es in der Hierarchie, es kann überall sein. Aber tatsächlich ist es nur

00:46:53.591 --> 00:46:57.251
ein Seiteneffekt davon, dass keine Checks gemacht werden mit denen.

00:46:57.891 --> 00:47:02.151
Also das ist quasi dieses Copout-Feature. Das ist auch das, was mir als die

00:47:02.151 --> 00:47:03.531
Definition ganz schön gefällt.

00:47:03.731 --> 00:47:06.691
In dem Moment schaltest du TypeScript aus, da gibt es kein TypeScript.

00:47:06.691 --> 00:47:09.631
Alles, was diese Variable betrifft, ist TypeScript.

00:47:09.771 --> 00:47:12.551
Ganz vergessen. Ja, voll gut.

00:47:15.691 --> 00:47:20.231
Ich erinnere mich, dass ich schon mal bei euch zu Gast war und dass da ich dieses

00:47:20.231 --> 00:47:24.731
Projekt TS Reset irgendwie mal fallen gelassen habe, weil die so eine schöne Website haben.

00:47:25.251 --> 00:47:29.311
Und das ist für mich auch so im Kontext Unknown, lasse ich das gerne fallen.

00:47:31.511 --> 00:47:36.031
Irgendjemand hat die Entscheidung getroffen, dass in TypeScript die Funktion

00:47:36.031 --> 00:47:40.871
Fetch ein Promise zurückgibt, was mit Any Resolved.

00:47:41.591 --> 00:47:45.491
Und das bedeutet, dass in dem Moment, wo wir einen HTTP-Request mit nativen

00:47:45.491 --> 00:47:50.191
Wortmitteln machen, TypeScript uns quasi abgeschaltet ist für die Rückgabe davon.

00:47:50.631 --> 00:47:55.191
Und was TS-Reset unter anderem macht, ist eben das auf ein Unknown umzustellen,

00:47:55.271 --> 00:47:56.331
was letztendlich heißt,

00:47:56.771 --> 00:47:59.831
du musst erstmal prüfen, ob da wirklich das drin ist, was du erwartest,

00:47:59.931 --> 00:48:05.511
bevor du damit arbeiten kannst, was ich einen total guten Default finde an der

00:48:05.511 --> 00:48:06.671
Stelle gegenüber dem Any.

00:48:07.771 --> 00:48:10.091
Also es ist ganz eindeutig, warum.

00:48:11.126 --> 00:48:16.386
Das nicht in Typescript selbst sein kann, weil Typescript ja versucht,

00:48:17.226 --> 00:48:20.846
jeden JavaScript-Code, der funktioniert, auch weiterhin als funktionierend darzustellen

00:48:20.846 --> 00:48:22.826
und nur offensichtliche Fehler darstellen will.

00:48:23.026 --> 00:48:27.566
Und da hast du an dieser Grenze, wo du I.O.

00:48:27.586 --> 00:48:33.886
Hast, also wo der Punkt ist, wo du dich auf die Eingaben von Pritz-System verlässt

00:48:33.886 --> 00:48:38.206
oder auf eine Benutzereingabe oder was auch immer, also nicht Teil dieses Systems,

00:48:38.326 --> 00:48:40.626
das du dir aufgebaut hast, immer einen Bruch.

00:48:40.626 --> 00:48:44.746
Und mit diesen Brüchen geht TypeScript sehr, sehr lax um, bewusst,

00:48:45.206 --> 00:48:48.326
weil es ihm sagt, okay, in den meisten Fällen sorgt es für mehr Probleme,

00:48:48.446 --> 00:48:49.466
als wie sie tatsächlich lösen.

00:48:49.786 --> 00:48:53.346
Weil sie halt auch nicht davon ausgehen können, dass jeder halt irgendwie ausdefinierte

00:48:53.346 --> 00:48:54.966
Schemata für seine Endpoints hat.

00:48:55.306 --> 00:48:58.506
Ja, ganz genau. Oder du weißt ja gar nicht, ob du überhaupt irgendeinen Typen

00:48:58.506 --> 00:49:00.186
erwartest, wenn du einen Fetch Call machst.

00:49:00.266 --> 00:49:04.686
Vielleicht willst du ja einfach nur, keine Ahnung, sofort damit herumwerken und was tun.

00:49:04.926 --> 00:49:07.146
Von dem her verstehe ich, dass es nicht in TypeScript selbst ist.

00:49:07.406 --> 00:49:10.226
Aber genau deswegen sind so Projekte wie TS Reset eigentlich gut.

00:49:10.626 --> 00:49:13.966
Weil du dir diese Dinge nachher selbst schreiben kannst.

00:49:14.726 --> 00:49:17.486
Und das ist nicht einmal schwierig. Also in meinem Workshop mache ich das auch.

00:49:17.606 --> 00:49:21.746
Das ist ein Zehnzeiler, wo du das Interface vom Response-Buddy,

00:49:22.506 --> 00:49:26.886
mit einer anderen Methode überladest, die halt in der Anordnung der TypeScript-Methoden

00:49:26.886 --> 00:49:29.706
nachher die ist, die zieht und dann änderst du die Promise von Any auf Promise

00:49:29.706 --> 00:49:33.786
von Unknown und das Ding ist gestern und du hast ein Stück mehr Typsicherheit für das Ding.

00:49:34.506 --> 00:49:37.766
Also das ist ein Dreizeiler und das ist sehr, sehr effektiv.

00:49:38.646 --> 00:49:40.766
Und drum sollte man das auch.

00:49:42.139 --> 00:49:45.259
Glaube ich, über eine dritte Party-Bibliothek gut am einfachsten geschehen,

00:49:45.499 --> 00:49:46.419
selber schreiben, machen.

00:49:47.219 --> 00:49:51.059
Ich würde hier tatsächlich ein bisschen bei dem Anfangsstatement widersprechen.

00:49:51.579 --> 00:49:56.039
Ja, man kann TypeScript so konfigurieren, dass es allen JavaScript-Code schluckt,

00:49:56.259 --> 00:50:00.239
aber du musst dafür halt ein paar Settings in der TS-Config entsprechend setzen

00:50:00.239 --> 00:50:04.059
und es wäre durchaus legitim gewesen, dafür auch noch mal ein Setting zu machen.

00:50:04.399 --> 00:50:07.839
Absolut, ja. Und in default ist es ja nicht schwer zu lösen.

00:50:09.639 --> 00:50:11.859
Also so ein bisschen denke ich immer wieder, ich fände es schön,

00:50:11.939 --> 00:50:15.119
wenn das, was TS-Reset macht, einfach TS-Config-Settings wären.

00:50:16.279 --> 00:50:20.079
Weil das das deutlich, die Chance deutlich erhöht, dass man das verbreitert bekommt.

00:50:20.359 --> 00:50:24.259
Und selbst wenn es per Default unknown wäre, hält mich ja nichts davon ab,

00:50:24.679 --> 00:50:28.999
beim Handeln des Promise dann wiederum den Any als Parameter in das Land zu

00:50:28.999 --> 00:50:31.059
schreiben. Und dann funktioniert auch alles so, wie ich es mir gewünscht habe.

00:50:31.939 --> 00:50:33.479
Also rauskommt man immer noch.

00:50:34.819 --> 00:50:38.879
Aber ist auch nur mi, mi, mi. Und jammer auf hohem Niveau.

00:50:41.301 --> 00:50:44.761
Es ist so cool, ich gehe gerade die Feature-Liste von TS Reset durch und das

00:50:44.761 --> 00:50:47.941
sind im Grunde meine Blog-Artikel, die ich rund um 2021 geschrieben habe.

00:50:51.081 --> 00:50:55.161
Aber ich glaube, ich habe deinen Blog lange nicht gelesen.

00:50:55.261 --> 00:50:58.741
Ich habe den übrigens früher sehr häufig beworben. Ja, da habe ich einiges gelesen.

00:50:59.201 --> 00:51:00.841
Ja, da habe ich einiges gelesen.

00:51:03.421 --> 00:51:07.021
Und ich bin mir aber relativ sicher, das Design von TS Reset ist schöner als

00:51:07.021 --> 00:51:10.081
das von deinem Blog-Artikel dazu. Ich finde einfach immer wieder geil,

00:51:10.221 --> 00:51:12.721
wie gut diese Website von PS3. Das ist mein Blog schon lange nicht,

00:51:12.741 --> 00:51:14.901
Maxime. Der ist jetzt super fisch.

00:51:16.861 --> 00:51:21.441
Oh, ich dachte, ich wüsste die Adresse auswendig. Warte, ich hätte fatlog.eu gesagt. Ist das falsch?

00:51:21.861 --> 00:51:26.201
Das müsste ich jetzt weiterleiten auf eudat.dev. Vielleicht ist die Domainer schon wieder weg.

00:51:26.661 --> 00:51:29.901
Nee, die ist noch da. Funktioniert noch. Ich war einfach nur zu blöd zu tippen.

00:51:30.141 --> 00:51:31.841
Also es leitet nicht weiter. Vielleicht willst du das machen,

00:51:31.901 --> 00:51:32.681
sondern ist jetzt ein Alias.

00:51:33.261 --> 00:51:39.001
Ja, das ist okay. Alias ist okay. Ich gebe ein feuchtes Irgendwas drauf auf Domains.

00:51:39.281 --> 00:51:42.701
Das, was früher mal Suchmaschinenoptimierung war, das haben wir ja alles nicht

00:51:42.701 --> 00:51:44.901
mehr. Ja, genau. Da war ich einfach schon,

00:51:46.334 --> 00:51:51.474
Da war ich einfach schon fortschrittlich denkend, indem ich einfach drauf pfiffen habe. So.

00:51:53.294 --> 00:51:56.714
Dein letzter Blogartikel ist zu TypeScript. Das ist ja wunderschön.

00:51:56.814 --> 00:51:59.474
Das müssten wir eigentlich auch noch einbauen. Echt? Ist das wirklich ein Blogartikel?

00:51:59.674 --> 00:52:01.014
Ah, nee, Writtenartikel sind TypeScript.

00:52:01.114 --> 00:52:04.654
Das war explizit die Kategorie TypeScript. Schön guten Morgens.

00:52:07.314 --> 00:52:11.694
Irgendwelche nicht offensichtlichen Anwendungsfälle, wo ihr Unknown rausholt?

00:52:11.874 --> 00:52:14.614
Außer jetzt, um es zu resetten? Oh ja.

00:52:15.474 --> 00:52:21.994
Oh ja, es gibt dieses wunderschöne Pattern von Type Assertions,

00:52:22.194 --> 00:52:30.254
wo ihr aber komplett Mumpitz macht, wo man eine Variable as unknown as any schreiben muss.

00:52:30.774 --> 00:52:34.934
Ne, as any nicht, aber as unknown und dann as ein komplett invalider Typ.

00:52:36.394 --> 00:52:41.514
Was passiert da? Ganz kurz. Du gehst in dieser Menge auf die größere und noch

00:52:41.514 --> 00:52:45.174
auf eine andere kleinere zu gehen. Und wenn diese beiden Submengen halt nicht

00:52:45.174 --> 00:52:47.014
miteinander kompatibel sind, kriegst du einen Fehler.

00:52:47.934 --> 00:52:52.474
Du kannst ja von zum Beispiel einer Menge aus ein paar nur mal auf die größere

00:52:52.474 --> 00:52:55.674
gehen, absolut kein Problem. Und auch umgekehrt, das erlaubt die dir nicht.

00:52:55.894 --> 00:52:59.794
Aber wenn du mit zwei komplett adjazenten Mengen zu tun hast,

00:52:59.874 --> 00:53:02.354
die keine Schnittmenge haben, erlaubt dir das TypeScript nicht.

00:53:02.514 --> 00:53:06.114
Was tust du? Du gehst zuerst auf die größere, any oder an, und da siehst du

00:53:06.114 --> 00:53:12.154
wieder, dass das eben die Supermenge ist und reduzierst dann auf eine andere. Das ist herrlich.

00:53:13.494 --> 00:53:16.894
Also das ist dann so dieser kaputte Use-Case von Unknown auf jeden Fall.

00:53:17.454 --> 00:53:18.994
Und die Leute machen das mit dem

00:53:18.994 --> 00:53:22.374
Unknown, weil Any ja in ihrem statischen Code-Analyse-Tool verboten ist.

00:53:23.714 --> 00:53:30.134
Ja, es ist so schön, wie diese gesamte Theorie nachher mit pragmatischen Mitteln vorgeführt wird.

00:53:31.094 --> 00:53:33.674
Ich verstehe das aber auch und ich finde das auch gar nicht so schlecht.

00:53:33.814 --> 00:53:34.554
Also ich sage auch ständig,

00:53:35.394 --> 00:53:42.974
macht ihr das und seid euch nur bewusst, dass ihr später, wenn ihr irgendein

00:53:42.974 --> 00:53:46.434
Problem damit habt, diese Dinge wieder leicht finden können solltet.

00:53:46.434 --> 00:53:51.454
Und da ist dieses S-Keyword herrlich dafür, weil du kannst einfach über Textsuche

00:53:51.454 --> 00:53:55.674
nach Lehrzeichen, S-Lehrzeichen suchen und du findest alle Stellen,

00:53:55.734 --> 00:53:56.954
wo du potenziell Probleme hast.

00:53:57.874 --> 00:54:03.074
Und das ist für mich ein sehr, sehr wertvoller Workflow. Mach mit dem Typsystem, was du willst.

00:54:03.394 --> 00:54:08.274
Dazu ist es so flexibel und dazu kannst du es so schön biegen und teilweise auch brechen.

00:54:09.174 --> 00:54:13.774
Sei dir nur bewusst, dass wo du es brichst, dass du diese Dinge später wieder findest.

00:54:13.934 --> 00:54:16.294
Das ist ein viel, viel besserer Zugang, als wenn man sich an keine Ahnung,

00:54:16.294 --> 00:54:20.814
wie viele Linting-Rules oder Typescript-Typ-Kompatibilitäten hält.

00:54:21.094 --> 00:54:25.634
Also pragmatisch arbeiten, auf das Ziel hin arbeiten, aber sichtbar machen, was schief gehen kann.

00:54:25.834 --> 00:54:29.894
Wenn man sich nämlich zu viel Korsett baut, mit irgendwie Any-radikal verbieten,

00:54:30.254 --> 00:54:31.754
dann führt das halt nur zu Workarounds.

00:54:32.074 --> 00:54:35.074
Und die sind dann halt eben schwieriger zu findende Versionen von dem,

00:54:35.154 --> 00:54:37.034
was man mit Any gemacht hätte. Ganz genau.

00:54:37.514 --> 00:54:40.794
Und darum, also Any ist ja für mich auch ein super Indikator. Ich liebe das.

00:54:41.814 --> 00:54:45.734
Ich lese ja mehr Code, als wie ich schreibe nicht. und als wie,

00:54:45.814 --> 00:54:50.514
Entschuldigung, das ist eine sehr österreichische Aussage, ich lese mehr Code,

00:54:50.574 --> 00:54:52.934
als ich schreibe. Und ja.

00:54:55.120 --> 00:54:59.640
Und für mich sind solche Sachen irrsinnig gute Indikatoren. Wenn ich irgendwo

00:54:59.640 --> 00:55:03.000
Annie sehe, dann schaue ich da drauf und dann versuche ich zu verstehen, was da passiert.

00:55:03.340 --> 00:55:06.460
Oder im besten Fall geben Leute eine sehr, sehr gute Dokumentation mit,

00:55:06.500 --> 00:55:08.560
was da passiert und warum sie auf Annie gegangen sind.

00:55:08.960 --> 00:55:12.340
Also das sind alles Indikatoren für Dinge, wo du mit einem Typsystem,

00:55:12.420 --> 00:55:18.120
das sowieso ja nur drangenagelt ist und versucht mitzulaufen mit etwas,

00:55:18.180 --> 00:55:22.260
was schon existiert und auch immer mit etwas mitlaufen wird, was schon existiert,

00:55:24.300 --> 00:55:28.300
sind genau die Dinge, wo du merkst, wo diese beiden Welten brechen.

00:55:28.560 --> 00:55:31.080
Und nichts ist wertvoller als wie ein Zeichen, wo es bricht.

00:55:31.480 --> 00:55:34.740
Und das haben wir leider überall. Das haben wir jetzt, wenn man mit einem Backend

00:55:34.740 --> 00:55:36.620
redet oder auf User-Input wartest.

00:55:36.700 --> 00:55:41.800
Und das sind ja auch die spannendsten Dinge im Web, wenn es User-Input oder Backend-Bauten gibt.

00:55:43.000 --> 00:55:44.820
Sonst wäre es ja auf HD-JavaScript-Applikation.

00:55:46.440 --> 00:55:49.200
Also unser Ziel war jetzt, dass wir eine 4-Stunden-Folge aufnehmen,

00:55:49.340 --> 00:55:52.180
oder? Nein, du musst mit das nur 5 Uhr aufhören.

00:55:54.560 --> 00:55:58.980
Wir können ja in mehreren Sessions eine Vier-Stunden-Folge aufnehmen.

00:55:59.960 --> 00:56:05.300
Eine ganze Staffel zu Annie. Ich dachte jetzt mehr an eine Trilogie,

00:56:05.360 --> 00:56:07.580
eine Star Wars. Das Anlone schlägt zurück.

00:56:09.840 --> 00:56:13.920
Darth Generic rückt an mit seinem Annie-Zerstörer.

00:56:14.440 --> 00:56:19.300
Ich finde Annie ein super hilfreiches Mittel.

00:56:22.100 --> 00:56:25.880
Aber es gibt den Satz, die Dosis macht das Gift oder so.

00:56:26.140 --> 00:56:29.700
Also es gibt halt so Situationen, wo Annie wirklich hilfreich ist und wo es

00:56:29.700 --> 00:56:32.680
gut ist, dass wir es haben. Wo es notwendig ist, würde ich behaupten.

00:56:33.849 --> 00:56:37.329
Ja, aufgrund von Unzulhängigkeiten von Computern, aber ja, genau.

00:56:37.769 --> 00:56:39.149
Oder menschlichen Gehirn.

00:56:40.709 --> 00:56:45.489
Und trotzdem sind so 90 Prozent der Fälle, wo ich Annie sehe,

00:56:45.589 --> 00:56:49.189
wenn nicht mehr, eigentlich Red Flags und da hat jemand sich keine Gedanken

00:56:49.189 --> 00:56:52.169
gemacht oder da hat jemand sich keine Gedanken gemacht.

00:56:52.729 --> 00:56:56.549
Also ich kann übrigens voll damit leben, wenn jemand den Kommentar in Annie

00:56:56.549 --> 00:56:59.389
verwendet und drüber schreibt, ich laff das nicht, ich weiß nicht,

00:56:59.449 --> 00:57:01.269
wie ich den korrekten Typescript schreiben soll.

00:57:01.429 --> 00:57:05.189
Oder ich habe das probiert und nach 30 Zeilen Typings habe ich beschlossen,

00:57:05.289 --> 00:57:07.449
dass ich jetzt Annie dran schreibe, mich auch voll feindet.

00:57:09.669 --> 00:57:16.429
Aber sich keine Gedanken gemacht zu haben oder Faulheit sind so Sachen,

00:57:16.549 --> 00:57:18.389
wo ich echt allergisch auf Annie reagiere.

00:57:18.489 --> 00:57:22.629
Und die Grenze zwischen Faulheit und Pragmatismus wo es ist halt erstens schwammig

00:57:22.629 --> 00:57:24.889
und zweitens von Person zu Person unterschiedlich.

00:57:27.109 --> 00:57:30.129
Ja, aber dann machst du das, was du halt in jeder verkeilgten Organisation machst

00:57:30.129 --> 00:57:34.009
und dann muss man halt irgendwie zu Papier bringen, in einen Kommentar schreiben

00:57:34.009 --> 00:57:35.569
oder so, warum da jetzt Annie dran steht.

00:57:36.349 --> 00:57:39.509
Also entweder irgendwie, wenn ich halt irgendwie so die Situation habe,

00:57:39.629 --> 00:57:42.869
wo das ist es jetzt nicht wert, gegen den Compiler zu Felde zu ziehen,

00:57:42.989 --> 00:57:46.409
das ist jetzt Annie, weil ich weiß, dass es funktioniert, dann schreibe ich das da halt eben dran.

00:57:46.869 --> 00:57:49.709
Oder wenn ich irgendwie so Datenmutationen mache, die man nicht machen sollte,

00:57:49.709 --> 00:57:54.189
dann nenne ich meine Funktion immer unsafe dofu oder sowas, damit man halt irgendwie

00:57:54.189 --> 00:57:57.069
so nach unsafe grabben kann und dann halt irgendwie so die Funktionen findet,

00:57:57.249 --> 00:57:59.349
die halt für seltsame Mutationen sorgen.

00:58:00.549 --> 00:58:03.729
Aber es ist halt einfach so ein Feature, das unter Rechtfertigungsdruck steht.

00:58:03.909 --> 00:58:06.069
Aber man kann ja eine Rechtfertigung drüber schreiben. Das kostet ja nichts.

00:58:06.349 --> 00:58:08.449
Und da finde ich durchaus so diese Idee ganz schön zu sagen,

00:58:08.529 --> 00:58:10.829
man verbietet halt any per statische Code-Analyse.

00:58:13.689 --> 00:58:16.329
Und deaktiviert das aber an den paar Stellen, wo man es deaktivieren will,

00:58:16.469 --> 00:58:18.989
mit einer weiteren Regel, die sagt, du erklärst bitte warum.

00:58:19.449 --> 00:58:23.089
Und dann schreiben Leute halt Quatsch in den Kommentaren, hat das alles auch

00:58:23.089 --> 00:58:24.929
nichts gebracht, aber trotzdem, also ich finde es so, so,

00:58:26.368 --> 00:58:28.868
Den Default zu haben, wir verbieten das und erlauben Ausnahmen,

00:58:28.968 --> 00:58:33.128
finde ich besser, als zu sagen, macht mal, aber seid euch sicher, was ihr tut.

00:58:33.528 --> 00:58:36.728
Es kommt halt darauf an, wie prävalent in deiner Codebase hinterher die Ausnahmen

00:58:36.728 --> 00:58:38.688
sein werden. Wie bitte was?

00:58:39.808 --> 00:58:41.948
Wie häufig die vorkommen, wie häufig du Ausnahmen brauchst.

00:58:43.148 --> 00:58:47.248
Prävalent war das Wort? Mhm. Dann schreibe ich mir gleich mal auf und google gleich. Okay, ja.

00:58:48.788 --> 00:58:51.268
Also, weil ich habe halt durchaus so Codebases, wo das halt irgendwie gar nicht

00:58:51.268 --> 00:58:53.088
vorkommt, weil ich halt einfach nicht Daten mutiere.

00:58:53.088 --> 00:58:56.228
Und dann gibt es halt welche, wo ich einfach so, man beginnt mit einem riesigen

00:58:56.228 --> 00:59:00.268
Array und das Endprodukt ist das gleiche Objekt, aber halt mit 7000 Modifikationen

00:59:00.268 --> 00:59:03.268
angefügt, dann müsste man halt, wenn man das mit TypeScript machen würde,

00:59:03.508 --> 00:59:05.008
was ja wahrscheinlich der erste Fehler wäre,

00:59:05.408 --> 00:59:08.548
halt in jeder Funktion sagen, ja, der Input ist eigentlich ein Any oder ein

00:59:08.548 --> 00:59:11.748
Array von Any oder irgendwie sowas, weil man halt ständig diese Dinger mutiert.

00:59:15.464 --> 00:59:19.204
Und davon wird man es dann abhängig machen, ob das vielleicht ein sinnvolles

00:59:19.204 --> 00:59:20.484
Verbot-Dings ist oder so.

00:59:21.384 --> 00:59:24.904
Generell denke ich mir halt öfter mal bei Type-Checkern und Lintern und so.

00:59:26.504 --> 00:59:29.704
Kollege, ihr von der Blech-Fraktion wollt eigentlich mal so langsam mit eurer

00:59:29.704 --> 00:59:31.264
künstlichen Intelligenz um die Ecke kommen.

00:59:31.484 --> 00:59:34.284
Und du beschwerst dich jetzt darüber, dass ich hier irgendwie Wild-Schuhe habe

00:59:34.284 --> 00:59:38.284
mit einem offensichtlichen Break zwei Zeilen tiefer und du meckerst dir trotzdem.

00:59:38.644 --> 00:59:39.444
Sag mal, was soll das denn?

00:59:40.404 --> 00:59:42.924
Ich habe jetzt gerade nachgeschaut, während Sie gesprochen haben,

00:59:43.004 --> 00:59:46.704
Sie war vor drei Monaten, ziemlich auf dem Tag genau vor drei Monaten,

00:59:47.324 --> 00:59:50.484
habe ich eine sehr lange Diskussion von fünf Leuten gelesen.

00:59:50.764 --> 00:59:53.944
Also bin ich in einem Slack-Trad dazugekommen. Da geht es darum,

00:59:54.184 --> 00:59:58.324
dass, ja, irgendwo gibt es halt einen Any-Wert und den darfst du nicht auf einer anderen Stelle.

00:59:58.444 --> 01:00:01.424
Das ist ein irrsinnig komplizierter Type und Sie fragen, okay,

01:00:01.444 --> 01:00:04.804
wie können Sie dort jetzt am Workaround machen, damit der Linter dort nicht

01:00:04.804 --> 01:00:09.364
schreit und damit der Code dann funktioniert, weil der Code wäre an und für

01:00:09.364 --> 01:00:11.824
sich korrekt und braucht man andere Typen,

01:00:11.984 --> 01:00:13.804
braucht man ein anderes Interface, braucht man andere Funktionen,

01:00:13.864 --> 01:00:15.244
braucht man einen anderen Assignment-Vorgang.

01:00:15.524 --> 01:00:18.124
Fünf Leute diskutieren, haben nachher sind ganz im Fuss gekommen,

01:00:19.004 --> 01:00:21.784
haben mich inkludiert und ich habe gesagt, trotz der Linting-Hole,

01:00:21.884 --> 01:00:22.644
die ist sowieso ein Scheiß.

01:00:23.844 --> 01:00:25.064
Und so einfach geht es.

01:00:27.724 --> 01:00:31.584
Das war die No-Unsafe-Assignment-Linting-Hole und in diesem speziellen Case

01:00:31.584 --> 01:00:34.464
war die halt sehr unangenehm.

01:00:34.664 --> 01:00:36.944
Man kann den Computer abschalten. Das geht.

01:00:39.064 --> 01:00:41.904
Und ich denke, den Effort, den Leute dort einigesickt haben,

01:00:41.984 --> 01:00:45.504
haben wir fünf Leute dort für mehrere Stunden diskutiert und ist einfach das

01:00:45.504 --> 01:00:48.364
nicht wert, wenn jeder weiß, okay, das funktioniert so und sie wissen,

01:00:48.444 --> 01:00:50.384
dass es funktioniert und es ist getestet und hin und her.

01:00:50.804 --> 01:00:53.424
Und da reden wir ja zwischen Typsicherheit und Testcases.

01:00:54.744 --> 01:00:57.284
Vor allem kommuniziert es mit einem Backend, da kriegst du sowieso dann irgendeine

01:00:57.284 --> 01:01:00.004
kaputte Backend-Message zurück, wenn der Typ nicht okay ist und den händeln

01:01:00.004 --> 01:01:01.124
sie ja sowieso im nächsten Fall.

01:01:01.124 --> 01:01:05.384
Also, ah, seht es halt so, dass euer Programm funktioniert und kümmert euch

01:01:05.384 --> 01:01:09.144
halt mal ein bisschen weniger darum, ob euer Puppenhaus aus DevTools richtig

01:01:09.144 --> 01:01:10.944
angestrichen ist. Meine Güte.

01:01:14.017 --> 01:01:18.717
Ja, letztens hatte ich übrigens einen sehr ulkigen Fall, da ist leider der entsprechende

01:01:18.717 --> 01:01:20.317
Teilnehmer im Workshop nicht aufgetaucht.

01:01:20.457 --> 01:01:24.677
Der hatte explizit in die Agenda diktiert, ich möge doch bitte schön herausarbeiten,

01:01:24.857 --> 01:01:30.017
warum eine Type Assertion via irgendwas als irgendwas anderes schlechter lesbar

01:01:30.017 --> 01:01:32.017
sei als die Spitzklammer-Syntaxe.

01:01:33.273 --> 01:01:37.033
Dann hat er einfach zwei komplett unterschiedliche Fälle. Gennet was?

01:01:37.373 --> 01:01:41.813
Wie? Nee, nee, nee. Du kannst ja irgendwie sagen, so Variable as any.

01:01:41.913 --> 01:01:44.853
Oder du kannst natürlich auch davor schreiben, Spitzklammer, Number, Spitzklammer.

01:01:45.073 --> 01:01:48.433
Also das, was wie ein Cast funktioniert. Ja, genau.

01:01:49.793 --> 01:01:52.793
Genau, wie so eine Typumwandlung. Ich halte zum Beispiel PHP ja auch nur halt

01:01:52.793 --> 01:01:54.253
eben mit Runden statt mit eckigen Klammern.

01:01:56.873 --> 01:02:00.353
Und erst mal fand ich super, dass es Leute gibt, die das noch benutzen.

01:02:01.213 --> 01:02:05.353
Zweitens React-Inkompatibilität. natürlich auch super, wegen so JSX-Spitzklammern.

01:02:06.233 --> 01:02:09.173
Drittens erstmal so festgestellt, ah, guck mal, mein Syntax-Highlighter kann das gar nicht.

01:02:09.333 --> 01:02:12.713
Und dann halt erstmal auch festgestellt, so okay, die ganze Toolchain hat diesen

01:02:12.713 --> 01:02:16.593
Fall nie berücksichtigt, der Parser kann das gar nicht, weil das halt einfach

01:02:16.593 --> 01:02:19.553
so ein olles Teil ist aus irgendwie der ersten Version von TypeScript.

01:02:20.593 --> 01:02:22.273
Und Wiederfindbarkeit, zwischen

01:02:22.273 --> 01:02:24.773
einem React-Code bis nach einer spitzen Klammer, wie er steppert, ne?

01:02:26.873 --> 01:02:30.513
Ja, das war ein Angular-Shop, deswegen war das da nicht. Leider war der Teilnehmer

01:02:30.513 --> 01:02:33.253
den ganzen Workshop nicht da, sodass ich ihn nie darauf festnageln konnte.

01:02:34.113 --> 01:02:37.333
Und der Rest halt halt nur sogar, ja, ja, der hat halt so seine originellen Meinungen.

01:02:37.893 --> 01:02:41.353
Aus der Philosophie Sicht ja eine tolle Frage, da kann man ewig drüber diskutieren,

01:02:41.433 --> 01:02:43.533
weil es ist spannend, herrlich.

01:02:44.293 --> 01:02:48.493
Nee, komm, das ist einfach so ein Fall von, keine Ahnung, Eaps vs.

01:02:48.573 --> 01:02:51.793
Space, das ist doch genau das Gleiche. Es ist doch alles bloß hier Sonntagsgefriemel

01:02:51.793 --> 01:02:54.393
und das kann man besser finden oder nicht, aber am Ende geht es ja darum,

01:02:54.813 --> 01:02:56.353
was sagt das Ding denn aus?

01:02:56.893 --> 01:03:00.513
Und keine Ahnung, wenn der komische Typ jetzt hier mein Boss gewesen wäre und

01:03:00.513 --> 01:03:02.693
er würde sagen, wieso muss man das schreiben, dann würde ich sagen,

01:03:02.873 --> 01:03:05.713
du bist komisch, ich schreibe das halt so, ist mir egal, Hauptsache,

01:03:05.933 --> 01:03:08.953
ich kann mich hier um die eigentlich wichtigen Dinge kümmern.

01:03:09.373 --> 01:03:13.273
Der Kiki seufzt schon die ganze Zeit, ich glaube, ihm liegt echt was am Herzen gerade.

01:03:14.193 --> 01:03:17.833
Ich muss ja dazu sagen, dass ich eventuell in dieser Liste der Themen vorhin

01:03:17.833 --> 01:03:21.273
explizit das Thema Type Assertions aufgenommen habe und ich finde es schön,

01:03:21.353 --> 01:03:24.153
dass wir da jetzt aus Versehen hingekommen sind.

01:03:26.548 --> 01:03:30.528
Type Assertions und auch diese Spitzenklammern haben für mich ein Problem.

01:03:31.488 --> 01:03:38.808
Ich habe das Gefühl, dass EntwicklerInnen, die aus richtigen Programmiersprachen

01:03:38.808 --> 01:03:40.808
kommen, Entschuldigung, das musste sein,

01:03:41.428 --> 01:03:47.228
die Erwartung haben, dass das ein Typecast ist, weil es im ersten Moment sehr

01:03:47.228 --> 01:03:49.768
ähnlich aussieht und sich auch sehr ähnlich anfühlt.

01:03:50.808 --> 01:03:54.188
Es aber was komplett anderes ist, nämlich es ist, lieber Compiler,

01:03:54.268 --> 01:03:57.368
du hast keine Ahnung, ich weiß es besser und falls ich mich doch irre,

01:03:57.468 --> 01:03:59.528
dann ist es meine Schuld, dass wir auf die Fresse fliegen.

01:03:59.768 --> 01:04:02.768
Ja, es ist so ein fundamentaler Unterschied.

01:04:02.908 --> 01:04:06.888
Es ist ein ähnlicher Syntax, aber es ist einfach ein komplett anderes Konzept,

01:04:07.068 --> 01:04:11.928
weil in den einen stehen halt einmal Bytes dahinter und das bedeutet,

01:04:12.108 --> 01:04:17.448
wenn du einfach eine so große Anzahl an Bytes in eine so große Anzahl steckst

01:04:17.448 --> 01:04:19.468
oder umgekehrt. Da gibt es halt einen Unterschied.

01:04:20.368 --> 01:04:22.908
Und beim anderen sagst du einfach nur im Compiler, hey, ich glaube,

01:04:23.108 --> 01:04:24.228
das ist was anderes, wie du glaubst.

01:04:25.208 --> 01:04:29.768
Ja, und es ist ja auch, wenn du einen Typecast in der einen oder anderen anderen

01:04:29.768 --> 01:04:36.468
Sprache machst, dann kannst du ja auch plötzlich Methoden aufrufen auf diesem

01:04:36.468 --> 01:04:39.568
Ding, die eigentlich gar nicht darauf existierten.

01:04:39.888 --> 01:04:42.868
Also wenn du irgendwie sagst, hier, ich habe einen User und ich castere den

01:04:42.868 --> 01:04:45.728
jetzt in einem Admin, dann kannst du die Methoden von Admin aufrufen.

01:04:45.788 --> 01:04:47.528
Das ist halt in TypeScript auch nicht der Fall.

01:04:47.988 --> 01:04:51.828
Und es wird ja auch nicht im Moment des Typecasts um die Ohren fliegen.

01:04:53.357 --> 01:04:56.737
Andere Programmiersprachen sagen dann zur Laufzeit, hey, dieser Typecast hier

01:04:56.737 --> 01:04:59.257
ist irgendwie kaputt, ich breche mal hier lieber ab, bevor du Quatsch machst.

01:04:59.737 --> 01:05:01.917
Und da TypeScript zur Laufzeit weg ist, passiert das eben auch nicht.

01:05:02.017 --> 01:05:06.317
Also deswegen ist nämlich dieses AS ähnlich wie das ADDI so ein richtig gutes,

01:05:06.597 --> 01:05:08.157
so ein richtig hilfreiches Werkzeug,

01:05:08.497 --> 01:05:12.217
wo über 90 Prozent der Anwendungen, die ich davon gesehen habe,

01:05:12.377 --> 01:05:14.877
aber einfach nicht hätten sein dürfen.

01:05:17.217 --> 01:05:20.497
Backend-Kommunikation, ich verstehe euren Punkt, ich glaube,

01:05:20.557 --> 01:05:22.877
das ist dann halt auch wieder so eine Abwägung von Pragmatismus.

01:05:24.417 --> 01:05:27.917
Also wenn ich jetzt eine Anwendung als Hobbyprojekt alleine im Keller schreibe,

01:05:27.957 --> 01:05:31.057
dann kann ich da auch gerne überall Annie an die Backend- Responses dran schreiben,

01:05:31.117 --> 01:05:31.837
das ist alles in Ordnung.

01:05:31.917 --> 01:05:34.197
Wenn ich jetzt Termin mit 200,

01:05:37.177 --> 01:05:41.017
Entwicklern an der gleichen Code-Basis arbeite, da will ich halt nicht,

01:05:41.097 --> 01:05:44.237
dass da überall Type-Assertions und Annies drinstehen, weil dann blicke ich

01:05:44.237 --> 01:05:44.877
irgendwie nicht mehr durch.

01:05:45.497 --> 01:05:49.137
Dann kann ich TypeScript auch sein lassen, kann ich jetzt etwas übertrieben vielleicht sagen.

01:05:49.277 --> 01:05:52.497
Dann kann ich auch JS-Doc verwenden. Doch bist du schon sehr nah an der Lösung

01:05:52.497 --> 01:05:55.837
dran, vielleicht sollte man TypeScript doch einfach sein lassen.

01:05:58.437 --> 01:06:01.757
Das ist natürlich ein bisschen scherzhaft jetzt gemeint. Ich verstehe dich.

01:06:02.997 --> 01:06:06.057
Bei mir nicht. Bei mir nicht. Es gibt halt da durchaus so Projekte,

01:06:06.097 --> 01:06:10.477
wo ich sage, da TypeScript dran zu dengeln, zieht einen Aufwand nach sich und

01:06:10.477 --> 01:06:12.317
einen Benefit an Typsicherheit.

01:06:13.857 --> 01:06:16.357
Wo das Verhältnis halt nicht gewahrt ist. Und dann sagt man lieber,

01:06:16.617 --> 01:06:18.317
holt mal Bier, dann machen wir es gleich in JavaScript.

01:06:18.837 --> 01:06:22.377
Hat man halt mit einigen Sachen mehr Schmerzen, mit anderen Sachen weniger.

01:06:22.517 --> 01:06:26.097
Und man kann durchaus ein Szenario sich überlegen, wo man sagt,

01:06:26.637 --> 01:06:28.377
unterm Strich lohnt sich der TypeScript tatsächlich nicht.

01:06:28.557 --> 01:06:31.277
Wenn man zum Beispiel wirklich irgendwie ganz viel mit nackten Web Components

01:06:31.277 --> 01:06:34.437
macht und irgendwie alles irgendwie ein String ist, dann bringt es das halt eben nicht.

01:06:34.697 --> 01:06:38.737
Dann kann man halt nur riesig viel Aufwand betreiben, um da irgendwie sich einem

01:06:38.737 --> 01:06:40.697
React-artigen Zustand anzunähern.

01:06:41.197 --> 01:06:42.677
Oder man kann sagen, da komme ich eh nicht hin.

01:06:43.457 --> 01:06:45.957
Machst du ein nacktes JavaScript, sparst du ja einen Compiler an der Toolstelle.

01:06:46.697 --> 01:06:49.817
Ich möchte noch ganz kurz auf etwas zugehen, was der Kiki jetzt gesagt hat. Ähm,

01:06:51.188 --> 01:06:54.968
Weil ich stimme dir ja sogar zu. Also ich stimme dir zu, dass wenn du jetzt

01:06:54.968 --> 01:06:59.928
200 Leute in einem Projekt hast und du hast lauter Typer-Sersals da drinnen,

01:07:00.188 --> 01:07:01.528
dann hast du irgendein Problem.

01:07:02.248 --> 01:07:06.468
Ich würde mal sagen, in den wenigsten Fällen ist das Problem die Typer-Sersals,

01:07:06.548 --> 01:07:08.468
sondern du hast wahrscheinlich ein organisatorisches Problem.

01:07:08.788 --> 01:07:12.128
Also warum gibt es diesen Divide zwischen Frontend und Backend,

01:07:12.228 --> 01:07:15.468
dass du hier überhaupt über Typen diskutieren musst?

01:07:16.548 --> 01:07:21.528
Oder sind die Dinge eh so nahe beieinander, dass die Leute, die diese Backend

01:07:21.528 --> 01:07:25.848
schreiben, eh wissen, was dort ankommt und du kannst eigentlich die Typ-Checks dort sparen.

01:07:27.368 --> 01:07:30.708
Am schönsten ist immer, wenn du ein Node-Backend und ein JavaScript-Frontend

01:07:30.708 --> 01:07:33.268
hast und du einfach in der Mitte die Typen hast und du schickst auf der einen

01:07:33.268 --> 01:07:35.768
Seite das mit dem Typen raus und empfängst es auf der anderen Seite,

01:07:36.088 --> 01:07:38.428
brauchst du keinen weiteren Check machen, ob das stimmt oder nicht.

01:07:38.528 --> 01:07:42.828
Das garantiert dir ja dein eigener Code und deine eigenen Typ-Checks auf beide Seiten.

01:07:43.588 --> 01:07:49.568
Und von dem her kommt dieses Überprüfen der Backend-Ergebnisse auch immer auf

01:07:49.568 --> 01:07:51.848
den Umstand an, wie du organisatorisch aufgestellt bist.

01:07:52.468 --> 01:07:57.188
Ich sage zum Beispiel bei uns in der Organisation, wir verwenden SORT ziemlich oft.

01:07:57.368 --> 01:08:00.888
Das ist so eine Pass-Not-Valitate-Bibliothek, die ist cool,

01:08:01.368 --> 01:08:04.828
die ist typsicher, die gibt super Ergebnisse und ich habe gesagt,

01:08:05.208 --> 01:08:09.628
die ist so schwer und macht so langsame Serverless-Functions,

01:08:09.848 --> 01:08:12.868
nutzt die wirklich nur, wenn du sie euch nicht auf das Backend verlassen könnt,

01:08:12.968 --> 01:08:13.888
mit dem ihr kommuniziert.

01:08:16.070 --> 01:08:18.410
Und das machen sie jetzt auch nicht. Also überall, wo wir eine Drittparty haben,

01:08:18.490 --> 01:08:21.350
ist das Ding drinnen. Übrigens, wo wir eine First- oder Second-Party reden, nicht.

01:08:22.910 --> 01:08:27.990
An der Stelle würde ich einen kurzen Werbeeinschub für einen Podcast von vor

01:08:27.990 --> 01:08:29.210
einem Jahr ungefähr machen.

01:08:29.610 --> 01:08:35.070
Revision 639, Server-Client-Kommunikation mit TypeScript vom Working Graph Podcast,

01:08:35.570 --> 01:08:37.270
wo auch SOT erwähnt wird.

01:08:38.030 --> 01:08:41.650
Und ich, ach und da kann man auch TS Reset vor, sehe ich gerade.

01:08:41.650 --> 01:08:46.230
Ich würde da einen Punkt zu der internen Kommunikation noch hinzufügen.

01:08:47.030 --> 01:08:52.370
Man sollte dann halt in irgendeiner Form früh genug mitbekommen,

01:08:52.470 --> 01:08:54.410
wenn das Backend-Mux zurückliefert.

01:08:54.930 --> 01:08:58.910
Also wenn das Backend plötzlich mit einer HTML-Seite als Fehlermeldung antwortet

01:08:58.910 --> 01:09:01.850
statt mit JSON, dann fliegt das JSON-Pass schon um die Ohren.

01:09:01.850 --> 01:09:04.630
Aber es kann ja auch sein, dass es in der JSON-Response antwortet,

01:09:04.710 --> 01:09:07.670
wo irgendwie Success-False drinsteht.

01:09:07.870 --> 01:09:11.930
Und wenn dann aber mein Code annimmt, das funktioniert alles, dann ist es halt doof.

01:09:12.450 --> 01:09:17.550
Da mach zum Ersten mal richtige HTTP-Status-Codes. Das ist das erste Kommunikationsproblem, das du hast.

01:09:17.790 --> 01:09:21.950
Du darfst nicht ein Success reingeben in eine Information über den Success innerhalb

01:09:21.950 --> 01:09:26.090
von der Payload, sondern eine Information über den Success kommt über den Status-Code

01:09:26.090 --> 01:09:28.130
mit und dann wird das auch auf einer anderen Stelle abgefragt.

01:09:28.190 --> 01:09:31.310
Das kannst du auch super überprüfen. Du kriegst in der Response diese Information mit.

01:09:31.850 --> 01:09:36.730
Noch bevor du dort Chasing aufhugst, also bevor du diesen schweren Weg des Passens

01:09:36.730 --> 01:09:41.190
des Ergebnisses angehst, kannst du schon überprüfen, ob das überhaupt sinnvoll

01:09:41.190 --> 01:09:42.210
war, was du kriegst oder nicht?

01:09:43.842 --> 01:09:47.582
Du musst es aber parsen. Also du musst halt den Status-Code prüfen.

01:09:47.742 --> 01:09:51.282
Das ist so. Ja, genau, weil der sieht in Headers und dort chasen geht ja nur auf den Body.

01:09:52.382 --> 01:09:55.002
Ja, man kann sich jetzt, glaube ich, auch stundenlang darüber streiten,

01:09:55.102 --> 01:09:58.262
ob das eine Fehlentscheidung ist, wie Fetch das handhabt oder nicht.

01:09:59.002 --> 01:10:01.442
Ich kann aber nachvollziehen, dass Menschen die Erwartung haben,

01:10:01.522 --> 01:10:06.142
wenn ich einen HTTP-Request mache und das Then von dem Fetch,

01:10:06.342 --> 01:10:13.502
also das Promise Resolved und nicht Throwed, dass dann das HTTP-Request erfolgreich war.

01:10:14.742 --> 01:10:19.062
Es ist ja auf eine gewisse Weise erfolgreich gewesen, weil du bist ja zum Server

01:10:19.062 --> 01:10:22.622
gekommen und hast dir im Worst Case da die Abfuhr eingefangen.

01:10:22.802 --> 01:10:25.722
Und das ist, glaube ich, ein Zustand, der zu unterscheiden ist zwischen,

01:10:25.962 --> 01:10:27.662
du befindest dich im Flugmodus.

01:10:28.482 --> 01:10:32.042
True und False ist halt nicht notwendigerweise so binär, wie man sich das vorstellt.

01:10:32.042 --> 01:10:36.302
Ich bin da auf deiner Seite, aber trotzdem, ich kann nachvollziehen,

01:10:36.422 --> 01:10:37.582
dass Menschen diese Erwartung haben.

01:10:37.722 --> 01:10:41.002
Also jetzt mal ganz ehrlich, wie viele JavaScript-Anwendungen habt ihr gesehen,

01:10:41.142 --> 01:10:45.162
in denen nicht der HTTP-Status-Code im Fetch überprüft wird?

01:10:45.422 --> 01:10:49.042
Oder ich meine, Error-Händling in JavaScript ist ja sowieso irgendwie sehr stiefmöglich.

01:10:49.042 --> 01:10:51.682
Du hast absolut recht, es ist aber keine Lösung jetzt zu sagen,

01:10:51.782 --> 01:10:58.802
wir werfen Errors in einer Programmiersprache, wo das Errorwerfen generell problematisch ist.

01:10:59.082 --> 01:11:03.222
Was man da macht ist, wenn man sich die Realität entsprechend vereinfacht,

01:11:03.542 --> 01:11:10.302
dann kann man sich dieser Programmiertechnik namens Abstraktion bedienen und dann läuft die Kiste.

01:11:10.302 --> 01:11:13.162
Dann machst du einfach hier einen Rapper um Fetch, den kannst du dann sogar

01:11:13.162 --> 01:11:15.962
irgendwie Get nennen, dann ist das noch kürzer, drei Buchstaben.

01:11:16.402 --> 01:11:19.202
Und dann machst du da drin halt eben, wenn die Response irgendwie doof ist,

01:11:19.302 --> 01:11:23.082
dann schmeißt das Ding auch eine Rejection raus. Das ist total easy, alles zu lösen.

01:11:23.342 --> 01:11:26.942
Aber so die Baseline, die im Browser wohnt, wie das Fetch, ist da schon mit

01:11:26.942 --> 01:11:28.122
einem anderen Maß zu messen.

01:11:28.122 --> 01:11:32.482
Das ist jetzt nicht zu 100% darauf ausgelegt, maximale Developer Convenience

01:11:32.482 --> 01:11:35.642
zu bieten, sondern das bildet erstmal ab, wie die Welt aussieht und die Welt

01:11:35.642 --> 01:11:39.262
sieht halt eben zwei unterschiedliche Möglichkeiten vor, ins Klo zu greifen,

01:11:39.342 --> 01:11:40.762
wenn du mit dem Server zu reden versuchst.

01:11:41.382 --> 01:11:42.822
Und die müssen dann unterschieden werden. Mehr.

01:11:44.858 --> 01:11:48.718
Also die Primären sind Request verlässt deinen Computer nicht und Request verlässt

01:11:48.718 --> 01:11:51.118
deinen Computer und geht dann irgendwie vor die Hunde.

01:11:53.698 --> 01:11:57.798
Und dann kannst du den letzten Fall ja doch differenzieren anhand von HTTP-Status-Codes.

01:11:59.018 --> 01:12:02.678
Oder Dinge, die im Body stehen. Wenn man ein richtiger Entwickler ist,

01:12:02.798 --> 01:12:03.478
dann natürlich auch das, ja.

01:12:06.938 --> 01:12:10.098
Also das Einzige, was ich sagen wollte, ist, auch bei einem internen Backend

01:12:10.098 --> 01:12:12.498
kann es halt mal sein, dass da Mumpids an Daten zurückkommen.

01:12:12.558 --> 01:12:15.618
Dann ist es schon schön, wenn die Anwendung so früh wie möglich dabei um die Ohren fliegt.

01:12:16.098 --> 01:12:20.818
Und ich glaube, da ist dann eine Frage von, nicht nur ist das Backend intern, sondern auch.

01:12:22.607 --> 01:12:26.747
Wie viel Vertrauen habe ich in das Backend? Oh, ich hätte tatsächlich diese

01:12:26.747 --> 01:12:31.387
Überlegung, um noch einen weiteren Galaxy-Brain-Level-Gedanken zu ergänzen.

01:12:32.147 --> 01:12:35.127
Also wenn wir jetzt erstmal schon mal davon ausgehen, dass wir ein Backend haben

01:12:35.127 --> 01:12:39.487
und das ist mehr oder minder intern, aber ein getrenntes System von unserem

01:12:39.487 --> 01:12:43.187
TypeScript, wenn das so unsere grundsätzliche Ausgangslage ist,

01:12:43.547 --> 01:12:48.447
würde ich ja tatsächlich mal in Frage stellen, inwiefern überhaupt TypeScript ein Monolith ist.

01:12:48.747 --> 01:12:52.367
Und ist es nicht vielmehr so, dass es sich bei dem, was wir als TypeScript wahrnehmen,

01:12:52.607 --> 01:12:56.127
mehr um so eine Wohngemeinschaft aus zwei Elementen handelt,

01:12:56.307 --> 01:13:02.387
wo einerseits YOLO JavaScript, alles kann, nichts muss existiert und eine andere, etwas seltsame,

01:13:02.747 --> 01:13:06.827
funktionale, statisch typisierte Sprache, die mit dem JavaScript zusammenarbeiten

01:13:06.827 --> 01:13:12.147
kann, aber wo trotzdem dieses Zweierteam nicht immer genau die gleiche Vorstellung

01:13:12.147 --> 01:13:14.247
davon haben muss, was die Realität ist.

01:13:14.467 --> 01:13:18.667
Ich will sagen, haben wir nicht so, selbst in Abwesenheit eines Backends ein

01:13:18.667 --> 01:13:22.747
Zusammenspiel aus zwei getrennten Systemen, ohnehin an der Backe,

01:13:23.127 --> 01:13:27.247
indem wir halt JavaScript im Browser haben und das Typsystem und die haben irgendwie

01:13:27.247 --> 01:13:30.507
so grob die gleiche Richtung, in die sie gehen, aber die können genauso gut

01:13:30.507 --> 01:13:33.227
zwei unterschiedliche Meinungen haben, wie zwei Piloten, die im Cockpit sitzen

01:13:33.227 --> 01:13:35.287
und der eine meint nach links, der andere meint nach rechts.

01:13:35.807 --> 01:13:39.247
Ich empfehle meinen Vortrag Lies with Hello Ourselves using Typescript,

01:13:39.487 --> 01:13:40.487
weil du kennst genau das.

01:13:40.747 --> 01:13:46.287
Ihr habt 15 bis 20 Zeilen Code geschrieben und ihr habt Typprobleme in jeder

01:13:46.287 --> 01:13:50.187
Zeile Code. Das ist also TypeScript kompiliert, TypeScript findet es super und

01:13:50.187 --> 01:13:51.687
das Programm crasht an jeder Zeile.

01:13:51.907 --> 01:13:55.367
Also das war meine Aufgabe und die Aufgabe ist nicht einmal so abwegig,

01:13:55.487 --> 01:13:57.347
also das ist jetzt nicht irgendwie ein...

01:13:59.453 --> 01:14:02.753
Großartig konstruiertes Beispiel oder so, sondern dann geht es um einen Fetch Call,

01:14:03.733 --> 01:14:09.433
über das wir ja gerade reden, das halt einfach sämtliche Type Guards oder Type

01:14:09.433 --> 01:14:12.333
Checks auslässt, wenn es darum geht, mit dem Ergebnis zu arbeiten und du hast

01:14:12.333 --> 01:14:14.173
halt irgendwo eine Zeile drinnen, die keinen Sinn macht,

01:14:14.673 --> 01:14:19.053
aber die passieren kann und genau deswegen geht alles in die Luft und selbst

01:14:19.053 --> 01:14:22.693
wenn du die Ergebnisse richtig bekommst, brauchst du nur auf die große zweite

01:14:22.693 --> 01:14:24.893
Sprachstelle von TypeScript eingehen, nämlich,

01:14:26.033 --> 01:14:30.893
Mutability auf Referenzen und hast halt dann den Wiss benannt.

01:14:31.013 --> 01:14:34.693
Du kannst ja Objekte in jede Funktion stecken, kannst den Typ innerhalb von

01:14:34.693 --> 01:14:39.033
dem Objekt typ-sicher komplett verändern und greifst nachher draußen auf Dinge

01:14:39.033 --> 01:14:42.353
zu, die nicht mehr stimmen und hast dann dort das Problem.

01:14:42.733 --> 01:14:46.453
Und das sind 15-Seine-Code oder 20 von mir aus, die brechen an jeder Stelle

01:14:46.453 --> 01:14:48.933
und das ist ein herrliches Problem, wo du alle Schwachstellen siehst,

01:14:49.073 --> 01:14:51.713
die halt aber tatsächlich in echten Code auftauchen.

01:14:52.273 --> 01:14:55.573
Und deswegen sage ich 100%ig recht, du hast absolut recht, das stimmt.

01:14:55.573 --> 01:14:59.753
Oder du versuchst auf iterative Weise ein Objekt zusammenzubauen aus irgendeiner

01:14:59.753 --> 01:15:01.193
wie auch immer gearteten Datenquelle.

01:15:03.013 --> 01:15:07.813
Das geht halt nicht, weil halt eben diese zwei WG-Bewohner halt eben nicht ein

01:15:07.813 --> 01:15:12.313
100% deckungsgleiches Weltbild von dem haben, was man macht und was geht und

01:15:12.313 --> 01:15:14.233
welche Operationen zu welchen Ergebnissen führen.

01:15:16.153 --> 01:15:19.313
So, und dann ist halt die Frage, dass mit dem Backend eigentlich das kleinere

01:15:19.313 --> 01:15:22.273
Problem, also ja, da fällt das dann auf und man ist halt meistens so,

01:15:22.453 --> 01:15:25.393
wie Stefan schon sagte, aufgrund den Lügen, die man sich gerne so einredet.

01:15:25.573 --> 01:15:30.553
Der Meinung, dass irgendwie unser WG-Mitbewohner und wir die exakt gleiche Perspektive

01:15:30.553 --> 01:15:33.853
auf die Welt haben, damit kann man halt wirklich relativ weit kommen,

01:15:33.933 --> 01:15:36.533
aber irgendwann stellt man fest, ach wir beide dachten, wir haben noch Spaghetti

01:15:36.533 --> 01:15:38.673
da und jetzt gibt es keine mehr. Pech.

01:15:41.142 --> 01:15:44.562
Der ganze Kack ist halt immer komplizierter, als man so meint.

01:15:45.482 --> 01:15:48.942
Und das ist ja allgemein auch einfach so eine Kiste bei TypeScript,

01:15:49.062 --> 01:15:53.542
wie oft man da dann in Rabbit-Holes einsteigt und es einfach unfassbar kompliziert wird.

01:15:53.662 --> 01:15:56.262
Und da dann einfach mal Annie dran schreiben, ist halt schon manchmal sinnvoll.

01:15:56.862 --> 01:16:02.042
Und wenn Unknown ist auch, tut das noch besser. Und damit haben wir die Kurve zurück zum Anfang.

01:16:02.402 --> 01:16:04.022
Super, danke, dass du wieder zurückgefunden

01:16:04.022 --> 01:16:05.902
hast. Ich war mir jetzt nicht sicher, wie man dort hinkommt.

01:16:08.562 --> 01:16:15.682
Aber ich glaube, einer geht noch, oder? Ich wollte noch meinen Unknown-Use-Case

01:16:15.682 --> 01:16:16.602
eigentlich noch einwerfen.

01:16:17.482 --> 01:16:20.522
Ich mache gleich wieder eine Überleitung. Ich gebe Mühe. Ja,

01:16:20.582 --> 01:16:24.022
alles klar, Herr Delling. Ich zähle auf Sie. Also, ich war heute beim Friseur,

01:16:24.082 --> 01:16:25.462
deswegen mache ich nicht mehr ganz so den Netzer.

01:16:25.842 --> 01:16:27.782
Also, was ich sagen wollte war Folgendes.

01:16:28.462 --> 01:16:33.082
Stellt euch vor, ihr baut eine JavaScript-Library mit natürlich TypeScript und

01:16:33.082 --> 01:16:36.682
eure Nutzerschaft besteht halt zur Hälfte aus TypeScript-Leuten und zur Hälfte

01:16:36.682 --> 01:16:40.702
aus JavaScript-Leuten, die das halt ohne den Benefit von so einem Typ-Checker

01:16:40.702 --> 01:16:42.622
benutzen. Mag es ja geben.

01:16:43.142 --> 01:16:48.042
General Public ist so eure Zielgruppe. Und jetzt baut ihr halt so eure Funktionen,

01:16:48.062 --> 01:16:51.022
die eure Library exportiert. Die nennen wir Foo.

01:16:51.862 --> 01:16:55.582
Und das ist einfach so, dass der eine einzige Public Export eurer Library.

01:16:57.002 --> 01:17:00.942
Wie gestaltet ihr die Typ-Annotation von dieser Funktion?

01:17:04.862 --> 01:17:09.362
Also, es gibt einen erwarteten Input-Typen, es gibt einen erwarteten Output-Typen

01:17:09.362 --> 01:17:13.822
und es ist halt so eine Library mit halt so reiner Funktion als Public-Facing-Consumable

01:17:13.822 --> 01:17:16.562
und ihr habt halt einen Haufen interne Funktionen, in die ihr halt eben dann

01:17:16.562 --> 01:17:19.222
die Inputs und so weiter reinsteckt, eine Funktionsverschachtelung.

01:17:22.580 --> 01:17:26.820
Sagt ihr in der Typsignatur eurer Funktion, jo, ich kriege hier einen Input

01:17:26.820 --> 01:17:29.340
und der Input ist vom Typ bla.

01:17:30.420 --> 01:17:35.560
Oder sagt ihr, dieser Input ist vom Typ unknown. Oder sagt ihr, irgendwas anderes.

01:17:37.560 --> 01:17:41.120
Nee, du hast recht. Wir sind hier eigentlich genau bei der Situation von gerade auch.

01:17:41.220 --> 01:17:44.360
Wenn diese Library von JavaScript entwickelnden Personen verwendet werden soll,

01:17:45.320 --> 01:17:47.280
dann ist der Wert ja unknown.

01:17:50.360 --> 01:17:51.740
Theoretisch könnte es ja sein, dass

01:17:51.740 --> 01:17:53.980
da irgendwer in irgendwelchen Blödsinn reinsteckt. Klar, kann passieren.

01:17:54.120 --> 01:17:59.620
Es ist genau, naja, es kommt davon, also die meisten Bibliotheken sind so,

01:17:59.740 --> 01:18:04.000
dass eigentlich jeder darauf pfeift, ob der Impot jetzt richtig ist oder nicht

01:18:04.000 --> 01:18:05.920
und du bist schuld, wenn du das falsch verwendest.

01:18:06.080 --> 01:18:10.080
Das ist ja nicht unser Anspruch. Wir wollen hier was bombensicheres machen.

01:18:10.540 --> 01:18:13.380
Stell dir vor, Stefan, du baust irgendwas, was wirklich fundamental ist,

01:18:13.600 --> 01:18:16.060
was am Ende alle Leute in deiner gewaltigen Company benutzen werden.

01:18:16.660 --> 01:18:19.400
Da willst du ja irgendwie schon sicherstellen, dass du irgendwie jetzt nicht,

01:18:20.480 --> 01:18:23.420
wie so gewisse irgendwelche Rassenbugs am Ende in die Nachricht...

01:18:23.420 --> 01:18:26.560
Ich möchte natürlich die gesamte Probleme auf die Anwender und Anwenderinnen

01:18:26.560 --> 01:18:27.400
geben und nicht auf mich.

01:18:27.540 --> 01:18:30.480
Natürlich ist das dann ein Level-Auch-Problem.

01:18:31.020 --> 01:18:34.360
Ja, ja. Aber ihr versteht, worauf ich mich ausschöpfe. Aber ich verstehe dich

01:18:34.360 --> 01:18:37.700
nicht. Es kommt darauf, was der Anspruch ist. Tatsächlich kann...

01:18:39.240 --> 01:18:42.260
Wir sind ja da genau wieder an dieser Grenze. Ich würde sogar eher sagen.

01:18:44.320 --> 01:18:47.540
Es geht mir weniger darum, ob das JavaScript-EntwicklerInnen oder EntwicklerInnen

01:18:47.540 --> 01:18:48.420
sind, sondern es geht mir darum,

01:18:49.720 --> 01:18:56.020
an welcher Stelle setze ich diese Funktion ein, ist die basierend auf Anwender-Input,

01:18:56.120 --> 01:19:00.640
nicht EntwicklerInput oder EntwicklerInnen-Input, sondern auf Anwender oder AnwenderInnen-Input.

01:19:01.000 --> 01:19:06.000
Dann gestalte ich das so offen, dass ich natürlich mit dem Ergebnis oder mit

01:19:06.000 --> 01:19:09.020
dem Input zuerst etwas tun muss und den validieren muss und den überprüfen muss,

01:19:09.140 --> 01:19:10.100
bevor ich den weiterschicke.

01:19:10.360 --> 01:19:14.800
Also bin ich da an dieser Grenze, wo das Typsystem, das ich mir aufbaue.

01:19:16.152 --> 01:19:20.812
Nicht bricht, sondern die Grenze überschreitet zu einem anderen System,

01:19:20.972 --> 01:19:23.092
zu einem anderen Input, was auch immer, oder nicht.

01:19:23.372 --> 01:19:25.972
Wenn das nur ein anderes Team ist, dann sage ich einmal, okay,

01:19:26.072 --> 01:19:29.372
ich rede dich einmal zusammen, bevor ich sage, okay, ich mache dort jetzt irgendwelche

01:19:29.372 --> 01:19:31.612
Safeguards innerhalb von meinem Code und habe den Typen anon.

01:19:31.792 --> 01:19:36.592
Weil tatsächlich ist es so, auch wenn der Typ anon ist, das ist ja nur ein Anspruch,

01:19:36.792 --> 01:19:39.092
eine Erwartungshaltung von

01:19:39.092 --> 01:19:42.472
mir und nicht die Erwartungshaltung von dem Anwender oder der Anwenderin.

01:19:43.712 --> 01:19:47.732
Und da kann ich die Erwartungshaltung entsprechend ändern. Wenn es aber so ist,

01:19:47.772 --> 01:19:51.832
dass ich nicht kontrollieren kann, was dort reingibt und auch den Leuten,

01:19:51.852 --> 01:19:55.132
die damit umgehen, nicht das Richtige beibringen kann, weil es zum Beispiel

01:19:55.132 --> 01:19:58.172
über Formular passiert oder sonst irgendwas, dann gehe ich von anderen aus.

01:19:59.332 --> 01:20:04.692
Aber du hast vorhin selber ja durchaus angemerkt, dass so SOT bei jedem HTTP-Request

01:20:04.692 --> 01:20:06.172
ein bisschen Performance kosten kann.

01:20:06.972 --> 01:20:12.512
Letztendlich ist das, was du gerade vorschlägst, dass React in jedem Funktionsaufruf,

01:20:12.572 --> 01:20:17.192
in den Dinge reingegeben werden, die ein Nutzer von React übergibt,

01:20:17.912 --> 01:20:20.432
prüfen sollte, ob das den korrekten Typen hat, oder?

01:20:21.812 --> 01:20:25.252
Also bin ich ein Entwickler, der mit React arbeitet, oder bin ich ein Nutzer,

01:20:25.372 --> 01:20:28.192
der eine React-Applikation verwendet? Also du und ich.

01:20:28.772 --> 01:20:32.332
Nein, also mir geht es dort tatsächlich um die Anwenderinnen und Anwender der

01:20:32.332 --> 01:20:35.052
Applikation, nicht die Entwicklerinnen und Entwickler, die damit arbeiten.

01:20:35.592 --> 01:20:37.572
Dann habe ich dich mit verstanden. Dann brauchen wir aber auch nicht anderen

01:20:37.572 --> 01:20:41.792
reinschreiben in dem Fall, Und da geht es eben genau um diese Erwartungshaltung,

01:20:41.892 --> 01:20:43.172
die ich von diesem Interface habe.

01:20:43.632 --> 01:20:46.252
Also dann schreibe ich dort einen anderen rein, weil ich tatsächlich nicht sagen

01:20:46.252 --> 01:20:47.172
kann, was dort reinkommt.

01:20:47.332 --> 01:20:51.512
Wenn ich das anderen Leuten gebe, die damit entwickeln, dann ist meine Erwartungshaltung,

01:20:51.592 --> 01:20:54.412
dass sie zumindest die Dokumentation lesen und wissen, was dort reinstecken soll.

01:20:55.889 --> 01:20:59.589
Okay. Oder meine Erwartungshaltung ist, dass wenn ich dort den richtigen Typ

01:20:59.589 --> 01:21:05.669
reingebe, dass den die IDE dieser Leute zumindest den Typen aufgreift und damit

01:21:05.669 --> 01:21:07.849
was macht, auch wenn sie schon nichts damit machen.

01:21:08.289 --> 01:21:10.989
Naja, aber guck mal, das würde ja zum Beispiel nicht passieren,

01:21:11.149 --> 01:21:15.369
wenn dein Input-Parameter unknown wäre, weil dann könnte ja die IDE über diesen Typen nichts sagen.

01:21:16.349 --> 01:21:19.589
Genau. Deswegen mach da nicht unknown rein. Deswegen mach ich nicht unknown rein. Okay.

01:21:20.729 --> 01:21:24.669
Wisst ihr, was ich mache in der Situation? Die Idee der JavaScript-Entwickler

01:21:24.669 --> 01:21:25.949
schreit ja dann trotzdem nicht.

01:21:26.129 --> 01:21:29.049
Egal, ob du unknown drin ist oder der Typ, aber zumindest kriegst du autocomplete.

01:21:29.629 --> 01:21:32.329
Ja, ja, das ist ja auch schon mal was wert. Aber wenn du unknown machst,

01:21:32.409 --> 01:21:35.529
geht halt die autocompletion flöten und damit hast du ja im Prinzip das kaputt,

01:21:35.609 --> 01:21:38.049
was du ja versuchst zu erzielen. Weißt du, was ich mache? Ich mache beides.

01:21:40.729 --> 01:21:43.569
Ich mache ein Overload. Ich mache in solchen Fällen immer eine Funktion,

01:21:44.649 --> 01:21:50.449
die in Sicht als eigenen Typ-Parameter, als Implementierungssignatur unknown

01:21:50.449 --> 01:21:53.229
hat, damit ich in der Funktion gezwungen bin,

01:21:53.609 --> 01:21:56.609
das Ding per Type-Checking zu überprüfen, ob es auch wirklich passt.

01:21:56.829 --> 01:22:00.109
Und dann mache ich ein Overload drüber mit dem Typen, von dem ich hoffe,

01:22:00.209 --> 01:22:03.949
dass ich ihn kriege, mit der Intention, dass das die Autocompletion aktiviert,

01:22:04.089 --> 01:22:06.369
bei denen, die halt eine Autocompletion haben.

01:22:06.689 --> 01:22:10.369
Ich aber trotzdem selber in der Innensicht gezwungen bin, paranoid zu sein,

01:22:10.529 --> 01:22:13.549
weil in der Implementierungsperspektive der Typ ja unknown ist.

01:22:13.849 --> 01:22:16.949
Das heißt, nach außen sage ich, gib mir Fu. Nach innen sage ich,

01:22:17.189 --> 01:22:19.449
ich glaube dir aber nicht und zwinge mich dadurch, das zu machen.

01:22:19.449 --> 01:22:24.149
Das ist eine relativ einfache Maßnahme, um halt so diese Kontaktpunkte zwischen

01:22:24.149 --> 01:22:28.549
den Systemen wirklich festzunageln, weil wir ja vorhin schon sehr wortreich

01:22:28.549 --> 01:22:30.669
herausgearbeitet haben, das ist ja da, wo es meistens knallt.

01:22:30.769 --> 01:22:35.189
Und das ist ein Einzeiler, mit dem man viel besser sicherstellen kann, dass das passiert.

01:22:35.389 --> 01:22:38.309
Man kann das relativ einfach im Code-Review auch sehen, dass das gemacht wird.

01:22:38.649 --> 01:22:42.989
Die Public Functions müssen halt dieses Feature haben und das ist entweder da oder nicht da.

01:22:43.869 --> 01:22:47.589
Und wenn ich jetzt nicht gerade so irre Performance-Constraints habe mit irgendwie

01:22:47.589 --> 01:22:50.409
Serverless-Functions, sondern einfach nur sage, Das ist eine Library und die

01:22:50.409 --> 01:22:51.449
soll halt super stabil sein.

01:22:53.233 --> 01:22:57.473
Also für mich ist es immer kontextabhängig.

01:22:57.573 --> 01:23:00.053
Also wenn die Teams anders nicht miteinander arbeiten können,

01:23:00.393 --> 01:23:03.053
ja, in Gottes Namen, dann mache ich das halt auch so nicht. Ist okay.

01:23:04.333 --> 01:23:07.493
Und wenn das der Anspruch ist, ist das auf jeden Fall ein valides Mittel, das zu tun.

01:23:07.853 --> 01:23:13.593
Overloads sind sowieso schwer unterschätzt. Das ist eine richtig coole Methode,

01:23:13.813 --> 01:23:17.953
um Typen zu decken in Fibscript. Großer Fan davon.

01:23:19.013 --> 01:23:22.493
Ja, und natürlich hinterher beim Debugging absolute Maßnahmen zur Sicherung

01:23:22.493 --> 01:23:24.633
des Arbeitsplatzes. Auch nicht unwichtig.

01:23:25.933 --> 01:23:30.413
Überfordern auch grundsätzlich LLMs. Bitte was? Kiki zuerst.

01:23:31.893 --> 01:23:34.553
Überfordern auch grundsätzlich LLMs, weil die Fehlermeldung so lange ist,

01:23:34.633 --> 01:23:38.893
dass der Kontext zu groß ist. Also insofern ist Richard und Zintroff, das stimmt schon.

01:23:41.033 --> 01:23:43.433
Ihr vergeschlagen, wir machen noch einen. Einen machen wir noch,

01:23:43.513 --> 01:23:46.373
komm. Wie lange kann es schon dauern? Stefan, lass würfeln.

01:23:47.533 --> 01:23:52.373
58, das haben wir wieder in TypeScript Oh no, okay, das ist meine Schwachstelle,

01:23:52.373 --> 01:23:53.393
Peter, da musstest du reden,

01:23:54.173 --> 01:23:58.073
Wir sind bei Decorators Decorators, ja, was soll ich dazu sagen,

01:23:58.253 --> 01:24:02.373
wir sind ja sowieso hier mehr oder minder der OOP-Hater-Club also warum würde

01:24:02.373 --> 01:24:06.773
jemals jemand von uns an eine Klasse irgendwie eine Annotation mit einem Ad-Zeichen dran schreiben,

01:24:07.313 --> 01:24:11.973
oder ein Framework gestalten, das nur auf Decorators aufbaut Ja,

01:24:12.193 --> 01:24:14.893
ja, also habe ich alles schon gemacht, finde ich auch super,

01:24:15.013 --> 01:24:16.693
funktioniert voll Super verwende ich jeden Tag, ist prima,

01:24:17.293 --> 01:24:19.033
ist halt nicht vergnügungssteuerpflichtig.

01:24:19.713 --> 01:24:22.613
Weil das mit TypeScript halt wirklich, also das ist, das ist hart.

01:24:23.893 --> 01:24:27.273
Ich bin mir noch nicht sicher, wo hier jetzt gerade Sarkasmus-Ironie sonst was

01:24:27.273 --> 01:24:30.033
und wo hier echte Aussagen drinstecken. Du, das ist alles wahr.

01:24:30.253 --> 01:24:32.813
Ich befinde mich da in einem quantenmechanischen Überlagerungszustand zwischen

01:24:32.813 --> 01:24:34.413
das ist Kack, aber ich mach's trotzdem.

01:24:34.653 --> 01:24:37.493
Hör mal, du hast ja auch mal Webentwicklung gemacht früher. Du kennst das doch.

01:24:39.415 --> 01:24:45.155
Ja, also ich meine, es ist voll super für sehr wenige Use Cases.

01:24:45.815 --> 01:24:48.835
Und für diese Use Cases, und da bin ich natürlich wieder normalerweise bei meinen

01:24:48.835 --> 01:24:53.335
Web Components, ist das klasse, weil wenn ich da E-Klassen benutzen muss und

01:24:53.335 --> 01:24:56.855
ich da halt irgendwie so ständig wiederverwendbare Plugin-Logik habe,

01:24:56.955 --> 01:24:59.095
weil sich Attribute, die Strings sind, immer gleich verhalten,

01:24:59.375 --> 01:25:02.455
ist es ganz gut, wenn ich einfach an Klassenfelder dran klatschen kann, du bist ein String.

01:25:02.455 --> 01:25:04.695
Wenn ich an eine Klasse dran klatschen kann, du bist ein Element.

01:25:04.975 --> 01:25:08.815
Wenn ich an eine Methode dran klatschen kann, wenn Attribute erendern, musst du dich auslösen.

01:25:10.215 --> 01:25:17.995
Das ist schon ganz nett. Es ist halt nur wirklich brutal, was so die Syntax so angeht.

01:25:19.235 --> 01:25:22.935
Ich muss ja sagen, dass ich irgendwie, also ich mag Decorators,

01:25:23.055 --> 01:25:27.735
Entschuldigung, aber ich bin ein bisschen traurig darüber, was da in TypeScript

01:25:27.735 --> 01:25:28.995
oder JavaScript draus geworden ist.

01:25:29.095 --> 01:25:31.755
Also in meiner Welt heißen ja einfach Annotationen.

01:25:32.455 --> 01:25:36.715
Und als Annotation finde ich die eine schöne Idee. Decorator finde ich ein bisschen schwierig.

01:25:36.875 --> 01:25:40.915
Also wenn man Metadaten an Dinge dran packt, dafür finde ich die wirklich toll.

01:25:41.475 --> 01:25:45.735
In dem Moment, wo die unfassbar verändern, was da drunter steht,

01:25:45.855 --> 01:25:47.055
finde ich es immer ein bisschen schwierig.

01:25:48.615 --> 01:25:53.535
Und dass das in TypeScript oder JavaScript geht, total tolles Werkzeug,

01:25:53.695 --> 01:25:57.115
aber... Aber mein Letztand sagt ja, es geht eh noch nicht, oder?

01:25:57.355 --> 01:26:01.735
Also es ist eh... Naja, naja, naja, was heißt ja wieder, es geht.

01:26:01.735 --> 01:26:04.155
Das ist jetzt schon wieder irgendwie so, das hört sich ja schon wieder so an,

01:26:04.175 --> 01:26:06.715
als würden wir wieder hier in den Reich des Binären abrutschen.

01:26:06.875 --> 01:26:09.975
Aber meine Herren, die Realität ist ja viel komplizierter als das.

01:26:10.275 --> 01:26:13.375
Weil ich meine, die JavaScript-Decorators werden in keiner JavaScript-Engine

01:26:13.375 --> 01:26:15.355
unterstützt. Da muss man dann schon irgendwie einen Transpiler rausholen,

01:26:15.435 --> 01:26:16.555
wie Babel oder eben TypeScript.

01:26:17.195 --> 01:26:19.935
Und dieses Feature-Sidekick, vor dem es dir so graust von wegen,

01:26:20.035 --> 01:26:22.595
oh nein, die verändern alles. Kann ich dich beruhigen, nix davon,

01:26:22.735 --> 01:26:23.415
akzeptiere TypeScript.

01:26:23.995 --> 01:26:27.455
Das ist ja aber das nächste Problem für mich mit Decorator. Wir sind ja gerade

01:26:27.455 --> 01:26:28.895
hier im Themenblock TypeScript.

01:26:30.017 --> 01:26:37.237
Dass es zwei verschiedene und inkompatible Implementierungen gibt, ist richtig, oder?

01:26:37.517 --> 01:26:40.537
Es gibt irgendwie, du weißt da Dinge. Es gibt in TypeScript,

01:26:40.697 --> 01:26:44.457
wenn man da die Experimental Decorators aktiviert, dann aktivieren die eine

01:26:44.457 --> 01:26:49.377
Legacy-Version von Decorators, die sie implementiert haben, bevor das Ding fertig und abgesegnet war.

01:26:50.957 --> 01:26:54.077
Also die Quintessenz ist, wenn man in TypeScript Decorators den richtig haben

01:26:54.077 --> 01:26:55.617
will, muss man Decorators nicht aktivieren.

01:26:55.837 --> 01:26:57.597
Wenn man Decorators aktiviert, kriegt man den alten Schrott.

01:26:57.657 --> 01:26:59.417
Wenn man Decorators deaktiviert, kriegt man Decorators.

01:26:59.977 --> 01:27:01.537
Obviously. Ich hasse einfach alles.

01:27:05.197 --> 01:27:08.057
Deswegen funktioniert das Zwischenums 3 so gut. Ich glaube, wir haben den gleichen

01:27:08.057 --> 01:27:11.477
Level Abneigung gegen Technologie entwickelt.

01:27:12.777 --> 01:27:15.837
Das ist schon ein Eindruck, wie unsere Industrie sowas werden konnte.

01:27:16.097 --> 01:27:18.657
Technologie ist super. Es ist nur die anderen sind das Problem.

01:27:19.217 --> 01:27:21.277
Ah, schön. Experimental Decorators, true.

01:27:22.297 --> 01:27:25.097
Ja, schön. Also sagst du, das will ich mal auf Falls stellen?

01:27:25.817 --> 01:27:28.357
Das willst du auf Falls haben, dann kriegst du die richtigen Decorators.

01:27:28.617 --> 01:27:33.617
Ab Modulo, du verwendest irgendwelche Libraries, die aus Legacy-Gründen den alten Kram supporten.

01:27:34.957 --> 01:27:37.117
Oder du verwendest von denen halt eh nicht so viel, weil ich meine,

01:27:37.177 --> 01:27:40.597
wie gesagt, mit TypeScript ist das mit den Use Cases echt ein bisschen schwierig,

01:27:40.717 --> 01:27:47.277
weil Decorators können in JavaScript zwar die Typen von den dekorierten Elementen verändern.

01:27:47.717 --> 01:27:50.437
Die können irgendwie, wenn eine Methode irgendwie Strings zurückgibt,

01:27:50.537 --> 01:27:53.897
können die das Ergebnis von dieser Methode irgendwie durch die Number-Funktion

01:27:53.897 --> 01:27:55.157
jagen und dann Zahlen rausgeben.

01:27:56.297 --> 01:28:00.977
Und diese Änderung der Signatur der Klasse ist Typescript halt nicht beizubringen.

01:28:02.377 --> 01:28:05.117
Es geht nicht. Man kann keinen Typ formulieren, der das macht.

01:28:06.137 --> 01:28:09.877
Typescript glaubt halt immer, wenn sich eine Klassendeklaration anschaut,

01:28:10.077 --> 01:28:13.337
die Klasse, so wie sie geschrieben steht, mit ihren ganzen Members,

01:28:13.417 --> 01:28:15.317
wie sie da geschrieben stehen, entspricht der Wahrheit.

01:28:15.477 --> 01:28:18.277
Und wenn man da anfängt, irgendwie fancy zu werden, indem man da Decorators

01:28:18.277 --> 01:28:21.317
raufklatscht oder irgendwie im Constructor Dinge macht, die man nicht machen

01:28:21.317 --> 01:28:26.497
sollte, dann weigert sich Typescript, das zur Kenntnis zu nehmen und es ist halt nur konsequent.

01:28:30.116 --> 01:28:35.276
Ich habe noch eine Folgefrage. Dieses Emit-Decorator-Metadata funktioniert wahrscheinlich

01:28:35.276 --> 01:28:38.076
nur mit den Experimental-Decoratoren? Genau.

01:28:38.436 --> 01:28:42.176
Das gibt dann Decorator-Metadata aus, was nicht zu verwechseln ist mit Decorator-Metadata,

01:28:42.296 --> 01:28:43.416
was was komplett anderes ist.

01:28:43.676 --> 01:28:48.936
Die Decorator-Metadata von den Experimental-Decorators sind tatsächlich Metadaten,

01:28:49.116 --> 01:28:52.696
die im TypeScript-Code vom TypeScript-Compiler emittiert werden,

01:28:52.896 --> 01:28:56.256
um dann irgendwelchen Runtime-Metaprogrammierungskrempel zu ermöglichen,

01:28:56.416 --> 01:29:00.096
den TypeScript lieber wieder in die Dose stecken.

01:29:00.096 --> 01:29:03.616
Wollen würde und so tun würde, als wäre das nicht passiert. Aber geht halt nicht bei Legacy.

01:29:04.116 --> 01:29:08.856
Und Decorator Metadata ist tatsächlich ein Werkzeug von den Schneider-Decorators,

01:29:09.076 --> 01:29:12.796
mit dem Decorators miteinander reden können.

01:29:12.956 --> 01:29:16.316
Also ich habe irgendwie einen Klassen-Decorator und in der Klasse habe ich Methoden,

01:29:16.436 --> 01:29:18.896
auf die klatsche ich einen anderen Decorator und diese beiden unterschiedlichen

01:29:18.896 --> 01:29:21.996
Decorators sollten miteinander reden können, weil sie auf der gleichen Klasse

01:29:21.996 --> 01:29:24.336
rumhacken und mit Decorator Metadata geht genau das.

01:29:26.916 --> 01:29:29.136
Hat heißt also genau gleich und hat nichts miteinander zu tun,

01:29:29.196 --> 01:29:31.996
deswegen ist es Jahr wieder Web-Entwicklung, kennt man ja.

01:29:34.932 --> 01:29:38.572
Passt macht keine Integres und so. Wir enden mit einem schönen,

01:29:38.932 --> 01:29:42.572
also irgendwie mit etwas Freudigem. Und dann kommst du wieder um die Ecke mit der Realität.

01:29:43.012 --> 01:29:45.252
Ja, ich dachte, ich paste mal hier auch was in den Chat.

01:29:46.212 --> 01:29:51.192
Das ist ja hier meine Decorator-Library für Web-Components. Ich sehe einfach nur Raute 443.

01:29:51.352 --> 01:29:55.312
Also das heißt, ich gucke mir jetzt eine Datei mit 443 Zeilen an. Ja, mehr.

01:29:57.112 --> 01:30:01.312
Das Schöne ist, ich habe... Das ist kompilierter Code, oder? Nein, nein, nein, nein.

01:30:02.612 --> 01:30:04.532
Du sagst ja immer, du bist kein Entwickler. Ich erinnere mich.

01:30:05.152 --> 01:30:07.372
Erstens das und zum anderen habe ich auch wirklich bewusst gesagt,

01:30:07.492 --> 01:30:11.532
prima, ich sitze mit meiner ersten Covid-Infektion zu Hause und bin nur so halb

01:30:11.532 --> 01:30:14.032
da. Das ist genau der richtige Zeitpunkt, um sich Decorators drauf zu schaffen.

01:30:14.712 --> 01:30:17.232
So war das damals. Und seitdem habe ich diesen Code auch nicht mehr angefasst,

01:30:17.292 --> 01:30:18.692
weil er funktioniert natürlich offensichtlich.

01:30:19.252 --> 01:30:21.992
Es ist halt mit der Lesbarkeit so ein bisschen so ein Ding. Und das ist halt

01:30:21.992 --> 01:30:23.832
so das zweite Problem mit Decorators und TypeScript.

01:30:24.252 --> 01:30:27.972
Die Domäne, mit der man da halt eben arbeitet, ist halt teilweise extrem Meta,

01:30:28.052 --> 01:30:29.812
weil man halt irgendwelche, sagen wir mal,

01:30:30.612 --> 01:30:34.112
Metaprogrammierung ja macht mit irgendwelchen High-Level-Konstrukten wie Klassen

01:30:34.112 --> 01:30:37.412
und Methoden und mit denen ja auch Metagramm macht, den man dann ja auch auf

01:30:37.412 --> 01:30:39.352
Typebene irgendwie nachvollziehbar machen muss.

01:30:40.032 --> 01:30:44.332
Weil ich meine, selbst wenn diese Dinger tatsächlich nicht, diese Decorators

01:30:44.332 --> 01:30:47.412
nicht den Typ von etwas verändern können, müssen die ja zumindest in sich stimmig

01:30:47.412 --> 01:30:49.492
sein und verschiedene Signaturen supporten und so blödsinn.

01:30:49.672 --> 01:30:52.392
Und das führt dann halt eben zum hier sichtbaren Klammerinfarkt.

01:30:55.020 --> 01:30:59.220
Für all diejenigen, die jetzt nicht im Nachhinein auf GitHub nachschauen wollen,

01:31:00.020 --> 01:31:04.600
Peter hatte offensichtlich 13 Monate lang Covid, weil die Änderungen dieser

01:31:04.600 --> 01:31:08.120
Datei erstreckten sich über 13 Monate und wie wir wissen, war das alles während

01:31:08.120 --> 01:31:09.680
deiner einen Covid-Infektion.

01:31:09.820 --> 01:31:15.400
Der letzte Kommentar ist übrigens, die letzte Comment-Message ist, remove comments.

01:31:16.860 --> 01:31:22.060
Den werden To-Do-Kommentare ohne irgendwas anderes daran zu ändern. Das freut mich sehr.

01:31:22.640 --> 01:31:25.540
Naja, das Problem ist halt eben, ich meine, niemand weiß das besser als so Menschen

01:31:25.540 --> 01:31:28.400
wie ihr, die ihr ja arbeitet an großen alten Software-Systemen.

01:31:28.780 --> 01:31:32.000
Egal, wie lange man rumrefactort und egal, was man alles so macht,

01:31:32.340 --> 01:31:37.060
eine Software kann nie ihrer initialen Entstehungsgeschichte und ihrer initialen Idee entkommen.

01:31:37.960 --> 01:31:40.720
Das ist halt einfach dann irgendwann in der DNA drin und da kannst du so oft

01:31:40.720 --> 01:31:41.700
Haare schneiden, wie du willst.

01:31:41.960 --> 01:31:45.480
Am Ende ist da immer genau der gleiche Fettklumpen drunter, an dem das initial

01:31:45.480 --> 01:31:47.740
gesprossen ist. Und das ist mit diesen Decorators genauso.

01:31:47.960 --> 01:31:50.400
Es ist halt leider irgendwie nützlich, deswegen muss ich es weiter benutzen.

01:31:51.240 --> 01:31:54.280
Aber weil es halt eben einfach entstanden ist im buchstäblichen Fieberwahn,

01:31:54.460 --> 01:31:58.240
ist das halt strukturell immer noch der schiere Fieberwahn und wird das immer

01:31:58.240 --> 01:32:00.180
so bleiben und ich habe auch keine Intention, das zu ändern,

01:32:00.700 --> 01:32:01.840
weil es funktioniert halt, es ist fertig.

01:32:02.340 --> 01:32:06.180
Abgesehen davon, dass zu viele Kommentare drin sind, das beschwört ja die Gefahr

01:32:06.180 --> 01:32:07.680
der Lesbarkeit herauf, das wollen wir ja nicht.

01:32:09.582 --> 01:32:13.462
Und du hast eben so schön diese Frage mit komischen Use Cases von unknown.

01:32:14.262 --> 01:32:17.862
Ich habe einen komischen, vielleicht komischen Use Case von Dekoratoren und

01:32:17.862 --> 01:32:20.362
das absurde, ich bin mir nicht mehr sicher, ob es funktioniert hat oder nicht.

01:32:20.442 --> 01:32:22.562
Ich weiß, dass ich das mal versucht habe in der Anwendung einzubauen,

01:32:22.602 --> 01:32:24.542
ich weiß nicht, ob es funktioniert hat und du wirst gleich erklären können,

01:32:24.582 --> 01:32:29.042
ob es geklappt hat oder nicht. Im richtigen Programmiersprachen gibt ja sowas

01:32:29.042 --> 01:32:31.762
wie so ein Type-of, nur dass es halt funktioniert.

01:32:32.342 --> 01:32:37.222
Das heißt, man kann auch prüfen, implementiert ein Objekt ein Interface zur Laufzeit.

01:32:37.402 --> 01:32:40.102
Das ist was, was in TypeScript offensichtlich nicht funktioniert,

01:32:40.202 --> 01:32:41.742
weil das Interface zur Laufzeit nicht mehr da ist.

01:32:42.522 --> 01:32:48.082
Und ich meine, dass ich mir ein Workaround gefrickelt habe, dass ich einen Dekorator gebaut habe.

01:32:49.722 --> 01:32:54.062
Der nur auf Klassen, die dieses Interface erfüllen,

01:32:54.322 --> 01:32:57.062
angewendet werden kann und dann die Metadaten geschrieben habe,

01:32:57.122 --> 01:33:02.442
hier ist es drauf und dann einen Typeguard gebaut habe, der entsprechend auf

01:33:02.442 --> 01:33:05.122
das Interface narrowed und zur Laufzeit auch prüft, ob es funktioniert.

01:33:05.622 --> 01:33:07.922
Bist du das ein oder hat das geklappt? Ja, okay.

01:33:08.502 --> 01:33:11.342
Es ist plausibel. Also was du natürlich machen kannst, Die Frage ist jetzt natürlich,

01:33:11.462 --> 01:33:17.462
was sozusagen dein Sprachmittel war, um das Implementieren dieses Interfaces zu checken.

01:33:17.942 --> 01:33:23.182
Ich glaube, ich meine, dass ich in irgendwelchen Meta dann oder in einem Symbol rumgehampelt habe.

01:33:23.302 --> 01:33:25.582
Also irgendwas auch nicht so ganz Schönes habe ich da drin gemacht.

01:33:25.702 --> 01:33:30.042
Nee, die Frage ist, wenn du in deinem Brotcode drin bist und du willst jetzt

01:33:30.042 --> 01:33:33.322
irgendwie fragen, implementiert Objekt X das Interface Y?

01:33:33.902 --> 01:33:36.002
Was schreibst du, um diese Frage zu formulieren?

01:33:36.622 --> 01:33:40.182
Ich habe eine Funktion, die das für mich prüft. Und dann mache ich so ein If

01:33:40.182 --> 01:33:43.422
drumherum. Das ist so eine Kontrollstruktur, die viele Programmiersprachen unterstützen.

01:33:44.122 --> 01:33:46.862
Okay, ja, nee, das kann man so machen. Ich dachte, jetzt machst du irgendwie

01:33:46.862 --> 01:33:48.042
so Kram wie Instance-Off oder so?

01:33:48.422 --> 01:33:53.382
Das geht ja dann in diesem JavaScript-Type-Script nicht. Mit einem Interface.

01:33:53.902 --> 01:33:56.002
Natürlich geht das. Mit einem Interface? Ja.

01:33:56.722 --> 01:33:59.162
Also nicht mit einem Interface, aber mit Instance-Off.

01:34:00.042 --> 01:34:02.382
Ich kann halt nicht Instance-Off-Interface-Name machen.

01:34:03.542 --> 01:34:09.222
Du kannst nicht Instance-of-Interface-Name machen, aber du kannst ja Instance-of

01:34:09.222 --> 01:34:12.882
überladen und du kannst dann ja in die Überladung reinschreiben,

01:34:13.182 --> 01:34:16.182
was du sozusagen gelten lassen willst als Interface.

01:34:16.282 --> 01:34:21.282
Du kannst ja sozusagen dein Ducktyping formalisieren und so deine Klasse einbauen,

01:34:21.362 --> 01:34:23.002
dass Instance-of dieses Ducktyping

01:34:23.002 --> 01:34:27.322
ansteuert und du halt eben nicht random Funktionen mit if verwenden musst.

01:34:28.578 --> 01:34:31.418
Das Problem ist, dass ich Instance auch nicht beim Interface überschreiben kann.

01:34:32.538 --> 01:34:36.698
Und ja, was gibt zu Recht, keine Mehrfachvererbung unterstützt und ich an der

01:34:36.698 --> 01:34:39.418
Stelle mehrere Interfaces verwenden wollte auf einer Klasse.

01:34:40.178 --> 01:34:45.378
Weißt du, das Problem ist, es gibt Vererbung konzeptionell und es gibt Vererbung,

01:34:45.498 --> 01:34:47.658
wie es tatsächlich dann mechanisch implementiert ist.

01:34:47.998 --> 01:34:50.298
Und natürlich kannst du konzeptionelle Mehrfachvererbung herstellen.

01:34:50.378 --> 01:34:53.918
Du kannst es halt nicht mit den Vererbungsmechaniken von JavaScript herstellen.

01:34:54.898 --> 01:34:58.738
Wollte ich auch nicht. Ich wollte ja nur prüfen, man hätte halt auch prüfen

01:34:58.738 --> 01:34:59.938
können, gibt es da eine Funktion?

01:35:00.318 --> 01:35:03.398
Und das wäre eigentlich schon fast ausreichend, aber dann ist das nicht so typsicher.

01:35:03.738 --> 01:35:06.958
Ja, aber was du halt tatsächlich gemacht hast, wahrscheinlich wenn du so eine

01:35:06.958 --> 01:35:10.958
Prüffunktion hast, das könnte ja tatsächlich einfach eine stinknormale Typeguard-Funktion sein.

01:35:11.158 --> 01:35:14.498
Genau, das war auch ein Typeguard, aber der muss halt irgendwo drauf prüfen,

01:35:14.578 --> 01:35:17.318
ob das gegeben ist. Und ich will halt nicht prüfen, gibt es da eine Funktion,

01:35:17.458 --> 01:35:19.078
die folgende Parameter entgegen nimmt? Ja.

01:35:19.458 --> 01:35:22.278
Bisschen aufwendig. Genau. Du kannst sowas halt generisch gestalten und man

01:35:22.278 --> 01:35:27.858
könnte es theoretisch mithilfe eines Decorators Factory-Function-mäßig an eine Klasse dran tackern.

01:35:28.038 --> 01:35:32.578
Das einzige Problem ist, mit den Standard-Decorators wird TypeScript das halt

01:35:32.578 --> 01:35:33.338
nicht nachvollziehen können.

01:35:33.478 --> 01:35:37.158
Weil du ja den Typ der Klasse erweiterst, du machst ja sozusagen über einen

01:35:37.158 --> 01:35:42.318
Mechanismus, der nicht A Extens B ist, faktisch einen Subtyp aus der Klasse,

01:35:42.418 --> 01:35:44.918
die du dekorierst und das checkt er halt eben nicht.

01:35:46.018 --> 01:35:50.838
Das besagte Projekt nutzt NestJS und NestJS braucht Experimental Decorators,

01:35:50.838 --> 01:35:53.718
wenn ich es richtig sehe. Insofern, ja, wird es das gewesen sein.

01:35:54.918 --> 01:35:58.538
Ich habe halt in letzter Zeit sehr viel Spaß damit gehabt, einfach Instance-Off

01:35:58.538 --> 01:36:02.838
zu meinem Sklaven zu machen, indem ich halt festgestellt habe,

01:36:02.898 --> 01:36:06.558
aber warte mal, es gibt ja dieses wunderbare Well-Known-Symbol namens hasInstance,

01:36:06.838 --> 01:36:08.618
das du auf einer Klasse implementieren kannst.

01:36:08.978 --> 01:36:12.358
Und das ist eine statische Methode, die gibt True oder False zurück,

01:36:12.478 --> 01:36:15.458
kriegt als Parameter ein Objekt, ein anderes Objekt übergeben.

01:36:15.638 --> 01:36:20.258
Und das ist letztlich die Runtime-Implementierung von Instance-Off, wenn vorhanden.

01:36:21.466 --> 01:36:25.186
Da kannst du also wirklich hingehen und kannst sagen, A, Instance of Klasse

01:36:25.186 --> 01:36:28.546
B und dann kannst du das Ding dazu bringen, True zu sagen, auch wenn die beiden

01:36:28.546 --> 01:36:29.626
Dinger nichts miteinander zu tun haben.

01:36:30.646 --> 01:36:33.186
Da weiß ich jetzt natürlich nicht, wie gut TypeScript das nachvollziehen kann.

01:36:33.686 --> 01:36:36.206
Ich kann auf jeden Fall nachvollziehen, wenn jemand deine Gedanken nicht nachvollziehen

01:36:36.206 --> 01:36:38.346
kann. Das müsst ihr mal ausprobieren, das klingt eigentlich echt interessant.

01:36:38.346 --> 01:36:42.466
Ja, ich hatte letztens den wunderbaren Use Case, wo das tatsächlich gebraucht wurde.

01:36:42.806 --> 01:36:46.626
Ich hatte da Kundschaft, die ließ sich von mir beraten und die hatte ihr Bild

01:36:46.626 --> 01:36:48.646
im Bildprozess so mittelgut im Griff.

01:36:49.026 --> 01:36:52.966
Hatte so das Problem, die haben halt so ihre Library gebaut mit halt so lauter

01:36:52.966 --> 01:36:56.826
kleinen Helferfunktionen und dann gab es halt irgendwelches Software auf mittlerer

01:36:56.826 --> 01:37:01.706
Ebene und die haben das alles included und dann haben die auch die Dinge teilweise wieder reexportiert.

01:37:01.706 --> 01:37:06.646
Lange Rede, kurzer Sinn, durch das Bundling gab es am Ende sieben verschiedene

01:37:06.646 --> 01:37:11.946
Instanzen der Bad Request Error-Klasse und man konnte halt eben dann in die

01:37:11.946 --> 01:37:15.126
Situation kommen, dass irgendwie Bad Request Error links flog,

01:37:15.486 --> 01:37:19.626
Bad Request Error rechts flog und wenn man dann gesagt hat, ist dieser Bad Request

01:37:19.626 --> 01:37:22.746
Error ein Instance of Bad Request Error, kam immer false raus,

01:37:22.826 --> 01:37:25.766
weil der Constructor, gegen den man das gecheckt hat, dann die dritte Instanz war.

01:37:26.166 --> 01:37:28.526
Weil das halt einfach so Bundle-Duplikation war.

01:37:30.106 --> 01:37:33.546
Und das war halt voll super zu lösen, indem man tatsächlich Folgendes gemacht

01:37:33.546 --> 01:37:35.566
hat, also ich habe natürlich nicht irgendwie dein Bildsystem repariert,

01:37:35.646 --> 01:37:36.306
weil das wäre ja irgendwie,

01:37:37.841 --> 01:37:41.821
an der Ursache das Problem haben, statt irgendwie an den Symptomen rumzudoktoren.

01:37:42.081 --> 01:37:44.901
Hab ich gesagt, wenn ihr einfach alles so lassen wollt, wie es ist,

01:37:44.961 --> 01:37:46.201
aber ihr halt wollt, dass Instance-Off

01:37:46.201 --> 01:37:49.401
diese unterschiedlichen Bad Request-Errors anerkennt, sozusagen,

01:37:50.021 --> 01:37:56.281
dann geht's eben hin, nehmt Symbol.for, um zum Anfang zurückzukommen und sagt einfach,

01:37:56.481 --> 01:38:01.121
auf euren diversen Bad Request-Errors steckt überall so ein Symbol mit halt

01:38:01.121 --> 01:38:04.581
irgendwie einem definierten Key heraufbeschworen, wo True hintersteckt und ihr

01:38:04.581 --> 01:38:08.041
überladet euer Instance-Off so, dass das Ding bei dem anderen Objekt einfach nur guckt,

01:38:08.241 --> 01:38:11.621
ob hinter diesem Symbol ein True wohnt und wenn ja, gibt es True zurück.

01:38:12.141 --> 01:38:14.881
Und ich erinnere mich, dass ich diese Geschichte in deinem Workshop schon gehört

01:38:14.881 --> 01:38:17.821
habe und dass ich spätestens seitdem das mit dem Symbol vor mir hätte merken

01:38:17.821 --> 01:38:20.401
können, aber habe ich ja nicht.

01:38:21.721 --> 01:38:24.781
Tja, ich muss wohl wirklich nochmal demnächst bei euch vorbeikommen und dafür

01:38:24.781 --> 01:38:27.381
sorgen, dass das wirklich genau bei dir eingeschärft wird.

01:38:28.301 --> 01:38:32.921
Kurze Antwort zu dem Thema Checked, TypeScript has instance?

01:38:34.561 --> 01:38:39.001
Natürlich. Weil TypeScript sagt ja nichts anderes. Also TypeScript gibt ja keinen

01:38:39.001 --> 01:38:42.061
Fehler, wenn du ein Instance-Off-Ding machst.

01:38:42.441 --> 01:38:44.721
Sondern TypeScript sagt ja nur im nächsten Schritt, ja passt,

01:38:44.801 --> 01:38:46.241
du hast einen Instance-Off-Check gemacht.

01:38:46.701 --> 01:38:50.461
Also ist das jetzt Instance-Off, was auch immer du für einen Typ checken willst.

01:38:50.721 --> 01:38:54.701
Ob das jetzt stimmt oder nicht, seid ihr hingesteckt. Aber dem Typ-System nach entspricht es auch.

01:38:55.121 --> 01:39:00.241
Ja, und ich muss natürlich dann natürlich unter dem Aspekt auch meine Einschränkung

01:39:00.241 --> 01:39:01.221
von gerade zurücknehmen.

01:39:01.341 --> 01:39:04.381
Natürlich kannst du mit dem Decorator dieses HasInstance da drauf tackern.

01:39:04.381 --> 01:39:07.741
Du rufst es ja nicht direkt auf. Dass du den Typ der Klasse nicht änderst, ist ja egal.

01:39:09.475 --> 01:39:12.835
Also es klingt extrem plausibel, was du erzählt hast. Das hast du wahrscheinlich wirklich so gelöst.

01:39:13.915 --> 01:39:17.715
Ich glaube nicht mit dem HasInstance, weil nochmal, das würde mit dem Interface nicht funktionieren.

01:39:18.275 --> 01:39:22.355
Ja gut, aber dann... Aber dann muss ich ganz kurz sagen, es gibt eben Compile-Time-Welt

01:39:22.355 --> 01:39:26.275
und Run-Time-Welt und TypeScript ist keine Run-Time-Welt. Und soll es auch nie sein.

01:39:27.255 --> 01:39:30.575
Ich bin da manchmal traurig drüber, aber ja. Ich nie, auch egal.

01:39:30.795 --> 01:39:34.715
Du machst einfach eine Variable namens Instance und leitest da den Typ von her.

01:39:35.255 --> 01:39:39.175
Und dann hast du ja was? Dann hast du ja eine stoffliche Repräsentation.

01:39:39.475 --> 01:39:41.275
Die nennen wir bitte Dollar-Dollar-Type-Off.

01:39:42.275 --> 01:39:45.975
Damit sind wir wieder beim Anfang. Wunderschön. Jetzt sind wir wirklich full

01:39:45.975 --> 01:39:50.955
circle gekommen und haben ganze vier Einträge in unserem Glücksrat geschafft.

01:39:51.135 --> 01:39:56.295
Ich bin sehr stolz auf uns. Nach zwei Stunden Aufnahmezeit. Meine Güte, ey.

01:39:57.980 --> 01:40:01.580
Da müssen andere Leute echt viele Meetings für kloppen, um so wenige Punkte

01:40:01.580 --> 01:40:03.320
in der Zeit fertig zu kriegen.

01:40:04.760 --> 01:40:10.880
Du hast recht. Und ich würde gerne wissen, wir machen das ja vor allem jetzt

01:40:10.880 --> 01:40:14.440
in dieser Dreierrunde, weil es ja das letzte Mal so gut funktioniert hat,

01:40:14.520 --> 01:40:16.640
wo wir über React so ausgekaut haben.

01:40:16.780 --> 01:40:18.940
Entschuldigung, mir fällt nur das österreichische Schein, wo wir ein bisschen

01:40:18.940 --> 01:40:23.360
süffisanter darüber diskutiert haben, über dieses Thema.

01:40:23.580 --> 01:40:26.660
Und wir haben sehr, sehr viel gutes Feedback bekommen. Also ich bin sehr happy

01:40:26.660 --> 01:40:30.420
über das positive Feedback, aber auch zu den Diskussionen, die noch entstanden

01:40:30.420 --> 01:40:32.800
sind, das ist richtig cool gewesen. Sehr, sehr happy.

01:40:33.180 --> 01:40:36.640
Und deswegen habe ich gesagt, passt, wir machen das gleich in einer weiteren

01:40:36.640 --> 01:40:39.120
Runde Glücksrad als der Kapo.

01:40:39.580 --> 01:40:43.700
Und persönlich würde ich gerne echt nochmal in dieser Runde über ähnliche Themen reden.

01:40:43.780 --> 01:40:46.240
Mir macht das irrsinnig viel Spaß, aber ich würde vor allem gerne von den Leuten

01:40:46.240 --> 01:40:48.280
draußen hören, ob sie das ähnlich so sehen.

01:40:48.540 --> 01:40:52.320
Wenn ja, dann bitte wieder auf die gleichen Wege kommunizieren mit uns.

01:40:53.100 --> 01:40:56.300
Speziell, wenn ihr nicht in React oder TypeScript primär zu Hause seid.

01:40:56.860 --> 01:41:00.020
Also manchmal ist das ja so, dass man sich Content auch einfach reinzieht,

01:41:00.060 --> 01:41:02.580
weil es unterhaltsam ist, auch wenn man damit fachlich nichts anfangen kann.

01:41:03.020 --> 01:41:06.480
Vielleicht sind wir ja so unterhaltsam, ich weiß es nicht. Oder wir reden irgendwie alle Chinesisch.

01:41:06.880 --> 01:41:11.280
Aber wenn es halt nicht gut ist, lasst uns das auch wissen. Das ist auch wertvoller Input.

01:41:12.420 --> 01:41:14.720
Und dann machen wir demnächst mal wieder was irgendwie mit so,

01:41:14.780 --> 01:41:17.060
hier, wie heißt das Zeug? CSS und so.

01:41:19.320 --> 01:41:25.540
Oh Gott, jetzt habe ich die Shownotes unserer vorherigen Revision React-Halsbringer

01:41:25.540 --> 01:41:26.900
oder Höllenmaschine aufgemacht.

01:41:27.300 --> 01:41:30.220
Und mit den Shownotes ist nichts verkehrt, aber dann bin ich jetzt wieder auf

01:41:30.220 --> 01:41:34.800
dieser trumpcard.gov-Seite mit dem Adler-PNG-Video.

01:41:35.860 --> 01:41:41.200
Und wisst ihr, jetzt glaube ich wirklich, dass ich irgendwie was mit Steinen

01:41:41.200 --> 01:41:42.400
machen sollte, statt mit Software.

01:41:43.460 --> 01:41:47.320
Alles bisher irgendwie, ah, any und funktioniert eh nicht und spricht nicht

01:41:47.320 --> 01:41:51.380
zusammen und man kann nicht mal irgendwie dem Weltbild von Typescript selber in sich glauben.

01:41:51.600 --> 01:41:54.360
Alles ist Blödsinn. Aber wenn ich wieder diesen PNG-Adler sehe,

01:41:54.620 --> 01:41:59.200
da geht mir jetzt wirklich wieder der Glauben an die Menschheit und an die Existenz

01:41:59.200 --> 01:42:00.500
auf dieser Realitäts-Ebene flöten.

01:42:03.534 --> 01:42:08.774
Ja, ne? Ey! Ich hatte das erfolgreich verdrängt.

01:42:13.514 --> 01:42:16.614
Ich bin mir nicht sicher, wie dieser Tag bei mir jetzt noch eine Kurve kriegen

01:42:16.614 --> 01:42:19.714
soll. Ich meine, man kann es ja so sehen.

01:42:20.894 --> 01:42:25.774
Was ist Kunst? Kunst ist doch dann, wenn man bei seinem Publikum eine emotionale Reaktion erzeugt.

01:42:26.654 --> 01:42:29.454
Ich glaube, wir müssen diese Webseite unter Kunst rubrizieren.

01:42:35.814 --> 01:42:39.654
Gut, ich habe gehört, manche von uns haben bis vor drei Minuten Zeit,

01:42:41.654 --> 01:42:47.754
Ja, also bei mir wird es Zeit, dass ihr weiter noch bei mir Aber ich danke euch recht herzlich,

01:42:48.274 --> 01:42:52.914
Gleichfalls Es war ein Vergnügen wie sonst was Wie immer, liebe Hörerinnen,

01:42:52.954 --> 01:42:57.234
liebe Hörer Wir haben es schon gesagt, lasst euer Feedback erklingen auf Social

01:42:57.234 --> 01:43:00.114
Media oder haut uns auch sonst an, wenn ihr uns irgendwo seht.

01:43:00.214 --> 01:43:03.174
Ich habe keine Ahnung, was die nächste Revision ist Deswegen höre ich jetzt auf zu quatschen.

01:43:03.454 --> 01:43:06.194
Danke fürs Zuhören. Bis zum nächsten Mal und tschüss. Ciao.