Remix mit Andre Landgraf

Hallo und herzlich willkommen zu einer weiteren Folge der Programmierbar. Wir haben mal wieder einen Deep Dive heute zum Thema Remix, worüber ich mich sehr freue, was das ist, mit wem ihr sprechen erfahrt ihr gleich mit dabei ist neben mir der Semi. Hi. Hello. Und über Remix zu sprechen, dafür haben wir uns den Andre eingeladen. Hi Andre. Hallo, Hallo. Dich haben wir gefunden, weil du auf der aktuellen Remix Konf gesprochen hast und auf der Remix Konf den Leuten erzählt hast, wie man seine Bosses überzeugt, Remix zu nutzen. Deswegen dachte man okay, du scheinst auf jeden Fall zu wissen, wovon du redest, wenn du selbst die Manager davon überzeugen kannst und bist gerade Softwareentwickler bei LinkedIn? Genau. Vielleicht erst mit einer Frage, mit der wir am Anfang gerne mal einsteigen. Kannst du uns probieren? Es ist bei Software immer schwierig, aber... Kannst du mir in eins, zwei, vielleicht maximal drei Sätzen, zumindest kurz erklären, was Remix ist. Drei Sätzen, ich versuch's. Remix ist ein Full Stack Web Framework für React. React ist ja eher als Library zu verstehen, dass all die Sachen zu React bringt, die bei React noch fehlen, damit du eben eine Full-Stack-Applikation bauen kannst. Okay, das heißt aber schon gefühlt, wenn ich jetzt was, also abgrenzend zum Beispiel, wenn ich jetzt, da würde mir zum Beispiel auch Next. Js zum Beispiel direkt einfallen, so als Alternative dazu. Ist es denn auch so, wenn ich an diese Frameworks denke, so, die machen alle irgendwie Server Site Rendering, Static Site Generation und bieten irgendwie alle möglichen Dinge irgendwie an? Also reiht sich das da so komplett mit ein? So ist es, also kann ich da auch alles mit machen, was ich möchte, oder? Ja, auf jeden Fall. Vor allem jetzt in den letzten Monaten. Next. Js und Remix werden immer ähnlicher in den Funktionen, die sie anbieten. Also falls ihr NextGS kennt oder nachst, dann ist Remix auf jeden Fall sehr ähnlich auch von eben wie du gesagt hast, von Server-Set Rendering und diesen ganzen Funktionen, die man eben erwartet, heute von einem Full-Stack Web Framework. Remix hat aber eine ziemlich eigene Philosophie. Das ist etwas, wo man vielleicht sagen kann, dass es sich ein bisschen abgrenzt. Und kannst du ein bisschen auf die auf die Philosophie eingehen, weil zumindestens, also gleich mal ganz kurz wie ich auf Remix. Also ich glaube, wir kamen schon von einer ganzen Weile auf Remix, haben lange gebraucht, jemanden zu finden, der mit uns darüber sprechen kann und was Remix auf jeden Fall irgendwie gut macht, ist auf jeden Fall ihre Marketing Seite. Also gefühlt war so, danach hat man direkt Bock es zu probieren und irgendwie gefühlt bei dem, was mir hängengeblieben ist von der Marketing Seite, so wenn ich Remix nutze, habe ich keine X-Loading-Spinner mehr und lade irgendwie nicht alles ein, sondern gefühlt irgendwie machen sie was ganz toll mit Formularen. Das ist so, wenn ich auf Remix so ganz oberflächlich schaue, nachdem ich die Marketingpräsentation gesehen habe oder die Marketingseite, das scheinen sie irgendwie cool zu machen. Gerade der Part mit den Formularen ist bei mir hängengeblieben. Ist es denn, was du mit Philosophie meinst oder was genau meinst du mit Philosophie? Ansonsten werden wir bestimmt auf die anderen beiden Punkte auch gleich noch eingehen. Ja, auf jeden Fall. Also Remix. Run, die Website, die du beschrieben hast, ja, mega geil gemacht. Beschreibt es ganz gut, was sie da eben meinen. Aber vor allem, wenn du jetzt, weil du jetzt schon Nextjahres angesprochen hast, die Unterschiede da sind da wirklich, wirklich im Detail. Also es kommt dann auf die Nuancen drauf an, wie sich dann Remix entscheidet, die Sachen zu implementieren oder einem anzubieten. Und das basiert eben alles auf der Philosophie, die die zwei Founder, Ryan Florenz und Michael Jackson eben, was denen eben wichtig ist. Das kommt alles von der Erfahrung, was die vor React gemacht haben. Hattest du Michael Jackson gesagt? Wusstest du es nicht? Die React Router Maineainer sind Michael Jackson und Ryan Lorenz. Cool. Nach der Musikkarriere doch noch mal, der ist gar nicht tot. Jetzt macht Remix ja auch erst Sinn. Ja, versuch mal Remix Michael Jackson zu googeln und schau, ob du Remix. Run findest. Klingt danach nicht der gleiche Michael Jackson, wenn es so ist. Weil du gesagt hast mit ihrer Vorerfahrung, was haben die beiden vorher gemacht oder bevor sie Remix gemacht haben? Ja, die haben zusammen React Router entwickelt, der meistgenutzte Router für React Application. Ich glaube mittlerweile über eine Milliarde Downloads auf NPM oder so, also crazy Statistik. Genau. Und von ihrer Erfahrung mit dem Router haben sie dann eben gesagt: „Hey, wir wollen eigentlich mehr integrieren und haben dann Remix gestartet und Remix kann man eigentlich fast als ein Compiler für ReactRouter verstehen. Also ReactRouter ist ziemlich integriert in Remix und alles, was die sozusagen in React Outer jemals gemacht haben, hat zu Remix geführt. Okay. Aber jetzt geführt. Okay, aber jetzt so ein bisschen noch mehr die Philosophie zu verstehen. Was sind denn jetzt wirklich die Dinge, wo du sagst, das hebt Remix jetzt ab? Das sind die Philosophie Dinge, weshalb ich das dann wählen sollte. Ja, ich kann dir Spaß Antwort geben und dann versuchen, ein bisschen Ernstes zu erklären. Die beiden ganz am Anfang, als Remix rauskam, haben viele auf Twitter gesagt, dass Remix ein Boomer Framework ist. Und es wurde dann auch so ein bisschen so ein Running Gag in der Community. Und was damit gemeint ist, ist eben, dass die beiden Gründer, ich glaube, Ryan war lange in AmbaDev, also die haben, die kommen mit viel Vorerfahrung von PGB und Rales zu React und haben das dann eben alles auch in Remix gebracht. Eben diese älteren konventionellen, also Webplattform Standards. Also wie du schon gesagt hast, Formulare zu benutzen, wirklich auf die Web Standards aufzubauen. Und das sind einfach starke Opinions, mit denen die eben angefangen haben, Remix zu bauen, weil ihnen solche Sachen eben wichtig sind. Ein Formular soll auch funktionieren ohne JavaScript, Progressive Enhancement. Zum Beispiel solche Ideen sind ihnen unglaublich wichtig und da wollen die eben keine Kompromisse eingehen oder bzw. Alles auf dieser Basis aufaufbauen. Was sie zum Beispiel auch immer sagen, ist, dass mit dem JavaScript, das sie benutzen in Remix, emulieren sie die Default-Behaviour vom Browser. Also alles ist darauf gedacht, sozusagen so zu funktionieren, wie der Browser eh schon so funktioniert und es dann nur noch ein bisschen zu verbessern mit JavaScript, aber eben nicht das Rad neu zu erfinden. Und das ist so ein bisschen die Philosophie, die Michael F. Und Ryan eben vertreten. Okay, das heißt, sie wollen auf Web Standards setzen und sozusagen nichts Unnötiges Neues bauen. Das eine Beispiel wäre jetzt auf jeden Fall Formulare. Man stützt sich auf das Standard-Falten von Formularen, obwohl ich glaube, ich kann da gleich noch mal drauf eingehen, wie das dann trotzdem genau funktioniert. Sebi guckt. Schon so ein bisschen. Ich überlege gerade, ich habe mir diese Formular-Library von Fabian noch nicht angeschaut und hätte mir das vielleicht anschauen sollen, jetzt wirklich sagen zu können, ob da irgendwie Webstandards nicht. Berücksichtigt werden. Ich glaube, er hat ja eine Validation Library geschrieben. Ich glaube, Form Validation wird mich auch später noch mal interessieren. Fabian Hiller, der auch … Wenn die Folge rauskommt, ist der Talk von ihm über Solid und Quick bei uns hier als Meet-App schon vorbei. Aber genau, er hat für Solid eine Form Validation Library geschrieben. Aber da können wir bestimmt gleich noch mal darauf eingehen, wie eine Form Validation funktioniert. Aber vielleicht dann lass doch, wenn wir jetzt gerade da sind, lass uns mal vielleicht wirklich am Beispiel Formularen dann das Ganze machen. Was heißt denn, wie funktioniert denn ein Formular Flow dann jetzt? Und was heißt es, den Web Formular Standard zu nutzen? Genau. Ganz kurz bevor ich anfange. Ich will noch ein bisschen Highlighten, dass das jetzt eh immer populärer wird. Also was ich jetzt erkläre, wenn ihr jetzt sagt, das hat die nächste Version von Nextshares auch oder das Weltkrieg macht das jetzt auch schon. Ja, weil eben das sich jetzt langsam verbreitet. Aber Remix war so, das war ganz wichtig ganz am Anfang. Und jetzt ist es schön zu sehen, dass das andere auch machen. Was ich damit meine, dass sie eben auf diese Browser Standards aufbauen. Was passiert denn, wenn du eigentlich ein Formen Submit hast? Der Browser macht einen Full Page Reload und sendet die Daten als Query Parameter bei Default an den Webserver. Was wir aber jetzt in React und View und anderen Frontend Frameworks schon viel gemacht haben, ist dann „prevent default eben nicht zum Server zu senden, sondern eben dann Client Seiten Fetch zu schicken und das halt alles Client Zeit zu überwachen. Du hast deine Loading States, deine Error States, alles in deinem Frontend Framework. Du bleibst am Client und machst dann Fetch Requests zu irgendeinem REST API Web GraphQL Server. Und diesen Layer sozusagen implementiert Remix für dich, damit du das nicht selber machen musst. Aber die Art und Weise, wie sie es implementieren, ist eben so, dass sie versuchen, den Browser zu emulieren. Was das bedeutet, ist, dass sie natürlich schon Prevent Default machen und dann selber ein Fetch abschicken an ihren eigenen End Point bei Remix, den du dann implementieren kannst mit Actions. Actions ist die Konvention, die Remix in den Roader Files hat. Aber wenn du jetzt JavaScript disablen würdest in deinem Browser oder JavaScript würde nicht funktionieren, weil es kaum Fehler geworfen hat oder so weiter, würde das zurückfallen auf einen normalen Formsubmit. Also dann würdest du zu einem Full Page Reload kommen. Das Form würde ganz normal mit dem Browser submiten und eben zu dem selben End Point submitten, den du eh in Remix baust und es würde auch funktionieren. Und das ist das, was ich meine mit Emulets, The Browser ist die Falt Behaviour, dass es eben Remix schaut immer, dass die Browser Standards funktionieren und dann versucht man es natürlich trotzdem zu verbessern mit JavaScript, aber immer mit dem Hintergedanken, dass es auch ohne JavaScript funktioniert und nicht nur damit es ohne JavaScript funktioniert, aber auch einfach, weil es ein simpler Programmiermodell erschafft dann. Wenn du immer nur an Forms mit denkst und dann kriegst du die Daten zurück und Full Page Reload, wenn das dein Mental Model ist, dann macht es, also finde ich persönlich, das Programmieren wesentlich einfacher und es funktioniert eben auch ohne JavaScript. Und das heißt, vereinfacht es mir dann aber nur, also jetzt klingt es gerade wie, ich nehme einfach nur die Logik so ein bisschen ab, wie ich meine Daten an den Server schicke und funktioniert im worst case auch ohne meinen JavaScript-Pattern, den ich geschrieben habe, so, aber ist es denn, also ich meine zu diesem ganzen Form Handling, so was wie okay, da müssen die Daten ja irgendwie noch am Ende wieder zurückkommen. Ich habe vielleicht einen Loading State, muss irgendwie Fehler abfangen und so. Wird das alles noch einfacher oder spare ich mir nur einen Fetch? Nee, das ist genau das, was Remix so toll macht in meiner persönlichen Meinung. Wenn du auf Remix. Run die Homepage guckst und schaust dir die erste Landing Titel an, da ist ein kleines Grundbeispiel, das beschreibt das ganz gut. Dadurch, dass eben Remix dir das Fetchen abnimmt, musst du keine Loading States und keine Validation und all das ganze Zeug eben nicht mit React machen, sondern deklarativ mit deiner Formelogik und dann eben Server Site mit deinen Data Loaders oder Data Actions. Und dadurch, dass das Remix sozusagen inhouse macht, kannst du dann einfach bei Remix abfragen: „Hey, lädt die Seite gerade, sind wir gerade in einer Page Transition? Habe ich gerade schon die Daten? Was sind die Daten? Und dadurch wird das alles deklarativer. Also als ein Beispiel zum Beispiel, wenn du summittest und in deiner Action Function wird einkommst du zu einem Fehler als sagen wir mal bad Request, weil das Passwort ist falsch oder for one oder was auch immer. Dann kannst du da einfach einen Fehler werfen, ein Error. Und dann hast du eine Komponent in Remix, die heißt catch-Boundary oder Error-Boundary, wo du dann ganz normal dein UI definierst, was in dem Fehlerfall angezeigt werden soll. Und das heißt, du hast in React gar nicht dieses if Fetch Request, dort Bad Request, Error, Equals True, dann schau das auf der anderen Seite, sonst schau, keine Ahnung, zeigt es Form an oder eine Success Message. Dieses Ganze fällt eben weg, weil du es deklarativ eben definieren kannst. Und das ist super schwer zu beschreiben, ohne sich Code anzuschauen. Aber das ist genau das, was Remex für mich so produktiv macht, weil eben dieses ganze Loading State, der ganze Loading State wegfällt. Vielleicht, weil er damit auch … Ich glaube, du hast vorhin ja schon gemeint mit Webframing und so. Ich weiß aber nicht, ob es jetzt jedem so ganz klar ist. Der Server Teil ist ja auch komplett Remix. Wenn wir von Server reden, wohin die Daten geschickt werden, kann ich jetzt nicht zu irgendwas, irgendeinem anderen Backend die Daten schicken, sondern es ist wirklich so, wir haben ein Full-Stack Framework, wo wir Server-Setting Code laufen haben und ich wahrscheinlich, können wir vielleicht gleich noch auf die Syntax eingehen, weil ich gar nicht genau weiß, wo ich jetzt diese ganzen Action Dinger und so was definiere. Aber das ist ja alles dann Remix, ohne dass Remix halt das komplette Framework bietet und der komplette Backend Layer auch. Remix ist. Genau, also Remix, wie auch NextSGS versteht sich als Full Stack Web Framework, eben kommt in dem Client Part und einem Server Part. Und vielleicht ganz interessant, Remix sagt man nicht, dass Remix ist kein Webserver, sondern Remix ist ein HTP Request Handler am Backend. Also Remix setzt auf einen Webserver. Du kommst mit deinem eigenen Webserver und du setzt dann Remix drauf auf. Und wenn du ein neues Remix Projekt startest, dann ist das natürlich alles schon eingebaut. Also kannst sagen Hey, ich will auf ExpressJS laufen, also Node oder auf Deno oder auf CloudFabWerkers. Und dann ist der ganze Boiler-Plänt Code schon da. Aber der Remix Teil ist, handelt nur die HGP Requests und du hast dann noch deinen eigenen Server und runter, den du auch tatsächlich verändern kannst, wenn du willst. Das heißt aber, die Endpunkte definiere ich dann aber in Remix Syntax und nicht dann in Express Syntax. Das heißt eigentlich, wenn ich jetzt Node nutze, ob da jetzt Express oder Festify oder so, ist eigentlich eigentlich wurscht, weil ich alles nur in Remix Syntax schreibe. Genau. Also du würdest die ganze Remix App in Remix schreiben. Das Schöne ist aber, dass du deployen kannst, wo immer du willst. Serverless, Edge, Long Running Server, eben weil es Adapter für all diese unterschiedlichen Requirements gibt. Und falls du jetzt sagst, ich brauche einen Web Socccetserver mit Express, kannst du es theoretisch in derselben App bauen, weil du eben auch Zugriff auf Express oder Node hast. Genau. Aber ja, es macht dich sehr flexibel. Aber am Ende des Tages ist dann alles, was mit Remix zusammenhängt, in Remix geschrieben. Deswegen kannst du auch ziemlich einfach zwischen den Environment switchen. Ich finde es auch ganz spannend, wie diese Komponenten das Frontend und die Backend Sachen Remixen. Also. Man, vielleicht kannst du da noch mal drauf eingehen, weil irgendwie, also zumindest jetzt in diesem Getting Started habe ich mit Endpunkten und irgendwie einer URL aufrufen und so gar nicht so viele Berührungspunkte gehabt, sondern das hat irgendwie ganz schön weggekapselt. Ja, ich glaube, das liegt daran, dass eben der Router ein großes, einer der drei wichtigen Parts in Remix ist. Und in Remix wie auch in NXGS hast du eben einen Routespolder. Ich weiß nicht, wie es in NXGS heißt, aber NX ja auch. Das ist also File-based Routing. Du definierst deine Routestruktur mit einer File-Hierarchie, File-Folder-Hierarchie. Und in jedem Fall das mapst du zu einem Teil von der URL. Und der Router ist dafür zuständig herauszufinden, welche dieser Files gerade aktiv sind und welche nicht. Und dadurch, dass alles, jede Route zu einer URL gemappt wird, hast du sozusagen dieses, weil du gesagt hast, diese Endpunkte, das ist sozusagen implizit definiert, würde ich sagen, weil wenn du in irgendeinem von diesen Routesfiles eben deine Komponente exportierst und deinen Loader exportierst und dein Action exportierst, das sind die drei wichtigen Teile in Remix, dann weiß der Router eben durch deine File-Hierarchie, wie der Endpoint heißt und in welchem Fall der Endpoint ist. Und jetzt sagen wir, du hast in irgendeinem Fall ganz tief unten einen Loader, einen Action und eine Form und das Form wird committed. Dann weiß Remix eben, dass bei Default das zu der Action Function im selben File soll. Dadurch ist das halt schön abstrahiert. Das heißt der Server und der Client Code, obwohl man dann weiß gar nicht, ob man von Client Code sprechen kann. Ich habe jetzt für Client Code meine ich den Form Teil und Loader und Action, das ist wahrscheinlich der Server Teil, leben im selben File. Ja, Hot Takes. Ja, da gibt es Meinungen in beide Richtungen. Also kann sagen Hey, super produktiv, weil ich sehe alles, was von einer Business Logik zusammengehört in einem File. Ich muss nur hoch runter scrollen. Auf der anderen Seite natürlich muss man erst mal verstehen und das begreifen. Hier kann ich auf meine API Secrets zugreifen in meinem Load an Action, weil ich weiß, die sind immer nur im Server. Aber hier die Rack Component muss ich vorsichtig sein. Die wird zwar Server-seit gerendert, aber dann kommt der Code auch zum Client und alles was ich in React aufrufe, ist Client Code. Also muss ich vorsichtig sein, was ich da definiere und benutze. Ja, jetzt mit React Server Components, was ja so das große neue Ding ist, was auch NextJS jetzt ziemlich übernommen hat, wird es immer häufiger, würde ich sagen, dass da die Linie zwischen Server und Client ein bisschen schwammiger wird. Bei Remix gibt es Pain Points, würde ich sagen. Aber generell ist es okay, weil du eben zwei Funktionen hast, von denen du ganz genau weißt, die laufen nur auf dem Server und dann reactest du intuitiv, weil man ja eigentlich, dass es auch auf dem Client läuft. Dadurch geht es. Also ich hatte da jetzt noch nie, ich war noch nie wirklich verwirrt deswegen, aber ja, ich verstehe, dass das ein Punkt ist, wo man dem dann kritisieren kann, wenn das einem nicht gefällt. Okay, und von diesen, wie nennt man die, sind das dann, wie wäre der Fachbegriff für Loader und Action? Also sind das die einzigen Typen, die ich da, die ich da definieren kann? Dieses, also irgendwie die, für mich für die Server-Kommunikationsschicht, ich weiß nicht genau, was jetzt der Fachbegriff dafür ist. Ja, so ich würde sagen, das ist, wie nennt man das, das die File Exports, The Route File Exports, glaube ich, wenn du in der Dokumentation schaust, da würdest du die List finden von all den Sachen, die du in dem Routing File exportieren kannst. Das ist eine Handvoll, also du hast Meta Tags Export und Links, also wo du deine Style Sheets exportieren kannst. Du hast HTTP Headers und dann die wichtigsten sind eben Action, Loader und Default Export. Das ist die React Component. Kann ich Loader und Action so verstehen, dass Loader irgendwie der Endpunkt ist und Action der Post Endpunkt oder so? Ja genau. Wenn du jetzt einfach von Postman oder Curly zu einem React-UL Part posten oder getten würdest, bei get würde der Loader zurückkommen und bei POST, PUT und bei allen anderen HTP Verbs würde die Action Function getriggert werden. Okay, und Loader ist sozusagen was, wenn meine Komponente aufgerufen wird, wird wahrscheinlich per Default einfach das ausgeführt und irgendwie auf diese Daten kann ich wahrscheinlich dann irgendwie zugreifen, weil es wahrscheinlich irgendwie das Initialisieren meiner Komponente ist. Und die Action ist jetzt etwas, was durchs Formular getriggert werden kann. Ist das etwas, was ich dann auch händisch triggern kann? Ist ja vielleicht nicht immer, dass ich das über ein Formular, nicht dass ich ein gutes Beispiel hätte, aber wahrscheinlich nicht immer, dass ich per Formular irgendwie ein Update an meinen Server-Teil schicken will? Ja, gute Frage. Also du kannst auch Routes definieren, die gar keine React Component exportieren. Und was du dann quasi machst, das Remix nennt das ein ResourceRoute, dann hast du quasi einfach nur API Endpunkte. Aber eben, das heißt ein Get würde dann kein HTML zurückgeben, sondern einfach nur die Json Data, die du mit deinem Loader returnst. Und. Genauso kannst du eben auch die Action Function kannst du ganz normal mit einem Fetch Post delete aufrufen oder eben mit einem Formsignal mit. Und du wirst dann immer das Request Object bekommen. Das gibt dir Remix, also die Fetch API vom Web Browser gibt es ein Request und Response Object. Das sind die Objekte, mit denen auch Remix arbeitet. Und du würdest dann in deinem Action, egal wie du die aufrufst, das Request Object bekommen und kannst dann eben das Json passen oder die das Form passen und dann auch die Daten zu greifen. Am Anfang habe ich ja die Frage gestellt, ob Remix genauso wie jetzt next oder nachts im Endeffekt alles macht, Server Site Rendering oder Static Site Generation. Und irgendwie dachte ich in meiner, so was ich so mitbekomme, dass Remix komplett nur Server Site Rendering ist und gar keine Static Site Generation macht. Ich war jetzt ein bisschen überrascht von deiner Antwort. Ist es was, was neu dazugekommen ist oder habe ich das grundsätzlich irgendwie falsch verstanden, wo sich Remix positioniert? Ja, wenn ich gesagt habe, die haben dieselben Funktionalitäten, meinte ich, dass sie eben Endpunkte haben, dass du aufrufen kannst, kannst du recht rendern und so weiter. Remix hat kein Static Side Generation, aber eben das kommt jetzt, kommt man wieder zurück auf die Philosophie und kann sagen warum? Die Antwort ist, dass Remix eben Wert auf HGP Caching legt. Und da ist jetzt eben die Philosophie so Hey, wenn du was hast, was sich nie ändert, wie du das löst, ist mit Caching. Hgp Caching Headers, Revalidation Headers, CDNs. Du brauchst keine statische Generierung, weil du das eben auch anders lösen kannst. Deswegen die Funktionalitäten sind ähnlich. Und natürlich, wenn du dann in die Nuance gehst und dann wirklich reinschaust, siehst du natürlich, dass es Trade-outs sind wie überall. Aber genau du kannst dieselben Sachen erreichen, aber eben mit anderen, anderen Werkzeugen. Das klingt für mich erst mal so, als wird es so ein bisschen eine Zielgruppe so ein bisschen... Du siehst es so, ich mache jetzt immer meinen Blog und der Großteil von dem, was ich mache, ist irgendwie statisch generiert. Was ja gefühlt diese anderen Frameworks auch immer mit abwürgen. Klingt jetzt wie es muss schon eine gewisse Form von Interaktivität da sein, dass es sich lohnen würde, Remix zu nutzen? Würdest du da mitgehen? Weil ich zumindest sage ich mal so, ich brauche immer einen Server. Ich kann jetzt nicht einfach irgendwo mein keine Ahnung in meiner GitHub Action das Ganze bauen lassen und dann einfach nur irgendwie Firefox Hosting und Bumm aus. Ja, ich glaube, der Teufel istJa, das ist ja im Detail. Und wenn man dann wirklich diskutiert, kann man natürlich immer herausfinden Hey, das Tool ist besser für was ich baue als das Tool. Persönlich glaube ich nicht, dass ich jetzt irgendeine Website im Blick hätte, wo ich sagen würde, Remix ist nicht geeignet. Als Beispiel als Block. Du baust einen Block Server Site Rendering und dann haust du einen Caching-Header mit deinem CDN hin, der für einen Monat das hart cacht, auch im Browser. Das heißt, kein User würde tatsächlich jemals zum Server gehen, weil das CDN einen Monat lang alles surft. Das ist dann quasi Static Site Generation, richtig? Also du generierst es einmal bei dem ersten User. Das wird, HTML wird gerendert, dann wird es an dein CDN verteilt und der CDN hat die Caching Headers, der sieht, er muss nicht zurück zum Server gehen, weil es noch valide ist. Und dann ist der CDN, also dein Distribution System dafür verantwortlich, das an User zu verteilen. Und dann hast du ja quasi dasselbe wie Static Sight Generation. Der einzige Unterschied ist nur, dass bei Static Sight generierst du die Seiten in deinem Build Step und mit Caching Headers generierst du es, wenn der erste User nachfrägt. Und dann hast du natürlich 1000 unterschiedliche HTP Caching Headers, die du benutzen kannst, das ganz genau auf deinen Use Case einzubauen. Kein Browser Caching, Revalidation After 15 Minutes, aber dann ja, steil, weil Revalidate. Also es gibt ja so viele Optionen da, die du da auch hast, wo ich sagen könnte für 99% deine Use Case mit Static Site Generation, das kannst du genauso auch mit Server Set Rendering in Caching Headers machen. Und da kommen wir dann eben zurück, dass die Remix Founders da so eine Philosophie haben, eher auf die Browser Standards zurückzugreifen, anstatt das Rad versuchen neu zu erfinden mit Static Site Generation und solchen Sachen. Aber natürlich auch alles persönliche Präferenz. Und eine Sache kann vielleicht komplexer sein, wenn du „Statixile Generation in Next US, ist ein Konflikt, ob es über Emotionen oder so, kann vielleicht einfacher sein. Also es ist Trade-outs auf jeden Fall. Ja, cool. Vielleicht, also die Frage, die bei mir auf jeden Fall bei den Formularen, ich finde das hast du alles, den Unique Selling Point davon hast du glaube ich sehr gut rübergebracht, was wir am Anfang ein bisschen gemeint haben, bevor wir gleich mal auf diese Spinner kommen, was da eigentlich bei dieser Marketing Seite, was damit aufschlägt. Bei den Formularen, ich würde es jetzt so verstehen, du hast ja gemeint, die Formulare haben, also einerseits die Default-Behaviour, wenn kein JavaScript da ist, aber ansonsten macht Remix ein Prevent Default und hat dann die Eigenimplementierung davon, von dem Fetcher hintendran passiert. Das heißt, ich werde ja irgendein Formobjekt wahrscheinlich von Remix nutzen, damit das funktioniert. Das heißt, mein Form ist jetzt kein HTML Form, sondern irgendwie irgendwas, was ich von Remix importiere. Ist die Annahme richtig oder ist das.? Ja, also quasi du kannst einfach dein ganzes males HTML Form benutzen mit Remix. Aber das würde natürlich dann bei Default einen Full Page Reload machen und Seite wird neu laden, aber es würde funktionieren. Und dann kannst du eben von Remix die Form Component importieren, die quasi dann noch ein bisschen JavaScript obendrauf wirft. Und die kann zurückfallen und auch wie eine Form agieren. Aber eben wenn JavaScript enabled ist und es funktioniert, dann kümmert die sich eben darum, dass die Loading States klar kommuniziert werden, auf die du dann zugreifen kannst mit Hooks, dass du immer Zugriff auf die Form Data hast, die gerade submittet wird. Das macht übrigens Optimistik UI super einfach. Also wenn ihr darüber reden wollt, mega geil wie das Remix implementiert hat. Und dann geht eben die Submission zum Backend mit einem Fetch Request und die Daten kommen dann zurück, die da return werden von der Action, auf die du dann auch ganz normal mit einem Hook zugreifen kannst. Und was ich dann vielleicht noch eine Sache, die ja auch mega interessant ist, die Remix macht, Remix bei Default, revalidiert alle deine Loader Functions, also dein Get Data immer, wenn du eine Action Submit hast. Das heißt, wenn du was postest, du hättest ein To Do in deine To Do List und du hast in deiner Loader Function fälschst du alle To Do's, die du dann wieder Listen willst. Nach der Aktion wird der Loader getriggert und die React App wird sozusagen geupdatet mit den letzten Daten. Das heißt, du hast immer diese automatische Revalidierung. Das heißt, wenn du in einem Modal im Dialog bist und drei Schichten tief in einer anderen Komponent, würde dann auch das neue To Do Item erscheinen. Also du musst dich nie ums Stale UI oder solche Sachen kümmern. Das heißt. Sie retriggern jegliche Gats, also alle Loader oder wissen sie schon smart, was ich da gerade geupdatet habe? Alle Loader. Okay, du meintest okay, wir haben jetzt diese Form Component von Remix und vorhin haben wir uns über Form Validation unterhalten. Und du meintest ja, da gibt es ja auch irgendwie HTML-inhärente Form Validierung. Was ist denn ein Best Practice, einen Remixform zu validieren? Stell dir mal vor, in dem Flow könnte ich ja wahrscheinlich einfach sagen, ich validiere alles serverseitig und dadurch, dass ich einen Flow immer habe, so nehme ich einfach nur den Response vom Server und mache es dahingehend, validiere ich Client-seitig, nehme ich dafür eine Library, hat Remix irgendwas so? Weil gefühlt ist das immer das andere, so die Bauchschmerzen, die ich habe, wenn ich Formulare machen muss. Ja, ja, ich würde auch sagen, das ist eine von den Areas, wo Remix sich auf jeden Fall noch ein bisschen verbessern kann. Was am Server-Seite oft genutzt wird, ist SERT natürlich. Also egal welchen Rest-API-Endpunkt du hast, du musst immer deine Form Validierung machen. Es ist egal, ob es jetzt ein Form ist oder ein Fetish Request. Und du musst ja aufpassen, dass das Passwort passt, dass die E-Mail nicht zu lang ist. Also du musst es ja immer machen. Du weißt ja nicht, woher die Daten kommen. Also ist es in Remakes auch nicht anders und sortest da ziemlich beliebt, einfach weil du halt damit TypeScript gleich alles getypt hast von deinen Response Daten. Am Client wüsste ich jetzt nicht, dass es da eine Lösung gibt, die wirklich populär ist. Also es gibt natürlich ein paar Form Library und Domain Function ist das was, was ziemlich interessant ist. Aber da weiß ich jetzt auch nicht genug drüber, mehr dazu zu erzählen. Es gibt ein paar Form Validierungslibraries. Ich dachte. Vielleicht gibt es da irgendwie hat Remix irgendwas, also keine Ahnung, dass man komplett auf Client-seitige Form Validierung verzichtet, weil man sozusagen immer so einen engen Loop hat und irgendwie alles nur serverseitig und dann wieder runtergibt und irgendwie in der Antwort dann die validiert. Also okay, da ist es eher so, so wie ich es sonst auch mache, werde ich es auch. Da machen. Genau das ist dann der erste Augenblick in Remix, wo du deinen ersten Rack State definierst. Okay, cool. Ja, aber dann Formulare glaube ich, soweit verstanden. Vielleicht, wenn wir wirklich irgendwie nochmal die Marketingseite aufmachen, irgendwie gefühlt nochmal zu verstehen, was denn, wenn ich die Seite aufmache, sind da ganz, ganz viele Loader und wenn ich mir Remix angucke, ist da irgendwie ein Loader. Das ist das, was ich noch weiß. Kannst du uns sagen, was es damit auf sich hat? Ja, müssen wir wieder über Formulare reden. Ihr wisst das bestimmt auch in View und React ist es auch so, dass wenn du ein Fett-Request machst, dann hast du deinen State, wo du sagst ist Loading, ist Pending, wie auch immer. Und dann zeigst du eben den Loading-Spinner an oder irgendeine Progress Bar, während die Request gehändelt wird. Und wenn sie zurückkommt, löst du das eben auf, zeigst einen Success und einen Error State. Und wenn du Client Site Data Fetching machst, also jetzt mit React Query zum Beispiel, oder du hast eben ganz viele unterschiedliche Components auf der Seite, die eben alle Client Site gerendert werden, also kein Server Site Rendering, alles Client Site. Das heißt, du zeigst am Anfang eine weiße Seite an und dann wird dein React gerendert und dann hast du überall kleine Components, die anfangen, ihre Daten zu fälschen, die sie brauchen. Dann werden die alle ihren eigenen Loading State handeln müssen und anfangen kleine Spinner zu zeigen in der Gegendwo sie wo sie laden. Vielleicht hat deine Seite einen großen Spinner, aber genau generell ist es so, dass dann poppen die Comments auf und da hinten laden noch die Images und da hast du noch die Likes, die laden. Und das ist halt. Dieses Posting. Ich hoffe mal, dass du überhaupt einzelne Loading Spinner gemacht hast oder sie poppen halt einfach so rein. Ja, das würde mal tippen machen vielleicht auch viele. Ich dachte du sagst es. Hoffentlich hast du Likes. Also wenn du auf Twitter zum Beispiel guckst, so ein bisschen dein Networks Trolls im Network Tab, dann siehst du genau, was sie meinen. Also da hast du in der Mitte die Tweets, die laden. Auf der Seite hast du die News, da ist ein Loading Spinner. Dann hast du da noch irgendwelche anderen Side Panels, die alle rein laden. Und das ist eben was, was die Remix Devs als Spinner Get on bezeichnen, wo sie halt sagen Hey, das ist doch ein bisschen wild und vielleicht gibt es da eine bessere Lösung. Und was man dazu auch sagen kann, was verwandt das Thema, wenn du Client Set Rendering machst, schickst du erst mal eine Request, das HTML zu bekommen. Dann kriegst du das HTML zurück. Das ist ein MT-Div. Das ist da, wo deine React App dann rein rendert. Dann siehst du in dem HTML-Dokument: Aha, ich brauche ein bisschen JavaScript, ein paar Bundles. Also macht der Browser die Requests, das JavaScript zu kriegen. Dann downloadet der Browser das JavaScript. Dann fängt deine React App an zu rendern, die Component rendern und dann fängst du an Data Fetching zu machen. Und dann jede Get Request ist dann wieder eine Request. Also hast du dann drei hintereinander Roundtrips zu dem Server: HTML, JavaScript und dann deine Daten. Jetzt mit Remix: Wenn du den initialen Page-Load machst mit Remix, trägst du das HTML-Dokument an und dann am Server triggert Remix die Loader. Das ist das Server-side Data Fetching, wo du deine Daten fälscht und dann wird am Server auch deine React App gerendert. Das heißt, wenn das HTML zurückkommt, sind schon alle deine Daten da mit deinem HTML und es war ein Client Server Launcher. Und vor allem auf … Ich sage jetzt mal, im deutschen Zug mit 3G ist eine Roundtrip versus drei Roundtrips, damit du deine Sachen siehst auf der Website macht natürlich einen deutlichen Unterschied. Genau. Und du brauchst keine Spanners, weil du hast eine weiße Seite, die angezeigt wird, bis das HTML zurückkommt. Und wenn das HTML zurückkommt, siehst du schon all den Content. Also eins versus drei Roundtrips und keine Spanner. Okay. Und wenn ich jetzt ketzerisch fragen würde, was ist da jetzt anders zu anderen Frameworks, die Server-Side-Rendering machen? Wir sind nicht so, wir sind glaube ich nicht die, die jetzt super viel Server-Side-Rendering bisher machen. Ich hätte jetzt mal erwartet, dass mir Next. Js das Gleiche erzählt. Firstpain sozusagen die erste Seitenaufruf. Wir machen alles, schicken die Gründer die Seite zurück. Den Spinner brauchst du eigentlich auch nicht. Ja, ist genau dasselbe. Ich würde. Wahrscheinlich die Spinner haben wollen würden, wenn diese Requests extrem teuer wären oder wenn sie zum Beispiel initial nicht sichtbar sind oder sowas. Ja, auf jeden Fall. Und das ist dann, wo die Nuance anfängt und wo du dann auch sagst okay, wie macht das Next Jazz und wie macht es Remix. Der Default Case in dem Hinsicht ist natürlich gleich. Was ein NextJS verändert sich ja auch gerade ziemlich wild. Also die neue Version ist ganz anders. Also wenn ich jetzt sage NextJS, meine ich vielleicht eher NextJS vor einem Jahr. Da war mehr State of the art, dass du doch dann auch noch React Query benutzt, eben und Client Site Fetching machst. Also da hättest du dann auch noch die Spinner, einfach weil dieses Get Statics Side Probser, wie das hieß, nicht so oft genutzt wurde, aus was auch welchen Gründen auch immer. Aber ja, prinzipiell jetzt mit dem NextJS letzte Version vor allem mit React Server Components ist das mit den Spinnern genau das gleiche zwischen NextJS und Remix. Aber dann, wie löst du eben solche Probleme, wenn eine Request du du, du fälschst die Tweets und du fälscht dann für jeden Tweet dann auch die Comments. Die Comments sind erst mal nicht zu sehen, sind auch nicht so wichtig, ist nicht die Priorität, dauert aber unglaublich lange zu fälschen. Dann hast du eine längere Wartezeit mit einer weißen Seite, wo du eben nichts zeigst, weil du eben auf alle Daten am Anfang wartest, eben auch auf die Comments. Und wie kannst du das verhindern oder verändern? Und wie Remix das macht, ist das Stichwort ist Differe. Differe ist die API, die sie benutzen. Du kannst also spezifische Promises in deinen Loader Function diffören. Also wenn du deine Loader Function Daten returnst und ein paar von diesen Daten die du returnst, sind noch Promises, also die sind noch gar nicht Results, sondern anstatt ein Array mit Comments zu returnen, returnst du ein Promis, das dann in der Zukunft ein Array mit Comments returnst. Dann versteht das Remix und gibt dir dann auch in deiner React App das als Promis. Das heißt, du kannst einfach den Rest schon mal rendern und das Promise gibst du dann an eine React Suspense Boundary und das ist jetzt, wo es ein bisschen kompliziert wird, das zu erklären. Aber quasi was passiert ist, dass du das einfach an deinen, du hast dann so zwei Components, eine von Remix, eine von React, mit der du den Teil von deiner UI dann wrapsst, sagst: „Hey, das ist eine Suspence Boundary. Das heißt, das sind Sachen, die jetzt noch nicht am Anfang da sind und wir müssen auf dieses Promise hier warten. Und dann kannst du noch eine Fallback UI anzeigen, also dann hast du wieder einen Spinner. Aber du hast ganz genau gesagt: „Hey, hier brauche ich einen Spinner, weil da hatte ich ein Bottomck und jetzt macht es Sinn. Aber bei Default bitte nicht. Okay, cool. Das heißt, da kann ich wirklich sehr feingranular im Endeffekt, also sozusagen einfache Antwort wäre erst mal alle weg. Und wenn ich dann merke, der einzelne Spinner hatte vielleicht doch seinen Sinn, nicht ewig lang auf das Ergebnis zu warten, kann ich es dann wieder hinmachen und da nutze ich dann dieses Differe. Also ich liefere nicht einfach nur einen Promis zurück, sondern irgendwie oder ist es einfach nur wirklich in der Loader Function Return ein Promis und damit wird intern irgendwie die Diffur genutzt? Genau. Also ich mit diesem Differe selbst interagiere ich nicht, so ist das Konzept und unterunter ich return entweder das, ich erwarte entweder das Promis oder ich gebe es Promis zurück in der Loader Function. Genau. Du hast ein paar Helper Functions in Remix und eine von denen heißt Diffur. Also was du in der Loader Function returnst, ist immer ein Response Object. Also du hast schon vorhin gesagt, du hast Fatch Response und Fatch Request. Das sind die zwei Objekte, mit der die Web Plattform arbeitet und die halt Remix auch benutzt. Das heißt, du musst immer ein Response Object returnen. Aber damit es ein bisschen einfacher ist, kannst du auch einfach Json returnen und Remix macht es dann schon in einem Response Object. Und dann gibt es ein paar Helper Functions, die dir eben helfen Json zu returnen, aber eben auch HTP Headers und so weiter. Und eine von diesen Helper Functions heißt Differe. Und wenn du Differe benutzt und einfach dann ein Json Object als Parameter eingibst, dann kannst du ein paar Reserve Promises und ein paar nicht Reserve Promises übergeben. Und Remix weiß dann genau wie das halt das handeln soll. Heißt das für diese Komponente wird dann unter der Haube irgendwie noch ein separater Endpunkt erzeugt, der dann im Browser per Import irgendwie erwartet wird oder so? React 18 Streaming ist da das Stichwort. Also React hat schon Streaming Capabilities, die auch bei Default benutzt werden von Remix, einfach die Dokument Requests zu streamen. Also du hast einen Response Stream immer bei Default mit Remix und React. Und derselbe Stream wird eben dann auch genutzt, Daten später noch hinterher zu streamen. Und dadurch, dass das ist quasi eine React Capability. Also React versteht das Streaming eh schon und React hat dann eine Komponente, die heißt Suspens, die eben auch versteht auf sozusagen der Fall to data nachträglich dann also erst mal die Fallback zu rendern und dann nachträglich das Promis zu resolven. Also das passiert alles auf HGP Streaming und dann hat React eben noch obendrauf, Primitives, die mit denen Remix dann arbeitet. Was aber natürlich auch bedeutet, dass das nicht mit allen Servern out of the box funktioniert. Also dein Server muss HGP Streaming supporten. Welcher tut es nicht? Heutzutage hoffentlich alle, aber war nicht Herr Rugkuh lange Zeit, dass die kein Streaming supportet? Also es gibt auf jeden Fall ein paar Server, die mit Edge, Edge supportet auch Streaming, glaube ich, aber viele Serverless-Envirements haben lange kein HTP-Streaming supportet, eben weil die ja nach zehn Sekunden aufhören müssen und so weiter. Also auf jeden Fall was, was man checken sollte. Aber bei Default, wenn du Remix ein Projekt startest und sagst, auf welchem Server du aufbauen willst, wenn der Server HB Streaming supportet, dann kommt Remix Out of the Box mit das alles schon angebaut. Cool. Und ich glaube, du hattest vorhin, wenn ich die Marketing Seite noch mal zu Ende durchgehe, vorhin schon mal so ganz grob angesprochen, als wir über die Spinner gesprochen haben. Ich sehe noch am Ende irgendwie, wenn was schief geht, meine einzelnen Komponenten, also diese Error Boundaries, ich glaube die Error Boundaries als Begriff hast du mal irgendwie gedropt, aber kannst du uns da noch was drüber erzählen? Ja, ganz kleines Herz ab. Remix ist gerade in der Version eins, aber die arbeiten gerade sehr stark daran, in Version zwei zu kommen. Und ein paar von den Sachen, die ich jetzt gerade erkläre, werden sich vielleicht ändern. Aber zurzeit hat Remix eine catch und eine Error Boundary. Also eben in deinen Routes kannst du deine Rack Component exportieren und eben auch eine Error Boundary Component und eine catch Boundary Component. Und quasi wenn in deinem Loader ein Error geworfen wird, dann wird die Error Boundary oder die catch Boundary gerendert anstatt der Component. Und ich bin selber immer ein bisschen verwirrt, was die catch Boundary und was die Error Boundary ist, weil das wird wahrscheinlich die nächste Frage sein. Quasi das ist der Unterschied zwischen Exceptions and Error. Also wenn du ein throw Error, dann ist es ja was Unerwartetes, versus du kannst ja Response Return in Remix, also Loades and Action Return and Response, nicht Json. Und wenn eine Response einen anderen Status Code hat als 200, dann wird die, ich glaube Error-Ownary gerendert. Okay, ich hätte jetzt KED war ja gut. Das ist nicht Kette. Wie rum oder? Ja gut, wäre das entweder das eine oder das andere. Also zum Beispiel. Aber ja, du hast dich selbst rein manövriert in die Frage. Ich hätte die vielleicht gar nicht gestellt. Wenn ich zum Beispiel einen 404 werfe. Du würdest einen Beitrag anschauen, dann wirst du einen 404, dann wirst du eine 404 Error Response werfen und dann würde glaube ich die vielleicht catch Boundary oder Error Boundary gerendert werden. Das heißt, du kannst in der in den Boundaries dann auch, du weißt, welche Error geworfen wird, du hast Zugriff auf die Exceptions quasi, kannst gucken, welcher Status Code und darauf basierend dann deine Error Komponente rendern. Und das geile daran ist, dass du eben kein React State brauchst, das zu... Dieses if Error State, dann rendert diesen Part von dem React-Tree, anderweitig return, diese Component, das fällt alles weg, weil du das nicht alles in deiner Component managst, sondern du hast drei unterschiedliche Exports. Und das ist etwas, was Remix meint, wir machen alles deklarativ. Das heißt, in dem File exportiere ich einerseits, wenn wir jetzt keine Ahnungein Formular hätten, das Formular, hätte es Formular. Also ich habe Loader Action, ich exportiere ein Formular als auch eine Error und eine catch Boundary? Yes, genau. Also vom vom UI Code ist es genau dasselbe. Aber was wegfällt, ist das ganze if/else, State Management and React. Das Form ist sozusagen clean und ich kann einfach schauen, okay, Error, catch kann ich mir unten noch mal weiter anschauen. Genau. Finde ich, finde ich bei so einer Komponente so ein Konzept wie bei NACST Layoutshaben wollen würde, dann baue ich mir das selber, indem ich mir so eine Komponente bei jeder Seite drum rum baue oder? Gute Frage. Das habe ich jetzt noch gar nicht erwähnt. Also die letzten Versionen von Rack Router und eben auch Remix haben implementieren ein Nested Routing, eine Nested Routing Konvention. Was das quasi heißt ist, dass du kannst Layouts als Road Files definieren und dann wieder andere Rodes in Rodes Nestenund dann in einem ParentRoute definieren, wo der Nested ChildRoute sich eben hin rendern soll. Und Version 1 und Version 2 haben da zwei unterschiedliche Route, File, Konvention, also das ist auch gerade alles eine Änderung. Aber quasi hast du bei beiden die Möglichkeit zu definieren: „Hey, das ist mein Layout, mein Root Layout, dann habe ich Nested Layout, noch mal ein Nested Layout und das ist jetzt die aktive Seite. Und du kannst es so extrem machen, du könntest zum Beispiel eine, das letzte ChildRoute könnte nur ein Modalein klarer Dialog sein. Da machen diese Boundaries auch mehr Sinn, weil die würde ich wahrscheinlich irgendwo weiter oben vielleicht ansiedeln, falls dann irgendein Trial oder einer von meinen 28 Block Posts Snipplets nicht lädt, oder sowas. Oder du zeigst nur in der kleinen Comments Section ein Warning Error an, dass das gefehlt hat zu laden und alles andere ist trotzdem da. Das ist eben auch die Power von Nested, catch Boundaries und Error Boundaries. Die letzte, die definiert ist, wird gezeigt. Aber je weiter du eben Nested bist, wenn was schief geht, wird nur die lokale Error Catch Boundary gerendert. Interessant, cool. Ja, ich glaube, da muss ich mir dazu, glaube ich, den Baum noch mal anschauen mit den, ich glaube, wie du hast, konntest du ihm gut folgen mit den Nested Child Components und so weiter, wie ich dann, also ich habe mir jetzt gerade vorgestellt, wie ich meine File Hierarchie sozusagen anlege, weil du meintest, auf der obersten Rootebene, da habe ich irgendwie einen Layout definiert. Also wirklich, wenn ich auf eine Pfeilstruktur gehe, habe ich da oben einfach einen Pfeil, was mein Layout ist und dann andere sind in Subfoldern. Und aber die Child Components können sagen, was das Main Layout ist und die können noch mal sagen, zu welchem Layout sie gehören oder wie? Simpler. Ich werde es jetzt in der Remix Version One Road Konvention beschreiben. Mit dem Beispiel, du würdest jetzt mal ein bisschen verändern. Da kann man ja doof reden. Aber quasi stell dir vor, du hast ein Slash Dashboard. Das ist dein Dashboard. Dann würdest du ein Dashboardfolder anlegen und alle Roads, die dann Slash, eine User, Slash Accounts, was auch immer dann in Dashboard drinnen ist, würdest du als File in dem Dashboardfolder anlegen. Und jetzt sagst du Hey, alle diese Dashboards, Nested Routes sollen dasselbe Layout haben. Was du dann machen kannst, ist ein File anlegen, das genauso heißt wie der Dashboardfolder, also einfach Dashboard. Tsx. Und das ist dann auch ein ganz normaler Road Component, die auf den Slash Dashboard Road oder Pass Segmentmatcht. Und in der hast du dann auch eine Rack Component und du kannst dann von Remix eine Component importieren, die Outlet heißt und die kannst du dann irgendwo rendern. Und da wo das Outlet ist, wird dann die Child Road reingeladen. Also in dem Layout, also quasi im Dashboard Layout kannst du sagen hier ein Navbar, ein Futter und in der Mitte ist dann mein Outlet. Und wenn du dann bei /dashboard/index/dashboard/users oder so wirst, wird dann das spezifische Child-Rout in den Outlet reingeladen. Danke. No it makes sense. Und in der wahrscheinlich in der Dashboard-Layout-Komponente kann ich dann auch auf meine Parameter zugreifen von meinem Request. Ganz normal, so wie in den anderen Komponenten auch. Genau, du hast einen Loader, einen Action, du kannst Forms da haben im Footer theoretisch, die dann auf den Dashboard Road submiten. Du hast eine Error Boundary, Meta Tags, die du sharen kannst mit allen deinen Kindern. Styl Sheet kannst du importieren. Angenommen, dieses Dashboard ist jetzt in einem übergeordneten Design, weil irgendwie die ganze Seite einen schönen roten Rahmen bekommen soll. Das ist immer schön bei Dashboards. Ja, das ist schön. Wie wäre da die Konvention? Oder genauso würde ich dann auf Root eben einen Index anlegen und da das Outlet reinpacken mit dem roten Rahmen? Gute Frage. Ja, du hast einen Root. Tsx-file, das ist sozusagen, das ist da, wo dein HTML Tag definiert ist und dein Head Tag. Und da wird dann alles reingeladen in den Body. Da könntest du natürlich ein globales Layout auch reinbauen, wenn du willst. Aber du kannst auchfolder definieren und dann eben auch wieder diese ParentRoutes oder LayoutRoutes. Also Beispiel Dashboard hatten wir DashboardFolder und Dashboard File. Du kannst auch einfolder File Kombination machen, die du mit einem DoubleUnderscore anfängst, also in dann irgendein Name ist egal, sagen wir mal Layout. Und das sind dann auch Layout Routes, die aber nicht die URL verändern. Also quasi kannst du 50folder Hierarchien nach unten gehen. Und wenn die alle mit underscore anfangen, dann werden die nichts in der URL ändern. Also du kannst underscore_layout und da drin hast du einen Dashboard-Folder, dann wärst du immer noch /dash-Folder, aber du hast eben einen Folder und einen Pfeil, wo du noch. Layout definieren kannst. Das heißt, ich hätte Root T6 und der mache ich gar nichts, was den Style angeht, dann mache ich in dem ‘Anderscore’ Layout – und da packe ich einfach alles, meine gesamte Applikation rein – in dem ‘Anderscore’ Layout habe ich irgendwie CSS und sage hier „Rote Border, alle. Hauptsache „Rote Border, Yes. Und. Jetzt mit ‘V2’ kannst du auch komplett verrückte Sachen machen, die ich selber noch nie ausprobiert haben. Du kannst dann auch sagen Hey, dieses File soll eben nicht von dem Layout in das Layout reinrennen, auch wenn du in der URL zwar da irgendwo ganz tief drin bist. Dieses Route soll eigenständig sein und ganz wilde Geschichten. Aber du kannst sehr viele Sachen machen und die Route Konvention, wenn du versuchst alle Regeln dir durchzulesen, ist auch ziemlich kompliziert. Aber dadurch hast du halt auch unglaublich viele Tools zur Verfügung. Ja, cool. Du hast vorhin noch gemeint, wenn wir Lust haben, können wir darüber noch reden. Mich würde es auf jeden Fall noch interessieren. Du hast im Zuge der Forms hast du davon gesprochen, dass du ein bisschen optimistisch UI als Begriff hast du, glaube ich, hingeworfen, mit dem ich nicht so viel anfangen kann, aber du sehr enthusiastisch wirktest. Kannst du mir was darüber erzählen? Ja, also Optimistik UI ist quasi dieses „Hey, 99%, sagen wir mal ehrlich, 99% aller Fatch und Post Requests sukceden ja hoffentlich in deiner Applikation. Gehen wir mal davon aus. Kann auch die. Sla sein. Wenn nicht, hast du vielleicht andere Probleme. Genau. Und dann ist es ja quasi ein Rack, kannst du ja machen, was du willst. Du hast ja States und du weißt ja, was du mitwird an Daten. Jetzt sagen wir mal wie eine To Do List. Du weißt den Namen und die Description von der To Do, die du in dem Forum ausgefüllt wirst, wenn es vermittelt wird. Also warum auf die Response warten, wenn du die Daten eh schon hast, die du dann quasi anzeigen kannst? Wenn du eine To Do Liste hast, kannst du auch einfach schon eine To Do List dort Push machen und dann einfach optimistisch sagen Hey, das wird schon Sack. Sieben, jetzt fügen wir schon mal hinzu. Aber jetzt überlegt euch mal, wenn ihr das alles selber in React macht, wie viel nervigen Code ihr schreibt. Weil jetzt habt ihr das schon hingepusht, aber das To Do hat noch keine ID. Also müsst ihr irgendwie dann checken, dass wenn das keine ID hat, dass man dann das nicht löschen kann oder so, weil es ist ja noch nicht wirklich ein To Do. Aber auch was passiert, wenn dann eine Error kommt? Dann musst du wieder if Error Filter Update keine Ahnung, all Chaos und Success Case ja auch. Deswegen machst du es nicht, würde ich sagen. These, du machst es nicht. Jetzt sind wir auf einmal ein bisschen pessimistischer. Genau deswegen ist Optimistisch UI auch unglaublich schwer und kompliziert, eben wegen dieser Synchronisierungsphase. Und wenn du es richtig machen willst, musst du halt unglaublich viel bedenken. Und wenn du es nicht richtig machst, geht halt viel falsch. Remix macht es unglaublich einfach. Du hast einen Hook, der heißt Use, jetzt muss ich kurz nachdenken, ich glaube Transition, Use Transition, die haben das geändert. Jetzt heißt es glaube ich Use Navigation, weil es gibt einen Use Transition Hook jetzt in React. Also jetzt heißt es Use Navigation. Und du kannst sozusagen auf ein globales Navigation Objekt zugreifen, was dir immer sagt Hey, habe ich gerade ein Forms Admited, bin ich gerade in einem Loading State und du kannst es eh benutzen, irgendwelche Progress oder Spinner oder irgendwelche Forms Submissions zu desabeln. Also du hast gerade ein To Do Submitten, also Navigation dort, State eq Loading ist dann quasi, wo du dann deine Loading, Pending Sachen anzeigen kannst. Aber mit Navigation hast du auch immer Zugriff auf die Form Daten, die gerade in dem Moment committed werden. Das. Heißt, du hast Zugriff auf Form Data dort Name oder dort Description von deinem To Do, das du gerade sendest. Das heißt, wenn du was sammelst, kannst du in einer Liste von To Do's quasi einfach dieses globale Objekt nehmen und sagen Hey, wenn das ein Submission ist zu meinem Create To Do. End. Point, dann füge am Ende einfach noch ein To Do in die Liste hinzu. Und du musst es nicht in dein State pushen oder so, weil du das einfach du hast, machst du einfach am Ende deiner Liste wo du mappst, machst du einfach noch ein weiteres, was nicht im Area ist. Hey, wenn wir gerade Pending sind, zeig noch ein neues an. Und das Geile ist eben, dass du dafür kein React State brauchst, weil du hast ein globales Objekt, du renderst es unten an und ab dem Moment, wo das Success in Remix, habe ich schon vorhin angesprochen, dass alle Loaders werden revalidiert. Das heißt, du kriegst automatisch das neue To Do Array von deinem Loader Data, was eben auch das neueste Objekt beinhaltet. Und wenn der Loading State vorbei ist, ist das FormData Objekt wieder leer. Das heißt, es verschwindet einfach wieder, das ist weg, aber das andere kommt wieder rein und dadurch verändert sich die Liste nicht, schaut wieder genauso aus wie vorher. Aber du konntest es eben schon optimistisch anzeigen. Cool. Ja, in den Fällen wäre ich auch optimistisch. Automatische Resynchronisierung am Ende und dann eben mit den Error-Boundaries und so ist auch unglaublich einfach, dann die Error-Case oder nicht unglaublich einfach, Errors immer in der Richtung zu handeln, aber ist auf jeden Fall einfacher und es fühlt sich ein bisschen releganter an und das alles halt ohne deinen eigenen React-State definieren zu müssen. Genau, einfach zumindest was du auch meintest, mit dem ich kann es nicht löschen, so solange es halt noch in Navigation drin ist, die desable ich halt, ein Deal-Button oder so, ist irgendwie alles ein bisschen einfacher. Klingt auf jeden Fall cool. Ja, und weil ich es jetzt noch nicht erwähnt habe, kurz. Es gibt mehrere unterschiedliche Arten und Weisen Forms zu bauen in Remix. Also ich habe jetzt von dieser Form Component geredet und von dem globalen Navigation Objekt. Das ist gleich die nächste Frage natürlich, was passiert, wenn du zwei Forms gleichzeitig sammelst oder du löschst ein To Do und du sammelst ein To Do. Dann funktioniert das ja nicht mehr so sehr, was ich gerade beschrieben habe. Du kannst auch isolierte Forms bauen mit einem Use Fetcher Hook und der Use Fetcher Hook hat dann eine Form Component und der Use Fetcher Hook quasi hat dann seinen eigenen Loading State, seinen eigenen Form Data. Das heißt, du hast dannkleine, indepent Forms, die alle ihren eigenen State handeln können und parallel voneinander agieren, versus dieses globale Form mit dem globalen Loading State. Und da wird es dann ein bisschen komplizierter. Da muss man dann schauen, was in welchem Fall mehr Sinn macht. Zumindest halt To Do erstellen und dann gleichzeitig in der Liste anzeigen. Wenn ich es auch noch, also dann hätte ich wahrscheinlich den Erstellen irgendwo in der eigenen Komponente und dann würde ich es vielleicht nicht so einfach in die Liste jetzt reinbekommen wahrscheinlich oder wenn es nicht globaler State ist? Genau. Und dann würde man sagen okay, das Erstellen von einem To Do ist so die Hauptaktion auf der Seite. Das will ich global accessible haben, diesen Forms-State und so, dann würdest du es vielleicht mit einem normalen Form Component machen. Und das ist schon eher als.? Immer wenn du eine Formaktion in der Liste hast, ist das ein ganz gutes Beispiel für das soll ein isolierter Use Fetcher Form sein, weil jedes Deal hat seinen eigenen Loading State und die musst du getrennt voneinander anzeigen und die sollen sich nicht überschreiben und so weiter. Okay. Das heißt, dann überlege ich eher, was ist das globale, was soll schnell da sein? Wo macht es Sinn, es zu isolieren? Genau, so ein Kontaktformular z. B. Im Futter soll ja immer isoliert wahrscheinlich sein. Und ja, da geht es super ins Detail. Auch globale Transition, Formsummission in HTML oder ganz normal Browser Standards ist ja eine Navigation. Und mit einem Remix Form hast du eben auch diese Navigation. Das heißt, bei Default navigierst du zu der Action, die du aufrufst, zu dem Route. Und mit Usefetcher ist das anders. Mit Usefetcher fühlt sich das mehr nach einem Fetcher Request an. Ja, cool. Insebi, du guckst gerade noch so, als hättest du dazu... Ich habe mir gerade überlegt, wenn ich gerade dieses Beispiel mit... Ich habe eine Liste und davon die Elemente will ich löschen. Wie genau? Also dann drücke ich... Ich mache jetzt Klick, Klick, Klick und das Element soll dann weggehen. Habe ich dann... Also passieren dann drei Page Refreshes oder wird wirklich kleinseitig nur dieses Element weggelöscht? Also was passiert da unter der Haube? Ja, ja, das ist auch, wo es dann ein bisschen komplizierter wird und ich mir auch schwer tue, das zu beschreiben. Wenn du jetzt einfach ein form element benutzen würdest, ganz normales HML Formelelement, dann würde genau passieren, was du sagst, du trickst dreimal schnell und wahrscheinlich würde nur das dritte Submited werden, weil du nur ein form submission gleichzeitig machen kannst und die anderen zwei werden abgebrochen und du hast eben einen Full Page Reload. Und wenn du dann die Remix Form Component nimmst, versucht Remix eben das zu emulieren. Das heißt, du hast drei Requests. Die ersten zwei werden abgebrochen. Das heißt, die werden trotzdem sendet. Also der Server kriegt das schon mit. Du kannst ja nicht die Requests zurücknehmen, wenn du die einmal abgeschickt hast. Aber Remix wird sozusagen vom UI nur die letzte Submission handeln. Aber weil du eben ein globales Navigations Objekt hast, würde der Loading State an allem DELETE Icons true sein. Weil du hast ein Navigation. State ist Loading State, den checkst du überall, das heißt überall mehr ein Pending State, auch bei denen du nicht angeklickt hast. Und das ist natürlich nicht was du willst. Das heißt, hier macht ein globales Form mit einer globalen Navigation keinen Sinn. Und was du dann benutzt, ist eben den Use Fetcher Hook und benutzt das Use Fetcher dort Form. Das heißt, du würdest eine To Do Item Component haben. In allen einzelnen To Do Item Components hast du dann ein Use Fetcher Form mit dem DELETE Button und die haben dann einen isolierten Navigation State und die navigieren auch nirgendwo hin bei Default. Das heißt, du klickst den DELETE Button. Nur das Use Fetcher State wird jetzt zu Loading gestellt, alle anderen nicht. Und du wirst auch nirgendwo hin navigiert, sondern es ist wie ein Fetche Request. Das heißt auch dieses, was du am Anfang meintest, bei Formularen wird jeglicher Loader Function wieder ausgeführt global. Das stimmt dann in dem Fall nicht mehr so? Das ist immer. Immer wenn du eine Action Function, das ist quasi eher immer, wenn du eine Action Function aufrufst, wird alle Loader getriggert. Das heißt, ich mache drei Delets, das heißt dann mit drei mal kurz nacheinander einfach alle Loader wieder getriggert. Wenn ich drei Delets schnell mache. Ja, aber da ist es dann geil, dass Remix das rausfindet und das schafft alle, die Requests werden trotzdem abgebrochen in der Hinsicht, dass du hast die Requests, du siehst die Loading States, aber nur die letzte Revalidation wird ausgeführt. Okay, das heißt dann warte ich dann auf die dritte. Okay, cool. Das ist richtig geil im Network Tab, dass dann „Aboard Control, „Aboard Control, also rote Requests werden halt gecancelt und dann nur die letzte wird ausgeführt. Und das funktioniert erstaunlich gut. Ja, cool. Ich. Glaube, wir haben jetzt schon echt ziemlich gut verstanden, was Remix ist. Eine kleine Anekdote. Ich weiß gar nicht, ob das wert ist darüber zu sprechen hat, aber ich hatte irgendwann schon mal probiert, Remix auszuprobieren. Das ist schon eine ganze Weile lang her. Und damals, erinnere ich noch, gefühlt musste ich mich am Anfang entscheiden, welches Stack ich benutze. Es gibt ja auch an der Doku das Remix-Stack. Und witzigerweise habe ich mich dann für eins entschieden und ich bin dann mein Versuch, mich ein bisschen in Remix reinzuarbeiten, ist daran gescheitert, dass ich schon interessant fand, was das Stack mir dazu zu bieten hat, nämlich das hat mich damals auf das Prisma OEM gebracht. Und dann habe ich auf einmal gemerkt, Prisma interessiert mich und bin dann an der Prisma Doku hängengeblieben und hat mich dann erst mal mit Prisma beschäftigt. Also von daher Probs und Remix scheinen gute Stacks zu sein, aber ich war dann interessiert, als man da Unterkomponenten hat und irgendwie da war der Forschungstag auch schon wieder vorbei, als ich mich dann mit Prisma beschäftigt habe, was glaube ich auch hier schon des häufigeren seitdem mal in unseren Pick of the Days stattgefunden hat. Aber ich weiß nicht, deswegen eigentlich ist die Frage so ist es denn also war das, was ich da gefühlt so am Anfang ich mach Remix, muss man erst mal entscheiden, nehme ich Blues, Indie oder Grunch Stack? Ist es so eine Entscheidung, die man am Anfang trifft oder bin ich da irgendwie falsch vorgegangen? Ich habe die Stacks noch nie selber benutzt. Okay, du hast bei Remix sozusagen zwei unterschiedliche Boiler Plate Levels. Eine heißen Adapter und die anderen heißen Stacks. Und Stacks sind eher diese Hey, ich möchte nicht Login und Sign-Up selber implementieren. Ich will, dass das alles schon Out of the Box kommt und ich weiß eh, dass ich MySQL-Database benutzen möchte und zu Versaild deployen, jetzt als Beispiel. Weil man kann es ja in den drei Stacks nachlesen, was genau da drin ist. Aber das kommt sozusagen mit ganz vielen Sachen schon implementiert, aber halt als Boiler-Pläck-Code, das heißt du kannst das alles ändern, ist nicht abstrahiert oder so. Und eben mit deiner Datenbank schon und Docker und all den coolen Sachen schon Out of the Box. Ich finde das immer selber persönlich solche Stacks oder... Also ich finde ich solche Stacks, also so Poiler Black Solutions viel zu... Ja... Overweldigend, weil da ist dann Testing schon drin und ich will das... Wenn ich das selber baue, habe ich immer das Gefühl, dass ich selber besser verstehe, was das macht und dann kann ich selber besser Debuggen, falls was schief geht. Also ich benutze selber nie Stacks. Was es natürlich auch gibt bei Remix, ist, dass du ganz normal wie bei Nax oder Nexts eine CLI Tool benutzt, eine neue App zu bauen und die wird dann Clean State on Empt sein. Aber da musst du dann auch deinen Adapter auswählen. Weil ich schon wie vorhin schon gesagt, Remix ist kein Webserver, sondern Htp Request Handler auf einem Webserver. Das heißt, du musst immer auswählen, mit welchem Webserver dein Projekt initialisiert werden soll. Also musst du dann sagen Hey, ich will mit TypeScript bauen undExpress. Js. Und dann wirst du ein leeres Projekt bekommen, was halt einen kleinen Server. Js-file hat mit Express. Okay, da merken wir wieder mein nicht hohe Kompetenz darin, Dokumentationen gut zu lesen, sondern eher so, man muss mal irgendein Stack ausprobieren, ich will einfach schnell irgendeins. Aber du hast die Doku doch gelesen von Prisma dann. Ja, genau. Ich habe die falsche Doku dann gelesen, hat mich zur falschen gebracht. Aber okay, dann haben wir das aufgenommen, dann brauchen wir uns auch gar nicht weiter über Stacks unterhalten. Guckt euch das an, wenn es euch interessiert. Ja, cool. Aber ich finde wirklich, ich habe einen sehr guten Überblick über Remix bekommen, was wir sonst am Ende, also außer ich gucke den Sebi mal an, ob dir noch irgendeine Frage auf dem. Herzen brennt. Ich habe mich gerade nur gefragt, wieso haben wir es nicht genommen? Ich glaube wegen React. Einfach gell? Ja, wieso sind wir nicht so im React Ökosystem? Wir sind nicht so im React Game, leider. Und wir sind halt auch nicht, man muss auch dazu sagen, von dem Formular, gerade in unseren Games und sowas, hat der Formular Teil beschränkt. Also so ein bisschen … Das haben wir nicht. Von dem profitieren wir nicht so extrem. Aber ja, ich glaube. Einer von dem Remix Core Team Members ist ein unglaublicher View Fan und seine Mission ist es, Remix auch mit View zum Laufen zu kriegen. Ich habe schon vor einem Jahr gesagt, dass Remix versucht Frontend Framework agnostik zu sein. Stimmt, jetzt habe ich in deinem Blogbeitrag gelesen. Ich traue mich jetzt schon fast nicht mehr zu sagen, weil es jetzt ein Jahr her ist und wir immer noch nur React supporten. Aber der Traum ist auf jeden Fall auch View zu supporten. Und was ist das andere? Projekt. Projekt. Genau. Die zwei werden wahrscheinlich als erstes kommen. Vielleicht weil du gerade auch wir gesagt hast, was wir noch gar nicht so richtig gefragt haben, ist also wenn du sagst wir, wie ich es entwickle, als Open Source Contributor mit oder was bedeutet das? Wir, die erste Frage? Die zweite ist nutzt ihr es eigentlich auch bei LinkedIn? Gute Frage. Ich habe mich einfach nur schlecht ausgedrückt. Wenn ich sage wir meine ich die Remix Community, weil genau das auf jeden Fall wird es wahrscheinlich eher ein Community Effort sein, Vue zu supporten. Genau. Ich habe noch nicht zu Remixxs kontributed, außer zu den Docs, glaube ich, oder mit mit Exampels. Genau. Ich habe einfach nur unglaublich früh angefangen, Remixx zu benutzen und fand die Community sehr geil. Alle waren sehr hilfreich und ich habe, seitdem ich da angefangen habe mitzuarbeiten oder mitzuhelfen oder mich da mit denen zu diskutieren auf Discord und Stack Overflow und wo auch immer. Ja, ich habe unglaublich viel gelernt und deswegen sage ich wir, aber nur als Community. Und nutzt ihr die zweite Frage bei LinkedIn eigentlich irgendwie? Setzt ihr Remix irgendwo ein? Ja, Glyfford hat auch einen Talk bei der zweiten Remix-Kampf gehalten über Remix bei LinkedIn. Generell ist LinkedIn eine sehr gutes Netzwerk. Also ich arbeite zum Beispiel mit Ambers, aber Interna Teams haben meistens ein bisschen mehr Freiheit und da wirst du viele unterschiedliche Frameworks finden, inklusive Remix. Das heißt Customer Facing dann nicht, aber intern bei euren Tools schon? Genau. Cool. Dann bleibt eigentlich nur so die typische Frage zum Ende des inhaltlichen Teils. Ist irgendwas, was du noch über Remix sagen willst, was wir nicht gefragt hast, wo du denkst, warum so was wie mit Optimistik UI, warum habt ihr das nicht gefragt? Das wollte ich doch unbedingt erzählen. Nichts spezifisches. Ich finde die Fragen alle ziemlich gut. Was ich vielleicht Highlighten würde wollen, ist, dass ich Nextjahres mega finde und Lachs und SweltKid und Remix und dass das alles geile Solutions sind. Und ich bin kein großer Fan davon, dass das Framework besser ist als das. Und eben weil sie alle immer ähnlicher werden, ist es glaube ich auch ziemlich hart zu sagen, dass das eine für den Use Case besser ist als das. Das ist alles so tief in den Nuancen und man muss so tief reinschauen, wirklich zu verstehen, ob eins wirklich besser ist als das andere. Was ich aber noch Highlighten will, dass wir eigentlich ziemlich verwöhnt sind gerade und dass wir richtig viele geile Solutions haben. Und ja, ich bin sehr happy mit Remix, aber ich verstehe auch, dass es andere gibt. Es kommt immer darauf an, was man selber präferiert. Ja, cool. Ist doch ein schönes Statement zum Ende auch ein bisschen der Grundtenor, den wir hier in dem Podcast auch immer merken. Wir unterhalten uns über viele Technologien. Viel hat es mit eigener Präferenz zu tun. Aber wie gesagt, Remix etwas. Deswegen vielen Dank, dass du dir die Zeit genommen hast. Wo das Danke sage ich am Ende, weil eigentlich kommt jetzt der Zwischenspieler für unsere Pick of the Days. Sebi. Ich weiß gar nicht, am Anfang habe ich dich gar nicht gefragt, ob du was hast. Deswegen frage ich jetzt:. Hast du was? Ich habe was. Erzähl uns. Mein Pick of the Day ist die App MIME-Stream. Mime-stream. Schon mal gehört? Nein. Schon gehört? Mime-stream ist ein Mail Client für Mac OS, der ausschließlich mit der Gmail API arbeitet und der ist von einem Ex-Apple Mitarbeiter, der an der Mail App mitgearbeitet hat und macht für mich diesen Switch zwischen Arbeits-und Privat-Mail-Account einfach und die Suche ist halt viel geiler. Aber ich kann es auch wirklich nur mit einem Gmail Account nutzen. Weil du Switch meinst, du kannst auch mehrere Gmail Accounts hinterlegenund kannst dazwischen, das machen sie gut irgendwie, also beide. Parallel auf dem Zettel. Und du kannst alle Features, die auf Gmail zur Verfügung stehen, mit den Labels und sowas, kannst du auch verwenden. Und die fand ich ganz nice, habe ich jetzt im Einsatz und die Suche bei Apple Mail fand ich bisher immer, mäh. Ich bin auch mal überrascht, wenn man auf gmail. Com geht und da mal die Suche denkt, so hä, wieso hat meine Mail-Applikation das nicht gefunden? Was ist da los? Genau. Und MIME-Stream schafft es halt mit der. Suche ab. Cool. Dannvielleicht ist für dich auch MIME-Stream. Vielen Dank. Packen wir in die Shownotes. André, hast du was für uns dabei? Ja, MIME-Stream klingt für mich eher wie eine Mediation selbst. Ich habe gedacht, das ist so eine meinvolle Sache. Habt ihr schon mal was von Darknet Diaries gehört, den Podcast? Nee, vielleicht schon mal irgendwo gelesen. Aber eigentlich, nein, meine Antwort muss eigentlich sein Nein. Dann freut es mich, den euch vorzuschlagen. Er ist von Check Resider. Das sind Geschichten und Interviews von Darknet und ja, Geschichten über bestimmte Hacks oder Virus oder auch einfach Interviews mit Social Engineers. Und ja, ich, ganz oft höre ich mir den Podcast an und habe einen offenen Mund, weil es einfach so krasse Geschichten sind, die man sich einfach gar nicht vorstellen kann, was da alles passiert in der Welt. Richtig cooler Podcast. Cool, klingt cool. Ich hatte nämlich auch irgendwann einen Podcast gehört, einen amerikanischen, wo einfach nur in einer Folge irgendein Black Hat Hacker wirklich maleingeladen war und über Dinge erzählt hat. Und damals dachte ich auch so, ich habe auf unserer To-Do-Liste geschrieben, ich will auch mal eine Hackerfolge bei uns machen. Bis heute habe ich zwar ein paar twitter-mäßig angeschrieben, bis heute habe ich niemanden gefunden. Aber cool, Darknet Diaries. Andreas, hast du so eine kleine Geschichte, die man da hören kann, die dir so im Kopf hängengeblieben ist als besonders? Ja, da waren ganz in den ersten Folgen eine Geschichte über einen Hack, wo ein paar Kiddos X-Box gehackt haben. Und am Ende waren die tatsächlich unglaublich tief in Microsoft und ganz vielen Game Studios drin. Einfach nur, weil sie wissen wollten, was die nächsten Spiele sind, die rauskommen. Aber haben sich natürlich dabei unglaublich strafbar gemacht. Aber es ist halt erstaunlich zu sehen, wie weit die es geschafft haben, wirklich da in Microsoft reinzuhacken. Will ich auf jeden Fall mal reinhören. Ich habe irgendwie gefühlt, normalerweise tun wir uns manchmal, also so Last Minute Pick of the Days, habe ich ganz viele auf meiner Liste. Ich nehme mal eins aus meinem letzten Urlaub, da war nämlich die Problematik, irgendwie verlässt man sich ja mittlerweile darauf, dass Weil in Hotels irgendwie funktioniert. In unserem hat es die ersten drei Tage nicht funktioniert. Wir waren in Tunesien und mein Internet und mein Provider, das war ja auch vor Ewigkeit mein Pick of the date, ich habe ja Funk von FreeNet, so jeden Tag zahlst du, kannst jeden Tag kündigen, hast du ein Gigabyte Internet, aber die bieten keine Möglichkeit, dass ich mir irgendwie im Ausland Daten verschaffen kann. Und dann habe ich so ein bisschen gegoogled und dachte dann immer: Es gibt ja mittlerweile eh Simms und so, auch wenn ich irgendwie, wenn ich nutze, die eh Simms, bis dato habe ich es nicht genutzt, kann auch mehrere Simms auf meinem Handy haben. Ich muss da irgendeine App geben, die mir auf eine E-SIM gibt und dann kann ich da rüber surfen. Und es gibt die App, die fand ich jetzt ganz cool Red Bull Mobile Data, also wirklich von Red Bull, die haben irgendwie für ihre ganzen Athlet, die überall auf der Welt unterwegs waren, irgendwann diese App gebaut und haben die dann extern gemacht. Und da kratzt du einfach, lädst du runter, installierst dir eine zweite E-SIM, hast du dann sozusagen zwei Simps auf deinem Handy, kannst du einfach anschalten und kannst dann, hast du dann verschiedene Länder und kannst dir einfach für ein paar Euro Datenpakete kaufen. Das heißt, dann konnte ich mir für Tunesien für drei Euro, weil wir wollten es eigentlich machen für unser Babyfon und meine Frau hat es dann mit O2 gemacht, wo wir dachten, so viel kann die Babyphone App nicht ziehen. Na ja, dann war ihr Limit von 60 Euro, die man mit Roaming machen konnte, sehr schnell voll und dann habe ich mir irgendwie für, dann habe ich die App runtergeladen für vier Euro, mir einen Gigabyte geholt und das hat sehr lange gehalten. Fand ich irgendwie cool. Auf jeden Fall so Red Bull Apps Red Bull Mobile Data, Airbnb Data. Fand ich ganz cool, die App. Guter Hinweis. Sehr gut. Dann Andre, jetzt kann ich aber Danke sagen. Vielen Dank, dass du dir die Zeit genommen hast. Ich wollte schon lange über Remix reden. Wir haben ja immer die Schwierigkeit, deutschsprachige Speaker zu Themen zu finden und ich bin sehr happy, dass wir dich gefunden haben, dass du dir die Zeit dafür genommen hast. Und du hast jetzt zwar nicht darüber geredet, wie wir unsere Bosse überzeugen, Remix zu nutzen, aber vielleicht packen wir deinen Talk – der ist ja mittlerweile auf YouTube zu sehen, den Lightning Talk einfach in die Show-Notes, falls Leute noch mehr Argumente als diese tollen Techniken, die du uns heute gebracht hast, brauchen. Auch vielen, vielen Dank von mir. Hat Spaß gemacht. Sehr, sehr gerne. Hat mich gefreut. Danke schön. Dann an euch da draußen schickt uns wie immer gerne Feedback, Podcasts, Programmier, Punkt Bar oder einfach über unser Formular auf der Homepage. Bis zum nächsten Mal. Ciao. Bis dann, tschüss.