Category

Eine Single-Page-Applikation (kurz SPA) ist eine Webanwendung, die in der Regel aus einem einzigen HTML-Dokument besteht und deren Inhalte dynamisch nachgeladen werden. Bis jetzt wurden diese Anwendungen in JavaScript (beziehungsweise TypeScript) mit Angular, React, VueJS, Aurelia und Co. programmiert.

Blazor ist ein neues Framework von Microsoft mit dem es möglich ist, eine SPA in C# mit Standard .NET Bibliotheken zu programmieren. In September 2019 wurde mit dem .NET Core 3.0 «Blazor Server» veröffentlicht.  Microsoft hat angekündigt in Mai 2020 die Clientseitige Version «Blazor WebAssembly» auf den Markt zu bringen.

Geschichte

Der Browser ist eine der wichtigsten Anwendungen auf unseren Computern. 1994 kam die erste Version von Netscape auf den Markt, 1995 die erste Version vom Internet Explorer. Die Hersteller wollten natürlich so viele Benutzer wie möglich für sich gewinnen. Deshalb versuchten die Hersteller mehr HTML-Funktionen als ihre Konkurrenten anzubieten. Das ‘World Wide Web Consortium (W3C)’ veröffentlichte am 28. Oktober 2014 die endgültige HTML5-Spezifikation. Damit war der erste Browserkrieg beendet.

Browser Kriege

Quelle: http://royalmulti.blogspot.com.au/2012/07/holy-browser-wars.html

Historische WEB Meilensteine

1995 schrieb Brendan Eich in 10 Tagen JavaScript und löste den zweiten Browserkrieg aus. Dieses Mal geht es um die JavaScript-Leistung.

Klassische Ausführung JavaScript

Vor der WebAssembly-Technologie wurde JavaScript in den Browser geladen, analysiert, in Bytecode kompiliert und anschließend in systemeigenen Code konvertiert. Das binäre Format wird in einer virtuellen Maschine (die JavaScript Engine) ausgeführt.

WebAssembly

Mit der WebAssembly-Technologie (ab 2017) kompiliert der Server den Code in WASM (WebASseMbly). Der WASM Code wird in den Browser geladen und dann in systemeigenen Code konvertiert. Die JavaScript Engine führt den konvertierten Code wie zuvor aus.

JavaScript vorkompiliert auf dem Server zur WebAssembly

WebAssembly ist ein binäres Format, welches für die Ausführung im Browser optimiert ist. Es ist KEIN JavaScript.

Dies sind die Merkmale der WebAssembly (kurz WASM):

• WASM wird von der W3C vorangetrieben und wird ohne Plug-in von allen führenden Browsern (Chrome, Edge, Firefox und WebKit) auf Desktop und Mobilplattformen unterstützt.
• Es ist ein binäres Format für eine virtuelle Maschine. Sprachen wie C++ können in WASM übersetzt werden.
• WASM wurde nicht ausschließlich für den Browser konzipiert, sondern kann generell als Standard für portablen Code genutzt werden (z.B. Electron).
• WASM läuft in einer Sandbox im Browser und man kann mit WASM JavaScript aufrufen und umgekehrt.
• WASM ist bei der Ausführung so schnell wie nativer Code.
• Es gibt ein Textformat für WASM, damit man mit dem Code leichter umgehen kann und Debuggingunterstützung hat.

ASP.NET Core MVC & Razor Pages

Für die serverseitigen Erstellung von HTML Pages gibt es von Microsoft seit jeher Web Forms und seit 2008 ASP.NET MVC. Mit dem ASP.NET Core 2.0 Release kamen die Razor Pages. Das konventionelle MVC Model wird mit Razor Pages wieder vereinfacht: das ViewModel und der Controller sind integriert in die Razor Seiten. Im Internet findet man das Statement:

«Razor Pages ist Web Forms aber dann richtig gemacht».

All diese Technologien generieren HTML auf dem Server und senden die Seiten zum Browser. Serverseitige Internetseiten benötigen keine Dienste wie REST Schnittstellen, um die Daten im Browser zu laden, das wird bereits auf dem Server erledigt. Dadurch sind die Sicherheitsvorkehrungen bei serverseitig generierten Internetseiten einfacher.

ASP.NET Core MVC & Razor Pages

Quelle: https://www.heise.de/developer/meldung/Microsoft-will-Framework-Blazor-nun-zur-Produktreife-bringen-4409015.html

Der grösste Nachteil sind die Roundtrips, die es braucht um neue Inhalte für den Browser zu generieren. Eine Lösung ist die AJAX-Technologie, welche nur Teile der Seite aktualisiert.
Ein anderer Ansatz sind die Single Page Applikationen (SPA); progressive Webseiten, welche die Inhalte meist über REST-Schnittstellen dynamisch nachladen. Diese Seiten werden auch clientseitige Webanwendungen genannt, weil sich viel Logik im Browser befindet. Die Applikation reagiert dadurch so schnell, als ob es eine Desktop-Anwendung wäre.
Bis jetzt wurden JavaScript-lastige Technologien wie Angular und React verwendet. Mit Blazor wird es jetzt möglich, eine SPA in C# zu programmieren. Das neue SPA Blazor Framework baut auf dem gleichen Konzept auf wie die Razor Pages (Blazor = Browser enabled Razor).

Clientseitige Blazor

WebAssembly und Mono

Mono ist eine Open-Source-Implementierung der .NET-CLI-Spezifikation, was bedeutet, dass Mono eine Plattform für die Ausführung von .NET-Assemblies ist. Der ursprüngliche Zweck von Mono war, die .NET Runtime Plattform unabhängig zu machen. Mono wird in Xamarin zum Erstellen mobiler Anwendungen verwendet, die auf Android, Windows Phone und iOS ausgeführt werden. Die Mono Runtime ist in C++ geschrieben, wodurch es möglich ist, Mono in eine WebAssembly umzuwandeln.

Dem Mono-Team ist es gelungen, das Mono-Runtime in eine WebAssembly zu kompilieren.

Das WASM Mono-Runtime läuft im Browser und führt direkt .NET Assemblies aus. Die .NET Assemblies müssen also nicht erst in WASM kompiliert werden. Der Nachteil ist, dass man viele .NET Assemblies im Browser laden muss. Dieser Code kann minimiert werden durch Anwendung von Tree Shaking Algorithmen, welche unbenutzten Code entfernen. Diese sind im Moment aber noch in Entwicklung.

Clientseitiger ASP.NET Blazor

Quelle: https://www.heise.de/developer/meldung/Microsoft-will-Framework-Blazor-nun-zur-Produktreife-bringen-4409015.html

Wie es funktioniert

Wie bei serverseitigen Razor Pages funktioniert Blazor mit Razor Seiten. Razor Seiten (*.razor) beinhalten HTML mit embedded C# Code. Eine Razor Seite hat optional eine Code-Behind Datei (*.razor.cs), in welcher nach Best Practices der ViewModel-Code ausgelagert ist (muss aber nicht).

@page "/counter"

<h1>Counter</h1>

<p>Current count: @currentCount</p>

<button class="btn btn-primary" @onclick="@IncrementCount">Click me</button>

@code {
    int currentCount = 0;

    void IncrementCount()
    {
        currentCount++;
    }
}

Die Razor Seite wird kompiliert und ausgeführt im Blazor Engine. Das Resultat ist ein render tree, welcher zu JavaScript gesendet wird. Das JavaScript gleicht das DOM vom Browser ab, um den render tree abzubilden (also kreieren, aktualisieren und löschen von HTML Elementen und Attributen).

Wenn auf der Seite eine Aktualisierung stattfindet (z.B. nach einer Methode, die ausgeführt wird auf einem Button Click Handler) werden die Änderungen erneut an JavaScript gesendet, welche das DOM aktualisiert.

Clientseitiger Blazor Code kann ausgeführt werden in Electron Desktop Applikationen (wird z.B. für Visual Studio Code verwendet).

Vorteile Clientseitige Blazor

• Der Server wird entlastet, weil die Arbeit im Browser erledigt wird.
• Es ist eine pure clientseitige SPA ohne .NET serverseitige Abhängigkeiten.

Nachteile Clientseitige Blazor

• Die App läuft in der Sandbox des Browsers und hat (wie alle clientseitige Anwendungen) limitierte Möglichkeiten.
• Es dauert viel länger bis die App gestartet ist, weil erst die DLLs heruntergeladen werden müssen.

Serverseitige Blazor

Diese Variante bezieht sich auf ein serverseitiges Ausführungsmodell von Blazor. Die Anwendung fühlt sich wie eine SPA an, aber anstatt .NET-Code im Browser auszuführen, wird der Code auf einem Server ausgeführt.

Serverseitiger ASP.NET Blazor

Quelle: https://www.heise.de/developer/meldung/Microsoft-will-Framework-Blazor-nun-zur-Produktreife-bringen-4409015.html

Wie es funktioniert

Herkömmliche serverseitige Apps wie MVC erfordern eine vollständige Aktualisierung der Seite, um den Browser zu aktualisieren. Blazor ähnelt eher einer Ajax-Anwendung, wenn es um die Anzeige von Updates geht. Die Benutzeroberfläche ist jedoch viel gesprächiger als bei einer durchschnittlichen Ajax-Anwendung. Grundsätzlich erhält der Browser über eine Web-Socket-Verbindung inkrementelle Ansichtsaktualisierungen vom Server. Jedes Mal, wenn die Ansicht aktualisiert werden muss, wird über eine Socket-Verbindung (SignalR) eine Anforderung an den Server gesendet. Nachdem die Anforderung auf dem Server ausgeführt wurde, wird die inkrementelle Ansichtsänderung an den Browser zurückgegeben.

Vorteile Serverseitige Blazor

• Die App startet sehr schnell, da im Vergleich mit clientseitigem Blazor keine DLLs zum Browser transferiert werden müssen (z.B. mono.wasm oder .NET Assemblies).
• Der volle .NET Framework Stack steht auf dem Server zur Verfügung.
• Gewohnte .NET Entwicklungsumgebung samt Debugging funktioniert nach wie vor.

Nachteile Serverseitige Blazor

• Schlecht skalierbar für viele Benutzer. Ursachen: SignalR Technologie, für jeden Benutzer müssen die States verwaltet werden, serverseitige Rechnerlast.
• Höhere Latenzzeiten als clientseitige Blazor, fühlt sich aber immer noch an wie eine SPA.
• Kein offline Betrieb möglich, weil eine Verbindung zum Server notwendig ist.

Ausschau (Stand 12.2019)

Mai 2020, Blazor WebAssembly = Client-side Blazor
Kann auch offline funktionieren.

2020, Blazor Progressive Web Application (PWA)
Funktioniert gleich wie im Browser. Hat Ikon auf Desktop und Eintrag im Start-Menu. Funktioniert auch offline.

2020, Electron + Blazor
Basiert nicht mehr auf WebAssembly und Mono aber auf nativen .NET Core. Hat Ikon auf Desktop und Eintrag im Start-Menu. Funktioniert auch offline.

Microsoft plant C# direkt in WASM zu kompilieren wodurch Mono nicht mehr gebraucht wird.

Konzept: Native UI + Blazor (.NET Core)
Rendert kein HTML aber eigenes UI. Mit Blazor kann man z.B. Flutter nachmachen.

Flutter ist ein Open Source Entwicklungs-Kit von Google. Es wird verwendet um Apps für Android, iOS, Windows, macOS, Linux, Google Fuchsia und das Web zu erstellen. Flutter apps sind in Dart geschrieben und nutzen viele der erweiterten Funktionen dieser Sprache.
[WikiPedia]

Fazit

Nach Silverlight startet Microsoft mit Blazor einen zweiten Versuch, um Webanwendungen mit der .NET Framework Technologie zu erstellen. Dieses Mal braucht es im Browser keine Microsoft Abhängigkeiten und die unterliegende WebAssembly Technologie wird vom W3C unterstützt.
Weil die server-seitige Blazor Variante im Herbst 2019 offiziell veröffentlicht wurde und die Veröffentlichung der client-seitige Version in Mai 2020 zugesagt wurde, kann man mit weinig Risiko neue Projekte mit Razor realisieren. Es braucht nur ein paar Codezeilen-Änderungen um server-seitiges Blazor in client-seitiges Blazor um zu wandern.

Eine Blog-Serie zum Vergleich von Elm, ReactJS und AngularJS anhand eines praktischen Beispiels.Hier geht es direkt zu [Teil 1, 2, 3, 4, 5]

Herrlich frische Bergluft bläst unseren Wandervögeln entgegen auf der Ämpächli Alp, wo Angular sich vor allem über den festen Boden unter seinen Füssen freut, sowie die Aussicht auf eine Erfrischung im Restaurant bei der Bergstation. Elm ist aber überhaupt nicht in der Stimmung, bereits eine Rast einzulegen. Sie einigen sich auf einen Treffpunkt: Hängstboden. Elm marschiert wehenden Schrittes los, mit gewölbter Brust, den Kopf der Sonne entgegengestreckt.

_{Zur Erinnerung: Das Endziel ist ein Anagram-Generator für die deutsche Scrabble-Community.}

Etappenziel: Interaktive Benutzeroberfläche

Vorbereitung (create-elm-app)

In den letzten Monaten ist die Elm-Community sehr weit gewandert und nebst zahlreichen Editor-Plugins für die gängigen Opensource-Editoren sind andere wertvolle Tools erschienen, wie z.B. create-elm-app, welches sich webpack bedient, und damit eine “state-of-the-art” Toolchain für die Entwicklung unter elm bereitstellt.

Zur Erinnerung: Elm-Programme werden mit dem Compiler elm-make nach javascript kompiliert und das wiederum wird in eine Html-Seite eingebunden, entweder in ein Ziel-div oder fullscreen oder sogar headless (Keine Anzeige).

Der mitgelieferte elm-reactor (development web-server) reicht für die Entwicklung eigentlich aus, aber mit webpack gibt es jetzt schon solche goodies wie “hot reload” und css stylesheets können so auf die altbekannte Weise eingebunden werden, was für den Anfang auch vortheilhaft ist.

Dadurch bleibt mehr Zeit für die Sache, die Spass macht: die Programmierung mit Elm. Wer später seinen eigenen Build-Prozess einführen möchte, kann die Abhängigkeit problemlos durch das Tool entfernen lassen.

Die Installation erfolgt auf der Kommandozeile: sudo npm install -g create-elm-app

Wir fangen also nochmals ganz von vorne an mit unserer Applikation und kopieren die Models aus den vergangenen Blog-Posts bei Bedarf in unser Projekt. Zuerst aber mal eine neue elm-app erstellen:

create-elm-app /path/to/my/project/elm-anagrams

Creating elm-anagrams project...
 
Packages configured successfully!
 
Project is successfully created in `/path/to/my/project/elm-anagrams`.

cd /path/to/my/project/elm-anagrams

elm-app start

Nach kurzer Zeit erscheint:

Compiled successfully!
 
The app is running at:
 
    http://localhost:3000/
 
To create production build, run:
 
    elm-app build

Editor: Atom, Brackets, Emacs, IntelliJ, Sublime Text, Light Table, Vim, VS Code

Hier ist die Feature-Matrix

Persönlich nutze ich im Moment Atom mit folgenden Plugins:

• language-elm
• elm-format
• linter-elm-make
• elmjutsu

Ich wechsle demnach (in einer neuen Konsole) ins elm-anagrams-Verzeichnis und starte atom .

Projekt-Struktur

create-elm-app legt die Ordner src und tests an. Was durch elm-make kompiliert wird, landet im Verzeichnis elm-stuff. Das letzte Verzeichnis, dist, wird vom Build-Tool erzeugt. Ausserdem wird gleich auch noch die korrekte .gitgnore-Datei erzeugt, so dass wir nur noch git init && git add . && git commit -m “initial” aufrufen müssen, um unsere Resultate unter Versionskontrolle zu stellen.

Damit wir sofort loslegen können, öffnen wir die Datei src/App.elm, wo wir den folgenden Inhalt vorfinden:

module App exposing (..)
 
import Html exposing (text, div)
 

subscriptions model =
    Sub.none
 
 
update msg model =
    ( model, Cmd.none )
 
 
init =
    ( (), Cmd.none )
 
 
view model =
    div [] [ text "Your Elm App is working!" ]

Wir erinnern uns daran, dass elm mit einem immutable (unveränderbaren) Model operiert. Das Modell wird immer an die betreffenden Funktionen übergeben und daraus wird (in den meisten Fällen) ein neues Modell resultieren.

Die folgende Grafik veranschaulicht dies und beschreibt die Funktionsweise von elm.

Update-Loop

@fredcy‘s update loop:

Here is a simplified model of how an Elm 0.17 program operates.

The update function blocks waiting for the next incoming Msg. When received it creates a new model value and commands. The view and subscriptions functions then run against the new model value, producing new Html Msg and Sub Msg values, respectively. Then update waits for the next Msg. Note that subscriptions is called after each update.

Happy Elming!

So, hier noch der Link zum Syntax, und dann legen wir los:

Das Ziel

Unser heutiges Ziel ist es, eine einfache Eingabe-Maske zu erstellen, welche ein Textfeld enthält, welches bei Eingabe eines Zeichens den Bereich darunter entsprechend aktualisiert. Zu einem späteren Zeitpunkt befassen wir uns mit dem HTTP-Aufruf ans Backend.

init und Model

Model the problem!

Zuerst soll man sein Problem modellieren. Welche Daten muss unser Modell enthalten, damit wir unser Ziel erreichen können?

Dazu erstellen wir im File App.elm zwei neue Typen:

• einen mit dem treffenden Namen Model (es ist eine elm-Konvention, das Hauptmodell Model zu nennen) und
• Anagram, welcher später ausgebaut wird.

Eine erste Version könnte folgendermassen aussehen:

type alias Anagram = String   -- bloss ein neuer Name für String, lesbarer, lässt einfachen Ausbau zu
 
type alias Model = 
  { input: String             -- der momentane String im Textfeld
  , anagrams: List Anagram    -- die Liste der aktuellen Resultate
  }

init: (Model, Cmd Msg) 
init = ( { input = "", anagrams = [] }, Cmd.none )

_{() kann als ein Tupel ohne Elemente betrachtet werden, oder ein Wert ohne Daten.}

Cmd und Msg

Der Rückgabe-Wert von init ist ein Tuple tup = ( x, y ), welches an erster Stelle (fst tup) unser Modell enthält, und an zweiter Stelle (snd tup) stehen allfällig auszuführende Kommandos, die Funktionen mit Seiten-Effekten betreffen. elm kontrolliert die Aufrufe solcher Funktionen explizit, damit es nicht zu Laufzeitfehlern kommt. Der Entwickler wird dadurch gezwungen, auch den möglichen Fehlerfall im Code abzudecken. Ersichtlich wird das am Typ Task, der für den Aufruf solcher Funktionen verwendet werden muss:

type alias Task err ok = 
    Task err ok

Um einen Task erstellen zu können, müssen zwei Argumente (Funktionen) übergeben werden. Das erste behandelt den Fehlerfall, das zweite den Erfolgsfall mit dem angeforderten Resultat. Funktionen, die Seiten-Effekte aufweisen, sind z.B. Http.get oder Date.now.

Jedes Cmd spezifiziert:

1. Auf welche Effekte man zugreifen möchte und
2. Welche Nachrichten in die Applikation zurückgelangen.

Und obwohl wir in der Signatur von init angegeben haben, dass wir Nachrichten vom Typ Msg zurückhaben wollen, haben wir diesen Typ nirgends spezifiziert. Zeit, dies nachzuholen.

type Msg 
  = NoOp

type Msg 
  = NoOp 
  | OnInputChanged String

Dieses Konstrukt nennt sich Union Type und ist eins der mächtigen Werkzeuge der funktionalen Programmierung. Damit können auf natürliche Weise auch komplexe Strukturen ausgedrückt werden. Union Types werden oft auch tagged unions genannt, oder auch ADTs (algebraic data types). Sie beherbergen noch sooo viel mehr, wie der Begriff algebra in ADT vermuten lässt. Dieses höchst spannende Thema muss aber noch warten, weil hier geht es um elm, und bei elm lautet das Motto: “Let’s build stuff”.

Für den Moment reicht es, zu erkennen, dass ein Wert vom Typ Msg entweder vom Typ NoOp (Nachricht ohne zusätzlichen Wert) sein kann, oder vom Typ OnInputChanged mit einem zusätzlichen “Payload” vom Typ String

view

Nun können wir eigentlich bereits unsere View erstellen. Mit voller Signatur lautet diese im Original:

view: Model -> Html Msg 
view model =
    div [] [ text "Your Elm App is working!" ]

h1 : List (Attribute msg) -> List (Html msg) -> Html msg

Nehmen wir das folgende Html an: <h1 class=”special” z-index=”50″><span>Bingo</span><span>Mania</span></h1>

Ein Html-Element hat 0-n Attribute (class, z-index), sowie eine Liste von enthaltenen, oder Kind-Elementen, wie man das von einer Baumstruktur gewohnt ist. Die Funktions-Signatur drückt genau dasselbe aus: h1 ist der Name einer Funktion mit zwei Argumenten. Beide Argumente sind Listen, die erste enthält jedoch Werte vom Typ Html.Attribute msg , die zweite Werte vom Typ Html.Html msg. Hinweis: die kleingeschriebenen Typnamen (hier msg), weisen auf Platzhalter für beliebige Typen hin, in unserem Fall heisst der konkrete Typ ja Msg (Typnamen sind immer upper case).

In elm sähe dasselbe demnach so aus: h1 [ HA.class “special”, HA.zIndex “50” ] [ span [] [text “Bingo”], span [] [text “Mania”] ]

Hinweis: Bestehendes Html kann mit dem Paket mbylstra/html-to-elm nach elm konvertiert werden. Demo

Zurück zum Anagrammerator: Hier ist der Code für die View, wie sie im Bild oben angedeutet ist, ganz ohne zusätzlichen Schnickschnack:

import Html.Attributes as HA
 
view : Model -> Html Msg 
view model =
    div []
        [ Html.h1 [] [ text "Anagrammerator" ]
        , Html.h2 [] [ text ("Input: " ++ model.input) ]
        , viewTextField model
        , viewResults model
        ]
 
 
viewTextField : Model -> Html Msg 
viewTextField model =
    div [ HA.class "text-field-area" ]
        [ Html.span []
            [ Html.label [ HA.for "input" ] [ text "Buchstaben auf Bank" ]
            , Html.input
                [ HA.id "input"
                , HA.type' "text"
                ]
                []
            ]
        ]
 
 
viewResults : Model -> Html Msg 
viewResults model =
    div [ HA.class "result-area" ]
        [ Html.h2 [] [ text "Resultate" ]
        , Html.ul [] (List.map viewAnagram model.anagrams)
        ]
 
 
viewAnagram : Anagram -> Html Msg 
viewAnagram anagram =
    Html.li [ HA.style [ (,) "font-weight" "bold" ] ] [ text anagram ]

• Zuerst wird ein zusätzliches Modul für die Html-Attribute importiert und mit dem alias HA versehen, damit es später über diesen Namespace-Namen angesprochen werden kann. Wir könnten mit expose (id,style,type’) auch gleich die für unseren Code benötigten Funktionen bereitstellen, so wie es für (Html, div, text) getan wurde. Grundsätzlich sollte man aber, der Lesbarkeit zuliebe, bei Abhängigkeiten immer möglichst explizit sein. Ganz schlimm ist import Html exposing (..), weil ich zu einem späteren Zeitpunkt nicht mehr einfach herausfinden kann, welcher Code nun importiert wurde.
• Die view-Funktion wurde aufgeteilt auf mehrere kleine Funktionen. Dies vereinfacht den Code, macht ihn wartbarer und lässt den Programmenschen sich wiederholende Muster im Code schneller erkennen.
• In der Funktion viewTextField wird ein label und ein input vom Typ text erstellt. Man sieht auch, wie auf den äusseren div eine css-Klassen angewandt wird. Styles werden (da create-elm-app das alles für uns automatisiert), im src/main.css definiert und automatisch neu geladen.
• Die Funktion viewResults verwendet die Funktion List.map, welche zwei Argumente verlangt: Eine Funktion, die einen Wert in einen Wert eines anderen Typs überführt (a -> b) und eine Liste von Werten, hier unsere (leere) Liste der Anagramme. Die Funktion wird dann auf jeden Wert in der Liste angewandt, was wiederum zu einer Liste führt, nur haben die Element in der neuen Liste den Typ Html Msg

preview and review

Wer seinen Browser beim Entwickeln betrachtet hat, wird feststellen, dass sich dieser bei jeder Änderung automatisch aktualisiert, ohne seinen Zustand zu verlieren. Falls die app nicht läuft, diese wieder starten, und im Browser den Output betrachten. Wer unbedingt muss, kann nun auch etwas “live” stylen, inder er main.css anpasst und speichert.

Wir stellen aber fest, dass hier noch nichts von Bedeutung geschieht. Eingaben im Textfeld werden nicht sichtbar.

Eine erste Änderung könnte nun so aussehen:

Html.input
  [ HA.id "input"
  , HA.type' "text"
  , HA.value model.input   -- setze den Wert des Input-Felds auf den Wert des Feldes `input` im Model.
  ] []

import Html.Events as HE
 
...
  , Html.input
      [ HA.id "input"
      , HA.type' "text"
      , HA.value model.input
      , HE.onInput OnInputChanged  -- übersetze das Ereignis in eine Nachricht
      ]
      []

update

In dieser Funktion kommen alle Nachrichten zusammen, egal aus welcher Quelle sie stammen (Benutzereingabe, Subscriptions, Tasks) und werden ausschliesslich hier behandelt. Natürlich sind Hilfsfunktionen angebracht, nein, erwünscht, aber oft sind diese Updates gar nicht so involviert.

update : Msg -> Model -> ( Model, Cmd Msg ) 
update msg model =
    case msg of
        NoOp ->
            ( model, Cmd.none )
 
        OnInputChanged val ->
            ( { model | input = val }, Cmd.none )

{ model | input = val }

loop

Das Resultate-Feld ist jetzt halt leer geblieben. Wer möchte, kann im init  Werte einfüllen, und mit Listen von Werten herumspielen, oder selbst versuchen, die Liste interaktive mit Werten zu befüllen. Wir holen uns beim nächsten Mal die Werte von einem Webserver via Http-Request.

Nun aber weiterhin viel Spass beim Ausprobieren!

Elm sitzt mit gekühltem Getränk im Schatten eines grell-gelben Sonnenschirms auf der Terasse des Berggasthauses Bischofalp und fragt sich, wie lange es wohl dauern wird, bis die anderen auch hier eintreffen. Vermutlich haben sich die anderen vor der Abreise noch mit massenhaft unnötigem Material eingedeckt, bevor sie die kurze Strecke in Angriff nahmen. Sie klaubt ihr Handy aus der Hüfttasche und vertreibt die Zeit mit ein paar Spielen:

elm-package install –yes elm-community/list-extra

import List.Extra as List
import String
   
...
 
     OnInputChanged val ->
            let
                anagrams =
                    String.split "" val
                        |> List.permutations
                        |> List.map String.concat
                        |> List.unique
            in
                ( { model | input = val, anagrams = anagrams }, Cmd.none )

Damit fordert sie die Leistungsgrenzen ihres mobilen Browsers nun doch arg heraus. Und da ein Telefon mit Strom heute den Unterschied zwischen Leben und Tod bedeuten könnte, steckt sie es wieder weg… wo bleiben die anderen bloss?

Sind sie wohl schon aufgebrochen? Oder schon zusammengebrochen? Schaffen Sie den ersten Aufstieg des Elm-Höhenweges? Trink noch einen Kaffe Luz und erfahre im nächsten Teil, wie es React und Angular in der Zwischenzeit ergangen ist.