Impressionen aus der Praxis: Funktionale Ansätze in JavaScript

Das The­ma “Funk­tionale Pro­gram­mierung” ist umfan­gre­ich und nur schw­er in einem Talk abzudeck­en. Allerd­ings lässt sich eines machen: in prak­tis­chen Auszü­gen aus echt­en Pro­jek­ten zeigt Oliv­er, was er mith­il­fe funk­tionaler Ideen beson­ders effizient umset­zen kon­nte. Es gibt über­sichtlich gestal­tete Algo­rith­men, hil­fre­iche Laufzeit­typ­isierung für wiederver­wend­bare Bib­lio­theken und selek­tive Ein­bet­tung von Rescript-Code. Achtung: es beste­ht die Gefahr, dass Sie als Zuschauer Inter­esse an funk­tionaler Pro­gram­mierung entwick­eln und manche objek­to­ri­en­tierte Prax­is als nut­z­los erken­nen. Sagen Sie nicht, wir hät­ten Sie nicht gewarnt!

Next, Nest, Nuxt… Nust?

By the time this talk is over, some­one will have invent­ed a new JS frame­work. Thank­ful­ly it’s prob­a­bly not gained much pop­u­lar­i­ty yet. In the mean­time, Express.js is no longer the frame­work with the high­est sat­is­fac­tion rate, Next.js and frame­works recent­ly took the top spots in the lat­est Sta­te­OfJS survey.

In this ses­sion we’ll com­pare the big frame­works of today, check out their fea­tures, what they are miss­ing and con­sid­er their dif­fer­ent use-cas­es. By the end of the talk, there might be a new frame­work, but at least you’ll know when and where to use the exist­ing ones.

Reflection in TypeScript

Typen sind zur Laufzeit weg. Das ler­nen wir schon von Tag 1 an, wenn wir uns mit Type­Script beschäfti­gen. Je nach Hin­ter­grund ist diese Ein­schränkung sehr schmerzhaft, ger­ade wenn wir aus Ökosys­te­men wie der C# oder der Java-Welt kom­men, wo Bib­lio­theken, die auf Reflec­tion basieren gang und gäbe sind.

Im Laufe der Zeit hat die Type­Script-Com­mu­ni­ty den­noch viele Wege gefun­den, wie wir Kon­struk­te zwis­chen der Typ- und der Werte-Welt hin und her trans­portieren kön­nen. Begleit­et mich auf ein­er Reise durch die Zeit und lernt mit mir, wozu Type­Script noch alles fähig sein kann.

Zero-dependency Web Components

Web Com­po­nents sind als wiederver­w­ert­bare UI-Kom­po­nen­ten in aller Munde, doch wie wiederver­w­ert­bar, sta­bil und wartungs­fre­undlich ist etwas, dessen inner­er Auf­bau von Frame­works und Libraries abhängt? Genau gar nicht!

Die Gute Nachricht lautet: Es geht auch – wenn nicht gar bess­er – ohne Frame­works und Libraries! Dieser Work­shop weist Ihnen den Weg her­aus aus dem Depen­den­cy-Gulasch mod­ern­er Weben­twick­lung und hin zu Zero-Depen­den­cy Web Com­po­nents, gebaut mit puren Webstandards.

Neben argu­men­ta­tivem Rüstzeug gegen den Depen­den­cy-Wahn ver­sorgt sie dieser Work­shop mit dem the­o­retis­chen und prak­tis­chen Wis­sen rund um Stan­dard-basiertes Web-Com­po­nent-Design. Ler­nen Sie nicht nur alle rel­e­van­ten Brows­er-APIs rund um Web Com­po­nents ken­nen, son­dern erfahren Sie auch, wie Sie Kom­po­nen­ten gestal­ten kön­nen, die in Sachen API und Robus­theit nativ­en HTML-Ele­menten in nichts nach­ste­hen. Von API-Basics bis zu HTML-Ele­ment-Design-Philoso­phie bleibt kein Aspekt von Zero-Depen­den­cy Web Com­po­nents unbeleuchtet.

Type-Level Fizzbuzz

Ein neuer Tag, ein neues Bewer­bungs­ge­spräch und mal wieder die selbe Auf­gabe: Imple­men­tieren Sie FizzBuzz!
Anstatt in ein­er typ­is­chen Pro­gram­mier­sprache die Regeln rund um Zahlen, Schleifen, Bedin­gun­gen und Mod­u­lo-Oper­a­tio­nen zu imple­men­tieren, kön­nen wir uns auch ein­fach mal ein Späßchen gön­nen: Wie würde euer Gegenüber wohl reagieren, wenn ihr FizzBuzz nur mit Type­Script-Gener­ics, also kom­plett auf Typ-Ebene implementiert?

Was zunächst als Spaß begin­nt, wird schnell zur fort­geschrit­te­nen Übung rund um das mächtige Typ­sys­tem von Type­Script, bei der wir Funk­tio­nen wie bed­ingte Typen, rekur­sive Typen, Tupel-Typen und viele weit­ere geschickt kom­binieren müssen.

TypeScript-Typannotationen als Programmiersprache

Type­Script-Typan­no­ta­tio­nen sind eine eigene Pro­gram­mier­sprache! Typen sind Werte, Gener­ics sind Funk­tion­spa­ra­me­ter und Type­Script als Ganzes ist nicht nur ein wenig zusät­zliche Syn­tax, son­dern eine kom­plette in JavaScript einge­bet­tete DSL, die zu ver­ste­hen sich lohnt. Type­Script-Typen nicht nur zu schreiben, son­dern richtigge­hend zu pro­gram­mieren ist eine Superkraft, in die dieser Talk Sie ein­wei­ht! Mit nur wenig Umdenken und ein paar eher unbekan­nten Type­Script-Fea­tures kön­nen auch Sie kom­plexe Typ-Beziehungs­ge­flechte aus weni­gen basalen Regeln her­leit­en. Dieser Talk führt durch die Pro­gram­mierung eines Mes­sage-Bus-Sys­tems und ver­wen­det dabei fort­geschrit­tene Type­Script-Fea­tures wie Mapped Types, Dis­crim­i­nat­ed Unions und Con­di­tion­al Types, um den Mes­sage Bus mit weni­gen, aber smarten Typ-Def­i­n­i­tio­nen type­safe zu machen. Dabei ler­nen wir Typan­no­ta­tio­nen als eigene Pro­gram­mier­sprache ken­nen und bekom­men eine gän­zliche neue Per­spek­tive auf den Umgang mit Type­Script-Typen eröffnet.

UI5 + wdi5 – Framework Entwicklung im Spannungsfeld “Enterprise”, Open Source und Zukunftstechnologien

UI5 (https://openui5.org) ist bei SAP strate­gisch geset­zt zur Erstel­lung von Weban­wen­dun­gen, wdi5 (https://js-soft.github.io/wdi5/) als zuge­höriges Tool entsprechend für end-to-end Tests.
Bei­de müssen sowohl SAP Stan­dards genü­gen (Stich­worte z.B. Rück­wärt­skom­pat­i­bil­ität und Bar­ri­ere­frei­heit), aber auch tech­nol­o­gisch auf Trends und (Brows­er-) Entwick­lun­gen reagieren. Die Zusam­me­nar­beit mit der Com­mu­ni­ty in Form von Erstel­lung und Wartung von Open Source Soft­ware Kom­po­nen­ten ist hier­für ein Schlüssel.
Der Vor­trag zeigt Tech­niken, Tools und Maß­nah­men, der­er sich UI5 und wdi5 bedi­enen, um mit Ansprüchen an Geschäftssoft­ware umzuge­hen, aber gle­ichzeit­ig Offen­heit gegenüber der Entwick­ler­com­mu­ni­ty zu wahren. Sodass die Koop­er­a­tion vorteil­haft für sowohl SAP, wie auch die Com­mu­ni­ty, bleibt.

Extrahieren von Micro-Frontends aus einer monolithischen Frontend-Anwendung

Das Konzept von Microser­vice-Architek­turen in der Soft­wa­reen­twick­lung gewin­nt zunehmend an Aufmerk­samkeit. Diese Architek­turen entste­hen oft aus dem Refac­tor­ing mono­lithis­ch­er Anwen­dun­gen. Viele Microser­vice-Architek­turen küm­mern sich wenig um das Fron­tend beziehungsweise um die Benutze­r­ober­fläche. Oft führt die Zer­schla­gung zu vie­len kleinen, lose gekop­pel­ten Dien­sten, die in einem weit­er­hin mono­lithis­chen Fron­tend zusam­menge­fasst sind. Mit ein­er Micro-Fron­tend-Architek­tur kön­nen diese lose gekop­pel­ten Sys­teme systematisch/dynamisch in ein­er Benutze­r­ober­fläche zusam­menge­führt wer­den. Ich gebe in diesem Vor­trag einen Überblick über ver­schiedene Migra­tionsan­sätze zu Micro-Fron­tend-Architek­turen und zeige einen Migra­tionsansatz am Beispiel des Soft­ware-Visu­al­isierung­spro­gramms ExplorViz.

Ab Jetzt deine Anwendung testen: Einführung in Angular Unit-Testing Techniken

Beim Erstellen von erfol­gre­iche Angu­lar Anwen­dun­gen, spielt das Testen eine sehr wichtige Rolle.
Mit den Werkzeu­gen, die das Frame­work bietet kön­nen wichtige Code­ab­deck­un­gen erre­icht werden.
In diesem Work­shop erfährst du über die Moti­va­tion und Gründe für das Testen. Zudem wird einen
tiefen Ein­blick in das Unit-Test­ing von Angu­lar An gegeben sowie Frame­work-agnos­tis­che Test­strate­gien vorgestellt. Die Kom­bi­na­tion aus The­o­rie und prak­tis­che Übun­gen helfen dabei
ver­schiedene prax­is­na­he Szenar­ien zu testen.

Nx Monorepo: Frontend-Architekturen effizienter entwickeln und visualisieren

Die Art des Pro­jek­ts, an dem man arbeit­et, wirkt sich auf die Pro­jekt Entschei­dun­gen aus.
Kom­pliziert­er wird es, wenn man an mehreren zusam­men­hän­gen­den Pro­jek­ten arbeitet.
Wie verän­dert dies die Verze­ich­nis­struk­turen des Pro­jek­tes? Wie sollte der Code zwis­chen Pro­jek­ten geteilt wer­den? Nx ist ein Tool, das darauf abzielt, diese Prob­leme zu lösen. Wir gehen in diesem Vor­trag die Kern­funk­tion­al­itäten von Nx durch, sowie die Vorteile und Her­aus­forderun­gen die sich aus dem Ein­satz von Monore­pos im all­ge­meinen und Nx im beson­deren ergeben können.