 11.30 Uhr. Wir wollen beginnen. Das ist ja herzlich willkommen zum ersten Talk heute Morgen. Ein Publikum hat sich versammelt, sehr schön. Als ersten Talk haben wir heute Roger und Fait aus der Schweiz, die uns etwas sagen wollen zu Henry Ford und warum er bessere Webapplikationen gebaut hätte. Ja, und dann wünsche ich euch viel Spaß. Und wir machen eine 10 Minuten Q&A am Schluss. Also wenn ihr Fragen habt, können wir dann das behandeln. Viel Spaß. Danke. Ja, Roger. Also, guten Morgen oder guten Vormittag. Schön, dass es einige Leute hat, die Interesse zeigen an unserem Vortag heute. Gestern hatten wir leider ein Junk zu viel oder ein Junk, wie das hier heißt. Und ich hoffe aber, ihr seid fit und munter und könnt uns folgen. Also wir sind aus der Schweiz, das hört man ja, denke ich. Ein bisschen, ja. Was für euch, also wir werden nicht alles über Henry Ford erzählen. Wir werden mehr über Web Components sprechen, Polymer sprechen. Flow based Polymer mit Web Components, oder? Ja, wir beide arbeiten in der Schweiz bei Ad Kubum. Das ist ein Standard Software Hersteller in der Versicherungsbranche. Die sind übrigens auch hier in Deutschland vertretend, in Hamburg, Stuttgart und Düsseldorf. Düsseldorf, ja, genau. Und wir haben dort für unsere Web Applikationen und Mobile Apps ein Konzept entwickelt, wie wir möglichst schnell und einfach solche Web Apps entwickeln können. Und das auf einem deklarativen Weg mit Web Components und Flow based Programmen. Gut, gehen wir zurück zu Henry Ford. Warum Ford so erfolgreich? Ford hat natürlich vieles gemacht, er hat ja nicht nur Autos gebaut, sondern er hat sich überlegt, aus was besteht ein Auto. Er hat sich überlegt, was sind das für Pattern, die da drin verbaut sind, wie kann ich auf einem guten Weg und einfach immer wieder das Gleiche zusammenbauen? Also Prozesse. Prozesse auf die Miung, er hat Module entwickelt, also zum Beispiel die gleichen Bodengruppe für verschiedene Autotypen, Motoren. Das Rad, das hat er einmal entwickelt und dann bei jedem Fahrzeug eingesetzt. Aber viel wichtiger war auch noch die Normierung, das ist so, dass das böse Wort niemand lässt sich gerne in eine Norm bringen, aber das ist eben genau der Punkt, der erfolgreicher Punkt. Seine Motorenaufhängung hatten immer die gleichen Löcher am gleichen Ort und nicht irgendwo verteilt. Ja, und die hatten auch immer wieder die gleichen Schrauben, er hat da nicht einmal gemischt mit Metrisch, imperialen Schrauben, mal größer, mal kleiner, das war ein reduziertes Set an Schrauben. Dann kommt noch die isolierte Entwicklung dazu. Also, wenn er ein Auto zusammenbaut, dann muss er nicht zwingend auch den Motor selbst bauen oder die Schrauben muss auch nichts selbst machen. Die gibt es bereits und dank der Normierung, kann er Standardschrauben verwenden, ist ganz einfach im Zusammenbau. Ja, und die API des Motors war ja allen klar damals oder die haben sie einfach abgemacht, das ist die API des Motors und so konnte er auch die Entwicklung komplett isoliert an einem anderen Ort betreiben und die haben sich wirklich nur auf Motorenentwicklung konzentriert. So konnte ein Motor eingesetzt werden, fabriziert werden, aber unabhängig davon ein neuer Motor entwickelt werden. Genau, und jetzt sollten wir vielleicht wieder ein wenig auf Software zurückkommen. Gut, weil es gibt schon viele Parallelen zu Fahrzeugbau der Autoindustrie und der Softwareindustrie und man kann sich dann fragen, wir haben mehr als 100 Jahre Entwicklungserfahrung in der Automobilindustrie. Und in der Softwareindustrie wird sie häufig leider ignoriert? Ja, die gingen irgendwie vergessen oder es gibt noch andere Gründe, warum das nicht so funktioniert wie in der Autoindustrie und aus diesem Grund haben wir eine Retrospective durchgemacht. Ja, oder eine Analyse, wie man immer sagen will. Wir sind etwa 2.500 Sprints in der Vergangenheit und haben das mal angeschaut. Ja, wie wir sehen, also das Resultat nach Wochenlanger Analyse und Forschung wir sind rausgekommen, dass ein Auto in der Regel ein Resultat, das Resultat der Komponenten und Baugruppen, die bereits existieren sind. Also der Ansatz ist bottom up. Und bei der Software? Ja, bei der Software funktioniert das eben meistens nicht ganz so. Bei der Software werden Applikationen designt gebaut und während der Entwicklung wird meistens festgestellt, ah, das kann ich ja dort auch noch brauchen oder besser gesagt, das habe ich schon fünfmal gebaut in der Applikation. Vielleicht löse ich das in ein Modul raus. Und das ist genau der umgekehrte Ansatz. Anstatt eine Komposition mit Einzelteilen zu erstellen für die Applikation wird meistens in der Software eben eine Applikation gebaut und dann merkt man, ah, das könnte man vielleicht noch brauchen. Ja, die Autoindustrie denkt also schon in Komponenten. Also Fazit ist, die Autoindustrie ist uns weit voraus, kann man so sagen. Das sieht man auch, wenn man jetzt die verschiedenen Modelle anschaut. Zwei neue im Jahr, ja. Zwei neue im Jahr, alles identisch, außer das Häuschen obendrauf und das könnte man ja in der Software genau gleich erledigen. Gut, was können wir tun? Was hilft uns da weiter, haben wir uns gefragt. Ja, Web Components ist ja in aller Munde. Alle machen Web Components. Und Web Components hat natürlich den Vorteil, dass wir genau diese Probleme lösen können und in abstrakter Form diese Komponenten wieder einsetzen und zu Leben erwecken für andere Applikation. Genau, wir bauen ein Inputfeld mit Validierung und Federanzeigen und bauen das zum Beispiel nicht immer wieder. Wir können nicht nur visuelle Komponenten bauen mit Web Components, wir können auch problemlos nicht visuelle Komponenten, irgendwie ein Stellvertreter für einen API, eine Komponente, die mit unserer REST-API quatscht und sich um die ganze Kommunikation kümmert. Ja, da gibt es unendlich viele Möglichkeiten. Zu beachten ist einfach auch wieder hier, das haben wir zu Beginn auch gesagt, das Wort Normierung, das ist ein wichtigen Punkt. Also eine isolierte Entwicklung der Web Components in einer abstrakten Form und nicht in einer expliziten Form, wie sie gerade gebraucht wird, weil dann ist sie wirklich verbaut und sie kann nicht mehr wiederverwendet werden. Das sind so die Keypunkte, die man beachten muss. Für unsere Arbeit haben wir uns schlussendlich für die Polymer Library entschieden. Es gibt noch mehr Libraries durchaus, die den Web Components Sender unterstützen und hilfreich dabei sind. Ja, es gibt ja sowieso ganz viele Libraries für das und die Polymer Library bietet uns halt sehr viele Tools, die dazukommen. Also das ist ein riesiger Werkzeugkasten, den man einfach so mit einer Lib behält. Also es ist nicht nur das Lib.js, in dem Sinne, dass im Browser läuft, da ist die ganze Toolchain, da kommt recht viel sonst noch mit. Angefangen bei Generatoren, um Elemente oder ganze Applikationen direkt aus den Generatoren initial zu erstellen, die auch erweitert werden können um eigene Generatoren. Ja, und dann nicht zu vergessen die ganze Bildchain, die man auch braucht. Also jetzt bei unseren Kunden ist es so, dass wir verschiedene Bills ausliefern für das gleiche Produkt. Also wir haben zum Teil bandelnd anbandelnd, dann haben wir die Minified, das ganze, was man benötigt, ist bereits schon dabei in diesem Kasten drin. Ja, da ist auch noch ein Entwicklungsserver dabei, der Polymer Surf, um lokal zu entwickeln und gleich auch schon seine Sachen anzusehen und zu überprüfen. Kommt auch schon mit über die Polymer CLI Tools. Genau, und dann nicht zu vergessen, also das Testing der Web Components, das ist ja auch ein wichtiger Teil und das ist einfach auch schon dabei. Also Unit-Tests oder Integrations-Tests mit Selenium, alles out of the box. Dann haben ja jetzt ganz viele Web Components und jeder verliert irgendwo den Überblick. Was braucht es dazu? Also ich brauche ein Demosystem dazu, dass ich auch die Components direkt im Demos-Modus anschauen kann und was macht überhaupt? Also das Demosystem, ihr könnt die Komponente ansehen und damit rumspielen und Inputs verändern und seht das an dieser Komponente, wie sich das gleich auswirkt. Dann gibt es noch das Dokumentationssystem. Ja, das ist relativ wichtig, weil ohne die APIs zu kennen oder nachlesen zu können, ist man fast überfordert, ja. Und natürlich nicht zu vergessen, auch die Integration in die Ideas ist auch gegeben. Ja, und momentan sind mehrere Tausend Komponenten schon frei verfügbar im Web. Mehrere Hunde davon sind sinnvoll verwendbar, also nicht alle leider, also man kann sie verändern, aber ja, wie es halt so ist. Manche sind zu groß, manche schießen am Ziel vorbei, ja, gut. Da gibt es aber noch weitere Gründe, oder? Warum wir uns für das entschieden haben und die sehen wir jetzt auch hier, also das ist standardisiert, wir reden hier von einem Web-Standard und nicht von proprietären Systemen. Die Polymer Lib in unserem Fall, die wird idealerweise immer kleiner, eventuell verschwindet sie komplett, weil alles native vorhanden ist, das ist auch einer unserer Vorteile. Ja, die API, nicht zu vergessen, der kompletten Komponent. Und natürlich, das ist ein Steckenpferd von uns, die deklarative Verwendung. Da kommen wir dann, mit dem Flowbase kommen wir auch wieder auf die Deklarationen zurück. Und schön ist auch der isoliertes Kopf von diesen Komponenten. Da gibt es kein CSS hier eingestellt und ändert irgendwas, völlig an einem anderen Ort, in meiner Web-Applikation. Das CSS ist lokal, nur für diese Komponente gültig. Da habt ihr keine Nebenwirkungen. Ihr könnt auch nicht JS-Kreuzung quer durchzünden, das Zeug ist zu ungeschlossen, die Dinge sind gekapselt. Ja, das sind wir als Vorteile, nicht jeder sieht das als Vorteil, wir waren ein List, das war Listesjahr, waren wir in Kopenhagen bei einem Polymer Summit und dort hat es einen Vortrag gegeben von USA Today. Die haben innerhalb von einem Jahr, haben die sämtliche Websites, sämtliche Zeitungen, die sie betreiben online, haben die auf Webkomponente umgestellt. Ihre Haupt- oder Kernaussage war, you are not that special, das hat uns doch recht beeindruckt, was haben die gemeint? Jede dieser Zeitungen, New York Times oder die Zeit zum Beispiel, jeder dachte, sie sind speziell. Aber eigentlich haben alle das gleiche Problem zu lösen, die müssen Nachrichten darstellen. Die unterscheiden für sich vielleicht optisch, aber die Problemstellungen sind dieselben, die sie haben. Sie haben eine Feed, die benötigen Komponenten für das, sie haben Render-Komponenten, die sie benötigen, die unterscheiden sich dann oft, aber das Prinzip dahinter ist immer identisch. Dieser Spruch sagt, das ist die Kernaussage, das sehen wir auch bei uns in der Unternehmung. Jeder Protoktor ohne hat das Gefühl, bei uns funktioniert das etwas anders. Das ist viel komplizierter. Ihr macht hier einfache Geschichten, aber bei uns sind die Us-Cases extrem kompliziert. Wenn man die auseinander nimmt und wirklich modularisiert, dann merkt man, die Probleme sind immer dieselben. Und dort kommen die Webkomponenten ins Spiel. Genau. Ja, wahrscheinlich. Jetzt ist es genug Philosophie und bla, bla von uns, genug Konzepte. Wollen wir ... Wir gehen an's Eingemacht. Ja, dann zeigen wir mal was. Wir haben einen kleinen Showcase vorbereitet. Ja, das ist er. Seht ihr das? Ja. Seht man hier was? Ja, das sieht man nicht gut. Also, doch den Button seht ihr, oder? Gut. Wenn sie leuchtet auch. Gut. Rouscher, erklär mal das Beispiel. Ja, das ist ein triviales Beispiel, wenn man das so anschaut. Also, wir haben eine Komponente. Und das ist unsere Lampe. Einfach eine ganz normale Lampe. Das könnte aber auch eine ... Da könnte es verschiedene Varianten geben von diesen Lampen. Die könnte auch eingekauft sein, diese Komponente. Sie könnte auch stillvertretend sein für eine echte Lampe. Das wäre auch möglich. Und dann haben wir noch einen Schalter. Haben wir hier einfach einen Button verwendet. Den hier? Ja, genau. So einfach wie das Beispiel ist, wir haben einen Click-Händler auf dem Button. Und wir möchten gerne, dass die Lampe leuchtet. Also, hier ist der Click-Händler. Und hier ist die Methode. Ja, genau, die ist darauf reagiert. Was passiert hier? Es geht in diesem ... Dies ist der Host. Die aktuelle Komponente. Mit Dollar, das Element mit die Lampe 1. Dort ruft er die Methode Toggle auf. Also, die Lampe hat eine Toggle-Methode. Um sie ein- und auszuschalten. Das sind wir hier. Und sie lässt sich ein- und ausschalten. Was mir jetzt noch fehlt an diesem Beispiel, der Raum ist groß, die Lampe ist klein. Ich habe einfach zu wenig Licht. Ich hätte gerne mehrere Lampen. Gut, dann mache ich dir eine zweite Lampe. Lampe 2. Die ist da. Ich soll sie auch ein- und ausschalten. Dann ist das etwa dein Wunsch. Das schaut schon mal sehr gut aus. Wir symbolisieren hier ein Software-Entwicklungsprozess. Man sagt, man macht mal das. Und dann die permanenten Änderungen, die kommen. Das kennt ihr wahrscheinlich alle, diese Situation. Gut, hier hast du den Schalter. Was jetzt noch schön wäre an dieser Geschichte. Ich laufe jeden Morgen. Ich habe den Schalter im Dunkeln durch den kompletten Raum. Der Schalter ist dort hinten. Ich hätte gerne einen weiteren Schalter. Hier vorne ist okay. Dann bauen wir das mal dort rein. Dann hier. Einfach eine Geschichte. Ich bin etwas mühsam. Das gefällt mir immer noch nicht. Entweder habe ich jetzt sehr viel Licht oder kein Licht. Ja, das wolltest du ja. Ja, aber ich würde gerne den Vorderbereich ausleuchten oder den Hinterbereich ausleuchten. Und dann vielleicht noch alles miteinander. Gut. Das lässt sich schon machen. Dann machen wir hier eine Gruppe A. Gruppe B. Wunderbar. Da geht jetzt also eine Lampe verloren und sie ist nicht mehr da. Diese Lampe 1 gefällt mir nicht. Dann löst du einfach die Lampe aus. Gut, jetzt hast du ... Das sieht man jetzt. Wir haben im UI verdrahtet über den Event-Händler. Wir haben jetzt verschiedene Event-Händler. Die referenzieren halt auch eine ID von der Lampe. Und das passiert dann relativ schnell. Dass eine ID nicht mehr verfügbar ist oder die Komponente nicht mehr verfügbar ist. Und dann gibt es einen Fehler. Und das kann ja bei diesem Use-Case das wirklich überschaubar. Aber man kann sich ja vorstellen, dass dieser Use-Case enorm ist. Etwas größer, ja. Ja, und dann wird das ziemlich schnell zu einer mühseligen Geschichte. Ja, wie soll ich das jetzt reparieren? Ja, wir könnten vielleicht das nicht über diesen Händler lösen. Wir sind hier klassisch unterwegs mit Event-Händlern. Aha, ja. Wir wollen ja auch über Flow-Based ... Wir wollen ja über Flow-Based entwickeln. Genau. Dann setzen wir mal zurück. Man sieht jetzt hier, in diesem klassischen Weg, dass es sehr schnell mühsam wird, weil es explizit entwickelt wurde. Das funktioniert einwandfrei in allen Use-Cases, wenn die ziemlich statisch sind. Wenn die Anforderungen völlig klar sind, keine Veränderungen passieren, dann kann man das so durchaus erledigen. Bei uns sind aber die Anforderungen immer sehr wage. Sie ändern sich, werden im Projekt. Dort wollten wir mit Flow-Based einen anderen Ansatz fahren. Ja, bevor wir ... Was machst du da? Hast du die Folien ausgelöscht? Nein. Ah, da ist eine verschoben. Super. Draußen ist das schönes Wetter. Das ist ein einfacher Use-Case. Aber wir haben uns gedacht, wir brauchen noch einen Theorie-Block. Die gefüllte 15-Stunden-Knachentrachene-Theorie. Das werden wir jetzt kurz durchführen. Und dann starten wir wirklich in die Flow-Based-Geschichte rein. Gut, das können wir dann so machen. Flow-Based Polymer, zum Erwähnen, ist ein hybrides Flow-Based-System. Einige können vielleicht No-Flow-JS oder anderen Flow-Based-Systemen. Niemand. Flow-Based Polymer ist auch bei Weitem nicht das Erste solcher System, das Flow-Based arbeitet. Quartz-Composer, das kennt ihr sicher, die mit Max Bildschirm schon erbauen. Oder die Unreal Engine, dieser Game Engine, die wird auch Flow-Based programmiert. Dann gibt es auch noch Dataflow, ein System um Messinstrumenten zu bauen. Das wird auch im meteorologischen Institut in Davos eingesetzt. Ja, aber jetzt zu Theoretos. Genau. Hier sehen wir als Kitze eine Komponente A und eine Komponente B. In der Komponente A wird ein Event gefeuert. Und die Funktion, die aufgerufen wird in Komponente B, möchten wir verbinden. Wir nehmen dazu einen Eventwire und ziehen den einfach von A nach B. Genau. Ein Event, der gefeuert wird, sendet ja in der Regel Daten mit. Eigentlich den Event selbst. Und dort gibt es Details oder Paf usw. Den weiern wir rüber auf die Funktion von Element B und übergeben dort das Event Details als Argument. Damit wir das jetzt an unseren Lampen-Newscase noch etwas näher anbringen, kommen wir noch zu der Theorie-Lektion 101b. Gut. Hier haben wir unseren Paper-Button, ganz links, mit dem Click-Event. Und wir haben rechts die Lampe mit der Toggle-Funktion. Und damit wir nicht diese Eventhändler da und schreiben müssen, sagen wir einfach, Add-Click, Wire, Function, Toggle. Ja. Also das ist alles, was es hier gibt, eigentlich ein Add-Event über den Wire auf F-Methode. Ja. Das schauen wir uns jetzt an, oder? Ja, das war es schon. Das ist eigentlich eine einfache Geschichte. Wieder eine Idee? Ja, genau. Gut. Wir setzen beim gleichen News-Case auf, damit man wirklich den Unterschied so verzieht. Also wir haben hier jetzt wieder unsere Komponente. Das ist die selbe Komponente. Wir haben nichts verändert. Moment. Ja, ich muss hier noch in dem Browser noch messen. Ja, genau. Nichts verändert? Nichts verändert. Wir haben immer noch diese Lampe mit der Funktion, die ersichtlich ist. Und wir haben den Button mit dem Event clicked. Und diesen Event-Wire, den wir hier Button clicked genannt haben, den ziehen wir einfach bei beiden rein. Also so wie ein Kabel vom Paper-Button zu die Lampe. Und da kann man jetzt unendlich viele Lampen reinmachen. Ja. Also noch kurz eine visuelle Repräsentation vom selben Element an. Add click, Wire, dieser Wire heißt, Button clicked, F, Toggle von der Lampe. Gut. Was war das Erste, was du wolltest, eine zweite Lampe? Ja, dann sehen wir mal, wie das Flow-Based funktioniert. Wir haben hier diese zweite Lampe. Ja, sie schaltet. Was ist passiert, oder was haben wir gebaut? Ja, wir haben den selben Wire hier und hier auf diese Methoden. Vielleicht noch einmal im Source. Gesundheit. Hier add button clicked und dieser Wire verbindet hier nach F-Toggle von Lampe 1 und Lampe 2. Was vielleicht auffällt? Die Lampen brauchen keine IDs mehr. Das würde dann auch wieder heißen, dass wenn wir eine Lampe rauslöschen, überhaupt nichts passiert. Ja, wir müssen die gleichen Situation nachstellen. Also, was war das andere noch? Ein zweiter... Ja, dann hätten wir noch einen zweiten Schalter. Falsch. Was haben wir verdrahtet, wenn wir das anschauen? Okay, gut, nicht so eine schöne Schaltung, aber sie funktioniert. Also optisch nicht schön, aber sie funktioniert. Dann, was war das andere? Ja, dann könnten wir das noch unterschiedlich zusammenstellen. Der Schalter. Aber wir wollten noch hier noch was weglöschen, oder? Ah, separate Schalten war noch, Roger. Separate Schalten, ja. Machen wir hier die Gruppe A, Gruppe A, Gruppe B, Gruppe B. Ja, die lassen sich schalten, wenn wir das mal ansehen. Ja, sieht das wunderbar anständig aus. Und dann haben wir hier die Lampe weglöscht. Gut, hier passiert nichts, auch kein Fehler. Und die Lampe schaltet. Und im Diagramm, ja, wir haben einen wachen Button. Einen leeren Button, ja. Diese Art von Eventwire, die kann man auch bei jeder Komponente, die wird Komponen, kann man das auch einsetzen. Man kann die auch auf die nativen Elemente anwenden. Das funktioniert natürlich auch. Man hat ja vielleicht auch eingekaufte Komponenten, die man verwendet und in diesem Stil auch verbinden möchte. Was baust du noch zu sagen? Ja, du hast was von eingekauften Komponenten gesprochen. Moment, will dir nur eine Komponente kaufen. Ja, ich habe da eine Komponente Color Pad gekauft. Ah, jetzt können wir die Lampe Farbe vorstellen. Ja, das sollten wir jetzt können. Mach mal das schlecht. Ja, wir können die ändern. Mach nicht auch das schlecht. Ja, wie sieht das aus? Willst du Color Pad mal ansehen? Also, wie wir sie verwendet haben. Also, Color Pad, fixfertige Komponente. Dort kann man eine Farbe auswählen. Vielmehr kann das Ding nicht. Und es wirft ein Event New Color hier. Und ja, diese Farbe, also diesen Event, vielleicht besser hier. Ah, ja, hier. Hier hat New Color und dann können wir hier bei der Lampe die New Color Method aufrufen und da setzt die Farbe der Lampe. Ja. Und also, der Event wird natürlich bei jedem Chains gefeuert und dann fährt das rechtzügig mit. Und man sieht jetzt bei diesem einfachen Beispiel, sieht man ja sofort, dass das das System sehr flexibel ist. Das heißt, auf Veränderungen kann ich sehr gut reagieren, ohne dass ich irgendwo in der JavaScript-Hölle irgendwelche Funktionen ändern muss. Das fällt alles weg. Es ist wirklich, je nach Komponente, die man einsetzt, also es gibt ja auch viele Komponente, die vielleicht nur ein Mapping durchführen. Also, ich habe ja einen Event. In einem Event Detail kommt ein Objekt daher. Das gefällt mir aber nicht in dieser Struktur. Dann nehme ich das, in eine Mapper-Komponente, die baut mir das Zielobjekt und nehme den Draht hinten wieder raus und in meine Komponente, die das benötigt. Genau. So lassen sich Kompositionen erstellen, je nach Use Case, mit Basis-Elementen, die man entwickelt hat. Das ist natürlich schon vielleicht noch der Punkt, den man sagen sollte. Diese Basis-Komponente müssen natürlich existieren. Ja, die müssen existieren. Das wäre von Vorteil. Ja, gut. Ja, die müssen existieren. Was auch noch schön wäre, das könnte man jetzt einfach auch noch einbauen, meine Kinder zu Hause mit diesem Lichtschalter, die hemmen da und da auf rum und eigentlich möchte ich nur, dass die Lampe einmal einschaltet und nicht immer on-off. Dieses Spiel ist dann schnell langweilig, wenn man die Bouncer dazwischen ist. Das könnte man einfach jetzt in diesem Flow, den wir hier zusammengebaut haben, dazwischen setzen und ohne, dass man sich überlegen muss, wie läuft das ab im Code, sondern einfach die Wires nehmen in eine weitere Komponente rein, zum Beispiel eine Bouncer und das Resultat kommt dann wieder zur Lampe zurück. Ja, das ist so ein Ding. Ja, ich habe sie. Danke, das hat mir vorhin nicht so abgesprochen, aber ich importiere die Bounce Komponente. Jetzt die API dort nicht gerade, direkt zur Verfügung. Na, Puls und Trigret. Was wolltest du genau? Die Bounce. Die Bounce. Ah, ich bin mal ein Beispiel. Gut, okay, gut. Entschuldigung, nehmen wir hier die Bounce. Du kannst das auch einfach mal so, wie würde ich das verwenden, zu sehen, oder? Das müsste man hier nicht laufen lassen. Den hast du in einem anderen Fall gemacht. Den habe ich hier gemacht. Danke. Gut. Hast du es gemerkt? Ja, der hat jetzt den Standort wert, oder? Ja. Also, dann müssen wir mal diese Dauer, dieses Property. 250 Millisekunden ist der Default. Wie lange haben wir deinen Kinder auf dem Schaden gefunden? Keine Ahnung. Weil, ich habe jetzt was umgekehrt, das Gebäude ich drücke, und es ist also nach einer Sekunde ein, das ist nicht ganz das, was du wolltest, oder? Aber es veranschaut jetzt das Problem. Ja, aber wir können das schon setzen. Ah, seht ihr, ich ... Also, macht schon nicht mehr so viel Spaß, oder? Nein, das macht so viel Spaß. Ja, gut. Könnte genauso gut ein Bewegungsmelder sein, oder? Könnte es auch sein. Ja, könnte man machen so. Ja, jetzt wollen wir noch schauen, was FlowBase sonst noch so bietet, oder? Gut. Also, das wäre jetzt auch ein wichtiger Punkt. Ja. Aha, aber was FlowBase, was wir jetzt gesehen haben, ist so der Standardpfall. Wir haben Events, wir haben Funktionen, die kann man so miteinander verbinden. Das ist eigentlich der AT-Event und das F für die Funktion. Und da kann man natürlich auch mehrere solche Weges verwenden, oder? Da kommt man schon recht weit mit diesem AT irgendwas, F irgendwas, und dann noch die property bindings von Polymer, um Werte, die irgendwo gesetzt werden, eine andere Komponente reinzuschreiben, kommt man eigentlich recht weit. Gut, aber, was gibt es noch? Ja. Wir haben immer gesehen, vorhin in unserem Beispiel, AT-Click, ein Wire, aber, ein Wire, aber man kann beliebig viele Wires setzen. Man kann beliebig viele Verbindungen aus einem AT irgendwas ziehen. Also das macht dann Sinn, wenn man diesen Flow aufteilen möchte, von der gleichen Quelle aus eine Abzweigung zum Beispiel. Genau. Dann kann man das ganz einfach so in Chroma Separated eingeben, diese Wires. Ja. Dann können wir doch beliebig viele Wires in ein F leiten. Das F ist nicht ein normales F, noch zur Info. Das ist Functional F bei Option F auf der Mac und auf Windows, ist das? Keine Ahnung. Ich weiß auch nicht. Man kann mehrere von diesen Wires in ein F leiten. Das heißt, es können zwei Pfaden daherkommen und die sollen dasselbe auslösen. Ja. Das ist ... Ja, das hast du oft. Wenn du verschiedene Wege zum Ziel hast, verschiedene Möglichkeiten wie der Benutzer, zum Beispiel, über das UI zu einem Punkt kommt, dann macht das durchaus Sinn, dass man zum Beispiel mehrere Wires in Funktionen löst. Ja, das kann eine Speichermethode sein von einer AP-Komponente, die auf einen Button reagiert oder sonst nach einer gewissen Zeit sowieso ein Autosafe macht. Ja. Mit Senden von Daten. Wir können aus dem Host, das sind die Polymer Host Properties, ja, genau. Wir können auch sagen, wir wollen nicht beim Click, das Detail vom Click, das gibt eine 1 oder 2, 3, 4, also 2 für Doppel-Click, 3 für den Triple-Click und so weiter. Diese Information ist nicht immer sinnvoll. Aber wir haben ein Property, eine Variable, und dort drinnen haben wir die Daten, die wir mit schicken wollen. Dann kann man einfach den Wire mit einem Klammer auf Property angeben und dann wird das Property, das Host Property, welches angegeben wurde, mit in die Ziele gesendet. Gut. Kann ich dann auch Daten in Properties umleiten? Ja, das können wir auch. Also aus einem, aus einem Ereignis, das Event Detail, direkt in eine Property umleiten. Anstatt das über ein Händler zu schicken, ins JS runter und dort dann diese Property zu setzen, können wir das direkt reinschreiben. Ja. Das macht meistens dann Sinn, wenn man zum Beispiel Komponenten hat, die Properties benötigen, weil sie so implementiert wurden. Wir haben darauf, dass wir unsere Webkomponent mit Properties und Funktionen bestücken, für dasselbe. Somit sind wir im Flow-Based leichter unterwegs. Wir brauchen nicht, im Host property zu setzen, die dann wieder mit dem Binding verbunden werden, sondern wir können das dann direkt über die Funktion erledigen. Aber bei Fremden oder third-party Komponenten ist das nicht immer der Fall und diese Möglichkeit bietet eben das, was man dann machen kann. Ja. Das kann man auch nutzen. Also dieser Ajax-Request schickt uns Daten und die wollen wir vielleicht im HTML verwenden. Dann ist das ägige Klammer Search Results Punkt 0, Punkt Title. Dann steht das auch im HTML drin. Jetzt enden wir immer spezielle Events. Wir können auch den Native und den Raw Event senden. Ja. Das gibt es natürlich auch. Was unsere Vios immer machen, die nehmen Event Detail. Das ist einfach so bei Konventionen, weil die meisten Events, was sinnvolles schicken, schicken das im Detail. Es ist nicht standardisiert, aber ich sehe das quer durch. Ja. Aber wir können auch den ganzen Event senden und dann kommen zu den kompletten Event. Dann wäre es noch schön, wenn ich einen Stern mit einem Deep Property noch angeben kann. Das kommt bald. Ja. Willst du vielleicht auch sagen, wozu du das verwenden willst, diesen ganzen Event? Ja, das gibt es verschiedene Möglichkeiten. Zum Teil, wenn ich einen Prevent von diesem Event haben möchte, dann baue ich nicht das Event Detail, das ist natürlich den echten Event. Da könnte man das machen. Oder das Zielding, will den Domknoten haben und mit dem irgendwas machen. Dann macht es durchaus Sinn. Ja. Was haben wir noch? Ja, wir können Methoden, also nicht jede Komponente, die wir einsetzen, kommt ja von uns und bauen wir selber, die nutzen wir einfach. Manchmal verlangen die bei Methodenaufrufen mehrere Argumente. Das gibt es so Funktionen, die mehrere Argumente verlangen. Hier haben wir ein Multiplizierer, der hat die Kalkulettmethode und der erwartet zwei Werte. Dann müssen wir nur ein Array schicken, ja. Also ein Spread Operator. Ja, es wird aber überprüft, ob das Ziel-Element, also die Zielmethode auch diese mehrfach Argumente haben will. Sonst wird der Array geschickt, gesendet. Dann haben wir auch noch Return Werte von Funktionen, oder? Ja, genau. Wie wir hier sehen, wenn wir die Methode Kalkulett aufrufen mit den Daten, ja, dieses Multiplizierer, der macht Return und return das Resultat mit f und diese Funktionen, die du aufrufen hast, bekommst du den Wire mit der Antwort. Da kannst du natürlich das wieder in mehrere Orte reinschreiben. Also der Workaround wäre dann, dass die Kalkulettfunktion, zum Beispiel einen Event feuern würde. Und da beinhaltet. Das wäre ja auch eine Variante. Das ist aber so einfach, weil das macht nicht wirklich Sinn in vielen Fällen. Und so kann man den Return Werte direkt wieder auf einen Wire geben. Genau. Und Events feuern können wir natürlich auch. Ja, genau. Events feuern, wann machen die Sinn? Man könnte ja weiter oben einfach auf AdResponse hören, aber das ist einfach Response. Und man will eigentlich genau einen bestimmten, der der die Userdaten empfangen hat, dann kann man einfach den Event umleiten und umbenennen. Also es werden mit diesem Dach hier, der Bubble nicht, wird das, was hier von diesem Event kam und Response ist, heißt danach einfach Userdata received. Und im Event Detail ist dann die Response drin. Dann wird da was hier rausgekommen ist. Mit Dachdach können wir diesen Event auch bubblen. Man muss nicht immer bubblen. Event Bubbling im Browser, muss man das erklären. Das geht einfach so rauf, bis er beim Window-Dokument auftrifft, ja, aufschlägt. Das unterste haben wir bereits schon gesehen. Das haben wir gesehen. Das ist ein sehr explizit Wert mit schicken. Gut, wir hatten das anfangs auch nicht alles mit FlowBase geschrieben. Wir können auch sanft migrieren, Anführungs- Schlusszeichen und Teile der Applikation FlowBase machen, weil das Ganze ist ein hybrides Teil. Und man kann dann von JS aus mit FPP Trigger Wire einfach ein Wire Trigger mit den Daten, die man senden will. Das ist hier, wenn das Dokument, das Element bereit ist, oder hier, wenn es fokussiert wurde. Dann haben wir hier ein Wire fokussiert. Somit kann man später wieder mit dem Wire arbeiten und vielleicht die Komponenten, die jetzt noch nicht FlowBased verbunden sind, so nah das nah ersetzen. Genau, eins nach dem anderen. Dann gibt es auch den umgekehrten Wert weg. Wir können uns aus QuailCode an ein Wire anhängen und dort einfach eine CrawlBack-Methode hinterlegen. Wir verwenden das für die Unit Tests. Also wir können explizit uns hier auf diesen Wire einklicken und bekommen damit, dass er gezündet hat und bekommen seine Informationen. Auch das Trigger Wire verwenden wir für die Tests. Also wir zünden einen Rad und wir hören einen Rad ab. Das sind so die Grundfunktionen, die wir jetzt gesehen haben, von FlowBased Polymer. Jetzt gibt es aber noch andere positive Nebenwirkungen, die einfach so mitkommen. Ja. Zum Beispiel, wenn man im Web unterwegs ist mit Asynchronen, Request und so weiter, gibt es ja immer Probleme vom Timing. Also man muss das Timing handeln. Entweder haben wir Crawlbacks oder wir arbeiten mit Promises oder wir arbeiten FlowBased. Und es ist alles weg. Ja, wir kümmern uns nicht um Ryan-Folge und so Sachen. Es passiert einfach dieser Event. Das geht dorthin und dann schauen wir dieses Speck ran. Wir versuchen gar nicht, erst eine Ryan-Folge zu kontrollieren. Vielleicht zeigen wir hier einen... Dazu könnten wir noch einen komplexen Use-Quest zeigen. Hier geht es darum, dass man mehrere Request hat und aufgrund der Responses weiter Request auslösen muss, also über Konditionen. Und das wäre jetzt ohne diese Komponenten schon nicht ein Wahnsinnsaufwand, aber es bräuchte ein wenig Korot, um das umzusetzen. Jetzt musst du mir helfen. Welchen Use-Quest wolltest du zeigen? Jetzt musst du mal da in diese... Genau. Und dann hätten wir die ViewPersonen-Contact. Edit. Contact. Edit. Ja, hier haben wir reingehen. Also man sieht auch in diesem Repräsentation der Wires, kann man in den Komponenten tief hineintauchen, wirklich von Host zu Host springen. Und man sieht dann die unterliegende Schicht. Und dann war das dieses... Ja, ja. Genau, und hier hat es noch eine Form drin, mit der... Nicht definierten Komponenten. Da hast du den Import vergessen. Ja, da sieht man auch in diesem Tool. Da wurde etwas gefuselt und daher hat das dort noch probiert, und das wollen wir jetzt nicht eingehen. Wir wollen hier mal schauen, wie das da herkommt. Wir haben hier einen Request auf das API und wir holen Änderungen, pendente Änderungen, so Transaktionen. Allo Collection ist ein Repräsentant für eine Rest-Collection. Für eine Rest-API, die eine Collection beinhaltet. Oder? Genau. Und dann... Und dann kriegt sie auch eine Response und ein Model, das aufgrund der Spekt definiert wurde. Und hier bei diesem blauen Wire sehen wir jetzt bei der Response, geht es in eine Komponente. Die ist ziemlich abstrakt. Das ist einfach ein Conditional Event. Auf diesem Conditional Event kann man zum Zeitpunkt, wenn die Daten wirklich geladen sind, eigentlich auch wieder diese Asynchronität, die hier weg radiert wurde, kann man jetzt einen Check machen, zum Beispiel, hat es überhaupt Daten drin oder hat es keine Daten drin und dementsprechend über die Wires wieder reagieren. In diesem Fall reagieren wir so, dass zum Beispiel, wenn die Collection leer ist, erstellen wir eine neue Transaktion und laden, wenn diese Transaktion erstellt ist, unsere Änderungsmodelle mit den Formularwerten und so weiter, die vom Server her kommen. Falls ihr aber gefüllt ist, gehen wir an einen anderen Weg. Also, du erstellst hier ein Modell und wenn es erstellt ist, speicherst du das gleich wieder? Ja, weil das brauchen wir. Und die Haters Informationen liefern uns dann die Super-Sourcen, die wieder besagen, hey, in dieser Transaktion kannst du die Telefonnummer ändern, die E-Mail-Adressen ändern und mit Vorgaben, mit Definitionen und so weiter. Das ist weniger interessant, aber man sieht, man kann komplexere Abläufe sehr einfach zusammenstecken. Gut. Fünf Minuten. Das ist ein weiter Punkt. Also, wir haben jetzt vier gesprochen über Veränderungen. Im klassischen Sinne bedingt das immer mit einer guten Idee, kann man suchen, ersetzen machen, brauchen wir hier nicht, neue Funktionen einpflegen. Man sieht ja auch, bei diesem Tool, die Wires, man kann die Komponente wie abziehen und man würde dann die Drähte sehen und dort kann man die Neue hinsetzen. Und somit, also ein kleines Beispiel, wir haben in unserer Web-Applikation wurde ein Logger, ein Use-Case-Logger wurde als Anforderung geschickt. Ein Performance-Logging wurde verlangt. Und sie wollten aber nicht nur die Request-Loggen, sondern sie wollten wirklich Use-Case-Loggen. Also, ich starte jetzt mit einer Aktion und irgendwo hört diese Aktion auf. Sie kann aber an fünf verschiedenen Orten aufhören. Sie kann mit einem Okre aufhören, sie kann abgebrochen werden, sie kann nicht durchgeführt werden und so weiter. Und das haben ihr Flow-Based nur noch schön reingepackt, mit den Träten verbunden, damit es keine Zeilen schon ausgibt oder benötigt für diese Endung. Und die hat aber die ganze Applikation betroffen. Querdurch ohne Nebenwirkung, ja. Migration haben wir schon angedrückt. Das kann man Schritt für Schritt machen. Das heisst nicht, dass wenn ich eine klassisch entwickelte Applikation habe, dass ich dann das komplette umstellen muss. Das kann ich wirklich so durchgehen. Genau. Es ist ja nicht immer alles gut. Es hat auch Stolpersteine, über die man stolpern kann. Was sind die größten Probleme, die wir hatten? Ein Problem ist, wenn man diese Problemfälle nicht isoliert betrachtet. Wenn man tendiert dazu, das ganze direkt dort vor Ort eben host zu lösen, anstatt mal den Problemfall rauszunehmen und in eine eigene Komponente zu extrahieren, und dort isoliert zu betrachten. Wie kann ich dieses Problem komplett isoliert lösen, unabhängig von meiner gesamten Applikation? Da fällt man immer wieder, denkt man, man nimmt sich diese Abkürzung und lässt das ganz mal weg. Das ist sicher einer der größten Fehler, die passieren, wenn man keine klaren Patterns hat. Also die Pattern sind nicht bekannt und sie werden einfach so entwickelt, mehr per Zufall. Dann ist es schwierig, diese Normierung bei den Komponenten zu erreichen, weil sie sie einfach nicht gibt. Da wir mehr Entwicklungsteams haben, die damit arbeiten, die Mangelabstimmung ist eines unserer Probleme. Es werden gleiche Komponenten oder fast identische Komponenten mehrfach gebaut. Wir erstellen jetzt ein zentrales Dokumentationssystem, ein zentralen Katalog, bei dem jeder reinsehen kann und nachschauen kann, was es eigentlich schon an Komponenten gibt, welche Probleme wurden bereits gelöst und nicht nachher zu identische Komponenten baut, die sich vielleicht nur in der variablen Bezeichnung eine Unterscheidung. Ein weiter Punkt ist auch noch die mangelnde Verantwortung für Komponenten. Also wir haben festgestellt, dass wirklich ein, wenn du einen fixen Maintainer hast, eine verantwortliche Person, der auch die Komponente als ein Baby sieht, der schaut zu der Komponente, dann ist die Qualität massiv besser, als wenn sie einfach in einem Repo ist und die Komponente sieht und darf mal ein wenig ändern daran. Es ist was anderes, wenn ich sagen kann, deine Datenkomponente liefert falsche Resultate, als irgendjemand sollte diese Datenkomponente reparieren. Genau, ja. Ja, was war noch? Ja, fehlende Basiskomponenten. Da es ja ein Komponentenbasierter Ansatz ist und wir von unten nach oben gehen müssen, ist es natürlich schwierig, am Anfang war das sehr schwierig, als wir noch viel zu wenig Komponenten hatten. Ja, haben wir einfach nur noch Platzhalter, haben wir schnell Platzhalterkomponenten gebaut, die die API dokumentiert hatte, aber noch keine Implementierung hatte. Das war noch ein bisschen schwierig, anfangs, mangelnde Basiskomponenten. Ein Punkt noch zum Schluss, was auch immer wieder passiert, ist der imperative Modus, in dem Feld man oft wieder rein. Wenn man deklarativ unterwegs ist, dann ist das Problem in etwa 180° verschoben. Ich habe keine direkten Verbindungen, sondern ich warte auf einem Event, dann mache ich etwas und nicht. Die fixe Verbindung, wie soll ich das sagen? Ja, das imperative, ich klicke den Button und ich. Mach das, rufe, explizit das auch. Sondern im Flow-Base ist es so, hey, der Button wurde geklickt, hat jemand Interesse an und dann kannst du dort barzipieren. Ansonsten wäre es halt, und das passiert schon noch oft, dass man dann wirklich wieder imperativ unterwegs ist, hey, dieser Klick muss das machen. Und das ist ein großes Problem. Ein weiteres Problem, so schlimm ist es nicht, man bekommt es in den Griff, ist das mit den Versionen. Jede Komponente fährt eigene Versionen. Sehen wir, eigene Releasezyklus. Und jetzt gibt es Querabhängigkeiten. Wenn Komponente A, Teilkomponente X verwendet und Komponente B, X in einer anderen Version verwendet, dann haben wir ein Problem. Weil dann können wir nicht A und B verwenden, sondern müssen entweder A oder B diesen Versionskonflikt auflösen. Aber das meldet uns Bauer, wir sehen das auch. Da gibt es aber einen Trick, der hat auch noch ein wenig Tücken, dass man ein Monorepo fährt für harmonisch zusammengehörende Komponenten. Und die Entwickler draußen dann wirklich nur noch die Version des Monorepos verwenden und sicherstellen. Damit alles auch funktioniert in der Version. Ja, sind wir am Ende. Besten Dank für die Aufmerksamkeit. Tom. Vielen Dank, uns beiden. Gibt es denn Fragen aus dem Publikum? Ja. Vielen Dank. Ich habe noch eine Chance. Der grafische Editor, den ihr benutzt habt, gehört jetzt zu dem IntelliJ WebStorm? Nein, du meinst das Furo-Ding hier? Den habe ich nur experimentell mal gebaut, um das Zeug anzusehen. Ist Pri Alpha, ist aber auch in Flow-Based geschrieben als Elektron. Es funktioniert noch nicht. Ich weiß, wo klicken. Darum kann ich den noch nicht rausgeben. Ich will den noch nicht rausgeben, weil ich habe dann zu viele Issus, die mir sowieso schon bekannt sind. Aber der sollte dann auch über kurz oder lang frei verfügbar sein. Das Ziel ist natürlich später mit dem Ding, hier das Teil Ad-Model zu nehmen, den Draht einfach zu ziehen und hier auf eine Methode zu legen. Das ist schon das Ziel. Aber wir verwenden es eigentlich nur für die Visualisierung. Man kann ja das, das Beispiel von Roche im Source, es ist ja nicht groß, aber es ist schwieriger, die Wires nachzuverfolgen. Im Moment nur für Visualisierung und irgendwann auch Open. Noch jemand? Was ist mit Becken? Wir haben viel über Frontend geredet, und was ist mit Becken? Wir haben uns hier nur auf Frontend konzentriert. Für Becken-Systeme gibt es zu genügend Flow-Based-Systeme oder andere Maschinerie. Also es gibt No-Flow-JS. Das ist die Antwort, die du wolltest, oder wie gehen wir mit Becken-Systemen um? Nein, nein, nein, gar nicht. Du kannst mit Iron Age-Ex, also das ist ein X-Hair-Request, arbeiten und mit deinem Becken arbeiten. Das spielt gar keine Rolle. Unsere Becken haben wir recht standardisiert. Unsere Restapien sehen immer fast identisch aus. Sie verhalten sich gleich, nur der Informationsgehalt ist immer der andere, und der Endpunkt ist der andere. Darum konnten wir recht problemlos diese Allo-Entity um eine Entität von einer Person zum Beispiel zu holen. Das könnte genauso gut die Entität eines Autos sein. Man sieht, dass man das safe aus und das Ding kümmert sich um diese Interaktion mit dem Server. Wenn der Server sagt, hey, ich akzeptiere das nicht aus einem fachlichen Grund, dann schießt auch Allo-Entity für uns ein Fehlerevent, den wir auch nutzen können, oder markiert die Felder im Modell, das wir dann schon in der UI so sehen. Person eins kann nicht über einen Betrag von 50.000 Franken verfügen. Irgendwas solches, das steht dann dort. Wir verwenden hier den Contract First Ansatz für sämtliche Ressourcen. Der Server hat die gleiche Spezifikation, wie auch im Klein verfügbar ist. Daher können wir auch dieses Modell so erstellen, wie es auch der Server erstellt. Wir haben das mal in Polymer gebaut, aber wir können mit anderen Web-Components auch umgehen. Das, was Polymer reinziehen kann, können wir auch nutzen. Vielleicht später könnten wir das Ding komplett losgelöst von Polymer rausgeben, dass das mit jedem Web-Component funktionieren kann. Aber im Moment haben wir das mit Polymer gelöst. Okay, ein Letzter. In dem Beispiel wirkflos habe ich immer nur vorwärtsgerichtete Wires gesehen. Was ist mit Fehlerbehandlung? Sind die dann rückwärtsgerichtet? Nein, die kommen von hier wieder rein, das ist ein Fehlerbehandlung. Da ist kein Fehlerhandling drin momentan. Die Wires wären in die identische Richtung. Das wäre, wenn man hier vorne schaut, die Response, da hätten wir auch einen Error, einen Fail und so weiter, den man verweihren kann. Der würde dann z.B. in eine Komponente gezogen, die das Fehlerhandling erledigt. Ja, das fährt die gleichen Wege. Ein Teil hier bei Aluant, die beispielsweise, wenn hier Safe ein Fehler hätte, hat man erstens diesen Event, den kann man raufschicken für irgendwas Fehlermasken, und sonst im Model auffällt eine Fehler-Kennzeichnung, wenn der Server was sagt. Okay, dann breche ich das ungern ab, aber in der nächsten Wart schon. Vielen Dank an Roger und Pfeidt für den tollen Vortrag, und ich lade euch jetzt gleich noch zu den Lightning Talks hier im Raum. Viel Spaß. Danke.