Design Develop Test Deploy

2022 - Co było…Co jest…Co będzie…

2022-01-08T00:00:00+00:00

No i mamy styczeń! Czas podsumowań minionego roku oraz planowania działań na rok kolejny. W moim przypadku trzeci raz w blogowej formie:

Zobaczmy, co ciekawego wydarzyło się w ostatnich 12 miesiącach.

Co było…

“Jeden obraz wart więcej niż tysiąc słów” (chińskie przysłowie):

Na początku 2021 roku postanowiłem, że nie zmieniam długofalowego celu, który polegał na zdobyciu umiejętności budowania systemów zawierających Frontend, Backend oraz Integrację z systemami zewnętrznymi z wykorzystaniem elementów wymienionych na zdjęciu. Wprowadziłem trzy-kolorowy stopień osiągnięć:

zielony
- najwyższy, oznaczający umiejętności pozwalające na realizacje zagadnień
niebieski
- praktyczne znajomość
- pozwala na realizację zagadnień z większym wsparciem wyszukiwania i analizowania pomocnych treści
- do osiągnięcia najwyższego stopnia, potrzeba więcej treningów
czarny
- wiedza teoretyczna, pozwalająca dyskutować w danym temacie

Planowałem większą część czasu poświęcić zagadnieniom dookoła Frontendu. Kierunkiem było podejście JAMstack z wykorzystaniem frameworków C# Blazor oraz F# Bolero.

Osiągnięciami i przemyśleniami miałem dzielić się na tym blogu.

Co jest…

“Jeden obraz wart więcej niż tysiąc słów” (chińskie przysłowie):

Design

Przez cały poprzedni rok nie natrafiłem na materiały, które radykalnie zmieniłby moje podejście do wytwarzania oprogramowania. Niezmiennie trzymam się koncepcji z kursu Advanced Distributed System Design (ADSD).

Brakującym elementem w całej układance była wiedza z programowania Webowego. Sprawdziłem, o co w tym chodzi i od razu natrafiłem na styl architektoniczny Model-View-Update (MVU). To właściwie zamknęło temat projektowania, dlatego zamieniam JAMstack na MVU, jako główny koncept projektowy.

Develop

80% dostępnego czasu spędziłem na ćwiczeniu programowania Webowego z użyciem dwóch frameworków: F# Bolero oraz C# Blazor. Pierwszy z nich rozszerza drugi o implementację wzorca Model-View-Update oraz wiele innych przydatnych mechanizmów.

Pozostałe 20% poświęciłem przepisywaniu na język F# systemu komentarzy na blogu, który zrealizowany jest z wykorzystaniem wybranych technik wymienionych na zdjęciu.

Test

Dalej bez zmian. Dzielenie kodu na małe, niezależne części, które można przetestować za pomocą automatycznych testów jednostkowych oraz manualnych testów integracyjnych sprawdza się dość dobrze.

Deploy

Również bez zmian. Tematy czekają na swoją kolej.

Blog

Od strony wizualnej nic się nie zmieniło. Napisałem 8 artykułów, o dwa mniej w porównaniu do poprzedniego roku.

Co będzie…

Rok temu, o tej porze, dokładnie wiedziałem, czym będę się zajmował w kolejnych miesiącach. Dzisiaj nie mam sprecyzowanych celów. Plan jest taki, aby na bieżąco wybierać tematy z puli, zgłębiać zagadnienie i dzielić się poznaną wiedzą.

To tyle, jeśli chodzi o podsumowanie minionego roku. Dzięki za przeczytanie artykułu. Powodzenia z Twoimi planami oraz ich realizacją!

ADSD - NServiceBus - C# - F# - Reloaded

2021-11-14T00:00:00+00:00

No i stało się! System komentarzy, na którym ćwiczę różne koncepcje związane z wytwarzaniem oprogramowania, doczekał się nowej wersji. Do tej pory bazował na wielkiej czwórce. Najnowsza wersja zrealizowana jest z wykorzystaniem trójki z nich:

Dlaczego tak? Cała historia zaczyna się w tym miejscu i przewija się przez wszystkie późniejsze artykuły, aczkolwiek początki sięgają wpisu nr jeden.

Host

Proces realizacji całego przedsięwzięcia składał się z trzech części:

ADSD - utrzymanie dotychczasowej architektury rozwiązania
F# - zamiana kodu C# na F# 5, który upraszcza implementację Sagi
NServiceBus - wykorzystanie nowości wprowadzonych w wersji 7.4

Zacząłem od podniesienia F# do wersji 5, NServiceBus’a do wersji 7.5.0 oraz pozostałych paczek Nuget do ich najnowszych wersji. Wszystko ładnie kompilowało się i działało.

Kolejnym krokiem było przerobienie projektów typu Host. Najpierw dla Web, a potem dla NServiceBus Endpoint. Po zmianie plików z .csproj na .fsproj projekty przestały się kompilować. Zamiana C# na F# była pierwszym testem w stylu:

“Czy faktycznie znam już F# na tyle dobrze, żeby móc zrealizować tego typu zadanie?”

Proces przepisywania kodu dostarczył mi niezłego fun’u :) Do realizacji używałem dwóch narzędzi:

edytora tekstu bez żadnych dodatków - Visual Studio Code
kompilatora języka F#

Po paru przebiegach coraz lepiej rozumiałem mowę kompilatora. Szybszy efekt:

“…aha…no tak…”

Przykłady wprowadzanych zmian:

inne słowa kluczowe opisujące konstrukcje językowe np. klasy
ważna kolejność ułożenia plików w projekcie - z góry na dół - elementy re-używalne muszą być “wyżej” niż elementy, które z nich korzystają
zasięg określany przez wcięcia, a nie przez nawiasy {}
średniki nie są potrzebne
…

Policy

W tym momencie przyszła kolej na zmianę kluczowych elementów systemu - Policies, w większości zaimplementowanych, jako NServiceBus Saga. Realizując tę część, doświadczyłem tego, co naprawdę kryje się pod stwierdzeniem:

“To zależy”

W poprzedniej wersji systemu potrzebne były dwa projekty. Jeden na kod NServiceBus’a napisany w C#, drugi na kod Logiki napisanej w F#. Logicznie Saga oraz Logika stanowiły jedność. Fizycznie, były rozproszone po różnych projektach. Wszystko zgodnie z zasadami ADSD. W momencie, kiedy Saga przechodziła na F#, można było przenieść kod logiki w to samo miejsce, gdzie kod Sagi i odseparować te dwa elementy modułem. Dzięki temu zniknęła konieczność używania interoperability więc interfejs oraz klasa realizująca logikę przestały być potrzebne. Logiką stały się zwykłe pure functions, których nie trzeba nigdzie wstrzykiwać. Można ich używać tam, gdzie są potrzebne. Struktura kodu uprościła się, a zasady ADSD zostały zachowane.

W tym kontekście, odpowiedź na pytanie “Czy potrzebny jest osobny projekt na logikę?”, brzmiała “To zależy”. Od czego? Od tego, czy mieszany jest kod C# z kodem F#. Jeśli nie, to osobny projekt jest zbędny.

Saga Mapping

W trakcie zmiany C# na F#, skorzystałem z jednej z nowości wprowadzonych w NServiceBus 7.4 - sposobie mapowania Sagi z Message’ami.

Pierwotna metoda mapowania wygląda tak (przykład w C#):

protected override void ConfigureHowToFindSaga(SagaPropertyMapper<PolicyData> mapper)
{
    mapper.ConfigureMapping<RegisterComment>(message => message.CommentId)
          .ToSaga(data => data.CommentId);

    mapper.ConfigureMapping<ResponseCreateGitHubPullRequest>(message => message.CommentId)
          .ToSaga(data => data.CommentId);
}

Najpierw podaje się Message do mapowania - ConfigureMapping, a potem property Sagi - ToSaga.

Nowa metoda pozwala to zrobić tak (przykład w F#):

override this.ConfigureHowToFindSaga(mapper: SagaPropertyMapper<PolicyData>) =
    mapper.MapSaga(fun saga -> saga.CommentId :> obj)
          .ToMessage<RegisterComment>(fun message -> message.CommentId :> obj)
          .ToMessage<ResponseCreateGitHubPullRequest>(fun message -> message.CommentId :> obj) |> ignore

Najpierw podaje się property Sagi - MapSaga, a potem wymienia się Message’e do zmapowania - ToMessage.

Niewielka z pozoru zmiana, mocno upraszcza analizę kodu.

SQL Persistence

W całym procesie zmiany najbardziej obawiałem się wystąpienia niestandardowej sytuacji, która zablokuje zrealizowanie całego przedsięwzięcia. Taka sytuacja zdarzyła się, gdy testowałem zmiany z użyciem SQL Persistence. W trakcie kompilacji pojawiał się komunikat:

error : SqlPersistenceTask: Unable to determine Saga correlation property because an unexpected method call was detected in the ConfigureHowToFindSaga method.

SQL Persistence próbuje wywnioskować, które property z Saga Data pełni rolę correlation.

Ta sama struktura kodu działała w C#, ale nie w F#. Przeglądając source code oraz dokumentację okazało się, że wnioskowanie polega na przeglądaniu kodu IL, wygenerowanego z metody ConfigureHowToFindSaga. F# generuje dodatkowe wpisy w IL stąd przy próbie kompilacji pojawiał się powyższy komunikat

Wielokrotnie już pisałem o sile oraz możliwościach NServiceBus’a i tak też było w tym przypadku. Szybki wgląd w dokumentację i okazało się, że można zmienić domyślnie zachowanie, wskazując jawnie, który element ma pełnić rolę koordynatora. Służy do tego atrybut [SqlSaga]. Użycie w F# wygląda tak:

[<SqlSaga(nameof Unchecked.defaultof<PolicyData>.CommentId)>]
type CommentRegistrationPolicy() =
    ...

Dokumentacja wskazuje o stosowaniu tej konstrukcji w sytuacjach niestandardowych. Połączenie NServiceBus’a z F# można uznać za taką sytuację ;)

Endpoint Common

Następnym elementem do zmiany był Endpoint Common, którego intencją jest współdzielenie podstawowej konfiguracji, pomiędzy wszystkimi Endpoint’ami.

Multiple Message Conventions

Ponownie, w trakcie zmiany C# na F#, skorzystałem z jednej z nowości NServiceBus’a - Multiple Message Conventions.

Po przepisaniu kodu jeden do jeden, konfiguracja konwencji wyglądała tak:

let conventions = endpointConfiguration.Conventions()
conventions.DefiningCommandsAs(fun t -> t.Namespace <> null && t.Namespace.EndsWith("Commands") || t.IsAssignableFrom(typeof<ICommand>)) |> ignore
conventions.DefiningEventsAs(fun t -> t.Namespace <> null && t.Namespace.EndsWith("Events") || t.IsAssignableFrom(typeof<IEvent>)) |> ignore
conventions.DefiningMessagesAs(fun t -> t.Namespace <> null && t.Namespace.EndsWith("Messages") || t.IsAssignableFrom(typeof<IMessage>) || t = typeof<NServiceBus.Mailer.MailMessage>) |> ignore

Ze względu na to, że klasa NServiceBus.Mailer.MailMessage korzysta z domyślnej konwencji NServiceBusa, trzeba było ją zachować, używając dodatkowego warunku ||.

Nowy sposób pozwala dodawać własne konwencje do już istniejących:

let conventions = endpointConfiguration.Conventions()
conventions.Add(
    { new IMessageConvention with
        member this.Name = "Type name suffix"
        member this.IsCommandType(t) = t.Namespace <> null && t.Namespace.EndsWith("Commands")
        member this.IsEventType(t) = t.Namespace <> null && t.Namespace.EndsWith("Events")
        member this.IsMessageType(t) = t.Namespace <> null && t.Namespace.EndsWith("Messages")}) |> ignore

Metoda convention.Add przyjmuje w parametrze implementację interfejsu IMessageConvention.

Dzięki temu zniknęła konieczność jawnego definiowania konwencji dla NServiceBus.Mailer.MailMessage - uproszczenie.

Object Expressions

F# posiada bardzo fajną konstrukcję - Object Expressions. Dzięki niej można zakodować implementację interfejsu w miejscu jego użycia. Przydatne w sytuacjach, w których interfejs wykorzystywany jest tylko w jednym fragmencie kodu. Konfigurowanie konwencji dla Messge’y idealnie wpasowuje się w ten scenariusz, dlatego skorzystałem z tej konstrukcji przy ich definiowaniu.

Testy

Ostatnim, dużym fragmentem do dostosowania były testy jednostkowe oraz integracyjne. W wersji C# wszystkie zależności były dostarczane przez interfejsy, dzięki czemu w testach można było wstrzykiwać fake’owe implementacje. F# obsługuje interfejsy i mogłem pójść tą samą ścieżką, ale chciałem sprawdzić, czy można osiągnąć podobny efekt, korzystając z konstrukcji funkcyjnych :)

wartości dostarczane przez jeden z dostępnych typów danych: simple, tuple, record, …
zachowania dostarczane przez funkcje

Efekt? Policy to klasa. Jak klasa, to można w niej definiować konstruktory. NServiceBus, przy tworzeniu instancji Sagi wywołuje konstruktor bezparametrowy. Test może wołać dowolny konstruktor. Rozwiązaniem jest użycie dwóch konstruktów.

Przykład dla wartości:

type CommentAnswerNotificationPolicy(smtpFrom: string, blogDomainName: string) =
    ...
    new() = CommentAnswerNotificationPolicy(
                ConfigurationProvider.smtpFrom,
                ConfigurationProvider.blogDomainName)

Główny konstruktor przyjmuje dwa parametry typu string. Drugi konstruktor woła pierwszy, dostarczając wartości pobrane z konfiguracji.

Testy:

module PolicyTests =
    ...
    let getPolicy smtpFrom blogDomainName data =
            CommentAnswerNotificationPolicy(smtpFrom, blogDomainName, Data=data)
    ...
    [<Test>]
    let Handle_RegisterCommentNotification_FillProperPolicyData () =

        // Arrange
        ...
        let policyData = PolicyData()
        let policy = getPolicy "test@test.com" "sampleBlogDomainName" policyData
        ...

Funkcja getPolicy przyjmuje parametry smtpFrom, blogDomainName oraz data. Przekazuje je do konstruktora CommentAnswerNotificationPolicy. Parametr data podstawiany jest pod publiczne property Data. Test woła getPolicy, podstawiając odpowiednie wartości.

Przykład dla zachowania:

type GitHubPullRequestVerificationPolicy (checkPullRequestStatus: string -> string -> Async<ResponseCheckPullRequestStatus>) =
    new() = GitHubPullRequestVerificationPolicy(GitHub.checkPullRequestStatus)

Główny konstruktor przyjmuje funkcję, która zawiera dwa parametry typu string i zwraca, w sposób asynchroniczny, wartość ResponseCheckPullRequestStatus. Drugi konstruktor woła pierwszy, dostarczając implementację funkcji zgodną z oczekiwaną sygnaturą.

Testy:

module PolicyTests =
    ...
    let getPolicy() = GitHubPullRequestVerificationPolicy(fun _ _ -> async { return ResponseCheckPullRequestStatus(PullRequestStatus.Open, "ETag_123") })
    ...
    [<Test>]
    let Handle_RequestCheckPullRequestStatus_ProperResult () =

        // Arrange
        ...
        let policy = getPolicy () :> IHandleMessages<RequestCheckPullRequestStatus>
        ...

Funkcja getPolicy zwraca obiekt GitHubPullRequestVerificationPolicy. W parametrze konstruktora przekazuje funkcję lambda, symulującą zachowanie, które polega na zwróceniu statusu odpowiedzi na komentarz. Test woła getPolicy i rzutuje zwrócony wynik na odpowiedni typ.

Pozostałe zmiany dotyczyły usprawnień pracy z solucją oraz jej czyszczenie z nieużywanego kodu. Całą implementację wraz z historią zmian możesz podejrzeć na GitHub’e.

Podsumowanie

F# 5 pozwala programować NServiceBus Saga, w taki sam sposób, jak C#. NServiceBus 7.4 wprowadza usprawnienia, które ułatwiają realizację końcowego produktu. Z wielkiej czwórki ADSD, NServiceBus, C#, F# zrobiły się dwie, równoważne wielkie trójki:

ADSD, NServiceBus, C#
ADSD, NServiceBus, F#

Od tego momentu, jeśli dodajesz komentarz na tym blogu, to całość realizowana jest z wykorzystaniem ostatniej z nich :)

F# Bolero - A cóż to takiego? - remoting

2021-08-18T00:00:00+00:00

Posty z tej serii:

Aplikacja webowa składa się (w dużym uproszczeniu) z dwóch części:

Widoków
Danych, prezentowanych na widokach

Dane dla widoków możemy dostarczyć co najmniej na trzy sposoby:

Wołamy zewnętrzne API bezpośrednio z aplikacji
Tworzymy własne API, które dla aplikacji będzie punktem wejścia do wołania innych API
Mix dwóch powyższych

Tworząc własne API dla aplikacji pisanej w Bolero, możemy skorzystać z mechanizmu Remoting, który w mojej subiektywnej opinii posiada trzy bardzo fajne właściwości:

Szczegóły komunikacji między klientem a serwerem ukryte są pod warstwą abstrakcji
Ten sam sposób używania, niezależnie od tego, czy pobieramy, czy wysyłamy dane
Dwa wynikowe stany - udało się lub nie

W szczegółach, dane serilizowane są do formatu JSON oraz wymieniane przez protokół HTTP(s) z użyciem metody POST.

Zobaczmy, w jaki sposób możemy zaimplementować najprostsze API z jedną metodą, która zwraca tekst, a także, w jaki sposób możemy wywołać zaimplementowaną metodę.

Bolero Template umożliwia wygenerowanie kodu, gdzie serwer oraz klient skonfigurowani są w modelu hosted. My zrealizujemy scenariusz, w którym klient oraz serwer hostowani są niezależnie od siebie.

Cały kod znajdziesz na GitHub’e.

Zacznijmy od utworzenia trzech projektów:

kontrakty pomiędzy klientem, a serwerem - dll

dotnet new classlib -n Remoting.Contracts -lang f#
host serwera - ASP.NET Web API

dotnet new webapi -n Remoting.Server -lang f#
host klienta - Bolero minimal

dotnet new bolero-app -n Remoting.Client --minimal=true --server=false

Następnie, w projekcie Remoting.Contracts:

dodajemy paczkę Bolero

dotnet add package Bolero

usuwamy plik Library.fs
dodajemy plik SimpleService.fs z deklaracją API

module Remoting.Contracts

open Bolero.Remoting

type SimpleService =
    {
        GetHello: unit -> Async<string>
    }

    interface IRemoteService with
        member this.BasePath = "/simpleservice"

Record SimpleService zawiera pole GetHello, które reprezentuje metodę API. Wynikiem wywołania GetHello będzie zwrócenie przykładowego napisu. SimpleService dziedziczy po interfejsie IRemoteService z przestrzeni nazw Bolero.Remoting. Member this.BasePath wskazuje ścieżkę API. W ten sposób tworzymy deklarację, którą rozpozna Bolero.

Do projektu Remoting.Server:

dodajemy paczkę Bolero.Server

dotnet add package Bolero.Server

dodajemy referencję do projektu Remoting.Contracts:

dotnet add reference ../Remoting.Contracts

dodajemy plik SimpleServiceHandler.fs z implementacją API

namespace Remoting.Server

open Bolero.Remoting.Server
open Microsoft.AspNetCore.Hosting
open Remoting.Contracts
open Microsoft.Extensions.Primitives

type SimpleServiceHandler(ctx: IRemoteContext, env: IWebHostEnvironment) =
    inherit RemoteHandler<SimpleService>()

    override this.Handler =
        {
            GetHello = fun _ -> async {
                ctx.HttpContext.Response.Headers.Add("Access-Control-Allow-Origin", StringValues("*"))
                return "Hello from Simple Service!"
            }
        }

Klasa SimpleServiceHandler dziedziczy po klasie RemoteHandler z przestrzeni nazw Bolero.Remoting.Server. Pod Handler podstawiamy definicję metody API. Bolero umożliwia skorzystanie z dwóch zależności, dla których dostarcza implementacje: IRemoteContext oraz IWebHostEnvironment. W przykładzie pierwszą z nich wykorzystujemy, aby do odpowiedzi HTTP(s) dodać nagłówek Access-Control-Allow-Origin.

w pliku Startup.fs konfigurujemy ASP.NET Web API włączając Bolero Remoting oraz definiując CORS

type Startup(configuration: IConfiguration) =
    member _.Configuration = configuration

    // This method gets called by the runtime. Use this method to add services to the container.
    member _.ConfigureServices(services: IServiceCollection) =
        // Add framework services.
        services.AddControllers() |> ignore
        services.AddRemoting<SimpleServiceHandler>()
                .AddCors() |> ignore

    // This method gets called by the runtime. Use this method to configure the HTTP request pipeline.
    member _.Configure(app: IApplicationBuilder, env: IWebHostEnvironment) =
        if (env.IsDevelopment()) then
            app.UseDeveloperExceptionPage() |> ignore
        app.UseRemoting()
           .UseHttpsRedirection()
           .UseRouting()
           .UseAuthorization()
           .UseEndpoints(fun endpoints ->
                endpoints.MapControllers() |> ignore
            )
           .UseCors(fun policy ->
                policy.AllowAnyOrigin()
                      .AllowAnyMethod()
                      .AllowAnyHeader() |> ignore
             ) |> ignore

Remoting włączamy poprzez wywołanie metod:

services.AddControllers()
app.UseRemoting()

CORS definiujemy poprzez wywołanie metod:

services..AddCors()
app.UseCors(…)

W konfiguracji hosted CORS nie jest potrzebny, ponieważ zarówno serwer, jak i klient uruchamiane są z tej samej domeny.

Na koniec, w projekcie Remoting.Client:

dodajemy referencję do projektu Remoting.Contracts:

dotnet add reference ../../../Remoting.Contracts

w pliku Startup.fs, włączamy Bolero Remoting , podając bazowe URI pod którym dostępne jest API

builder.Services.AddRemoting((fun httpClient ->
    httpClient.BaseAddress <- Uri("http://localhost:1234"))) |> ignore

w pliku main.fs, realizujemy aplikację, które zawoła API za pomocą Elmish Commands:

Definiujemy model

type Model =
    {
        Text: string
    }

Ustawiamy początkowe wartości modelu

let initModel =
    {
        Text = ""
    }, Cmd.none

Nowością w stosunku do przykładów z poprzednich artykułów tej serii jest to, że wraz z wartościami modelu podajemy jaki Command ma się wykonać. W momencie inicjalizowania początkowych wartości nie wykonujemy żadnej akcji, oznaczając to przez Cmd.none

Definiujemy Messages

type Message =
    | GetHello
    | ShowHello of string
    | ShowError of exn

GetHello - zawołanie API
ShowHello - wykonanie działania, w przypadku, gdy API zwróci sukces
ShowError - wykonanie działania, w przypadku, gdy API zwróci błąd

Definiujemy funkcję update

let update simpleService message model =
    match message with
    | GetHello ->
        model, Cmd.OfAsync.either simpleService.GetHello () ShowHello ShowError
    | ShowHello text ->
        {model with Text = text}, Cmd.none
    | ShowError exn ->
        {model with Text = exn.Message}, Cmd.none

Oprócz standardowych parametrów message oraz model, funkcja przyjmuje parametr simpleService. Parametr jest typem SimpleService z projektu Remoting.Contracts. Po nadejściu Message’a GetHello wołamy API, za pomocą Command’a Cmd.OfAsync.either. W przypadku prawidłowego zakończenia wywołania zostanie zgłoszony Message ShowHello wpp. zostanie zgłoszony Message ShowError. Przy sukcesie wypełniamy model zwróconym rezultatem wpp. opisem błędu.

Definiujemy funkcję view

let view model dispatch =
    concat [
        div [] [
            button [on.click (fun _ -> dispatch GetHello)] [text "GetHello"]
        ]

        div [] [
            text model.Text
        ]
    ]

Widok zawiera dwa elementy:

przycisk z akcją on.Click, która wysyła Message GetHello
pole text, które wyświetla zawartość modelu

Na koniec zmieniamy inicjalizowanie głównego komponentu z mkSimple na mkProgram

type MyApp() =
    inherit ProgramComponent<Model, Message>()

    override this.Program =
        let simpleService = this.Remote<SimpleService>()
        Program.mkProgram (fun _ -> initModel) (update simpleService) view

W ten sposób wstrzykujemy klienta API do funkcji update oraz dostajemy możliwość używania Elmish Commands.

Koniec Serii

Tak, oto dotarliśmy do końca serii, która pokazuje podstawowe możliwości Bolero. Dzięki przedstawionym mechanizmom możemy tworzyć rozwiązania webowe w podejściu SPA, pisząc kod w języku F#.

Bolero posiada o wiele więcej możliwości. Jest to jednak temat na osobną serię artykułów.

Jeśli chodzi o mnie, to zostaję przy frameworku. Pamiętam, jak pierwszy raz przeczytałem o jego koncepcjach i doznałem tego fajnego efektu “aha…ciekawe…”. Teraz kiedy znam Bolero trochę lepiej, nic się nie zmieniło :)

Kolejnym etapem rozwoju jest wymyślenie tematu na aplikację oraz jej realizacja. Efektami prac podzielę się na blogu, którego w dalszej perspektywie będę chciał przepisać właśnie w Bolero.

F# Bolero - A cóż to takiego? - routing - page models

2021-06-12T00:00:00+00:00

Posty z tej serii:

Bolero przetrzymuje stan, przez cały cykl życia aplikacji. Każda strona, symulowana za pomocą Routingu, ma dostęp do aktualnego stanu, co jest bardzo fajną właściwością. Poniższe nagranie pokazuje, jak to działa. Obserwuj dane, wprowadzane na każdej stronie:

Your browser does not support the video tag.

Korzystając z właściwości Page Models, możemy zaprogramować zachowanie, w którym, przy każdym wyświetlaniu strony, stan będzie ustawiany domyślnymi wartościami. Poniższe nagranie pokazuje, jak to działa. Ponownie, obserwuj dane, wprowadzane na każdej stronie:

Your browser does not support the video tag.

Zobaczmy, w jaki sposób możemy zrealizować powyższą funkcjonalność. Cały kod znajdziesz na GitHub’e.

Tworzymy plik main.html z poniższym kodem i umieszczamy w katalogu wwwroot:

Choose:
 href="${MainLink}">Main  
 href="${CounterLink}">Counter  
 href="${EnterValuesLink}">EnterValues  
 href="${ViewComponentsLink}">ViewComponents  
 />
${Body}

Holes zdefiniowane w atrybutach href reprezentują linki do poszczególnych stron. $Body reprezentuje zawartość aktualnie wyświetlanej strony.

Definiujemy Templates dla poszczególnych stron:

Counter - plik wwwroot/counter.html

Counter

     onclick="${Decrement}">-
    ${Value}
     onclick="${Increment}">+

EnterValues - plik wwwroot/entervalues.html

EnterValues

     type="text" bind="${EnterValue}"/>
    ${EnterValue}

ViewComponents - plik wwwroot/viewcomponents.html

ViewComponents

     type="text" bind="${ViewComponentValue}"/>
    ${ViewComponentValue}

Definiujemy model oraz stan początkowy dla poszczególnych stron:

type CounterModel =
    {
        value: int
    }

type EnterValuesModel =
    {
        value: string
    }

type ViewComponentsModel =
    {
        value: string
    }

let defaultModel = function
    | Main -> ()
    | Counter model -> Router.definePageModel model { value = 0 }
    | EnterValues model -> Router.definePageModel model { value = "" }
    | ViewComponents model -> Router.definePageModel model { value = "" }

Do zdefiniowania początkowego stanu wykorzystujemy funkcję Router.definePageModel

Modelujemy dostępne strony z odpowiednim Page Model:

type Page =
    | [<EndPoint "/">] Main
    | [<EndPoint "/counter">] Counter of PageModel<CounterModel>
    | [<EndPoint "/entervalues">] EnterValues of PageModel<EnterValuesModel>
    | [<EndPoint "/viewcomponents">] ViewComponents of PageModel<ViewComponentsModel>

Definiujemy główny model oraz ustawiamy stan początkowy dla całej aplikacji:

type Model =
    {
        page: Page
    }

let initModel =
    {
        page = Main
    }

Stan poszczególnych stron został przeniesiony do Page Models. Główny model aplikacji zawiera informację o dostępnych stronach.

Definiujemy Message dla poszczególnych akcji:

type Message =
    | SetPage of Page
    | Increment
    | Decrement
    | EnterValue of string
    | EnterViewComponentValue of string

Definiujemy Routing:

let router = Router.inferWithModel SetPage (fun m -> m.page) defaultModel

W zwykłym Routingu używamy funkcji Router.infer. W Routingu z modelem używamy funkcji Router.inferWithModel. Trzeci parametr funkcji przyjmuje definicję domyślnych wartości dla poszczególnych stron.

Definiujemy funkcję update:

let update message model =
    match message with
    | SetPage p -> { model with page = p }
    | Increment ->
        match model.page with
        | Counter pageModel -> { model with page = Counter { Model = { pageModel.Model with value = pageModel.Model.value + 1 } } }
        | _ -> model
    | Decrement ->
        match model.page with
        | Counter pageModel -> { model with page = Counter { Model = { pageModel.Model with value = pageModel.Model.value - 1 } } }
        | _ -> model
    | EnterValue value ->
        match model.page with
        | EnterValues pageModel -> { model with page = EnterValues { Model = { pageModel.Model with value = value } } }
        | _ -> model
    | EnterViewComponentValue value ->
        match model.page with
        | ViewComponents pageModel -> { model with page = ViewComponents { Model = { pageModel.Model with value = value } } }
        | _ -> model

W naszym przykładzie każdy Message może być wykonany na jednej, konkretnej stronie. W związku z tym, w pierwszej kolejności rozpoznajemy, czy jesteśmy na właściwej stronie - match model.page with - następnie wykonujemy logikę działania.

Parametr pageModel reprezentuje aktualny stan na stronie. Routing z Page Models zapewnia resetowanie stanu do wartości domyślnych, przy przechodzeniu pomiędzy stronami.

Definiujemy View Component:

type InputComponent() =
    inherit ElmishComponent<string, string>()

    override this.ShouldRender(oldModel, newModel) =
        oldModel <> newModel

    override this.View model dispatch =
        ViewComponentsTemplate()
            .ViewComponentValue(model, fun value -> dispatch value)
            .Elt()

Definiujemy funkcję view:

let view model dispatch =
    let main =
        MainTemplate()
            .MainLink(router.Link Main)
            .CounterLink(router.Link (Counter Router.noModel))
            .EnterValuesLink(router.Link (EnterValues Router.noModel))
            .ViewComponentsLink(router.Link (ViewComponents Router.noModel))

    let counter (pageModel: CounterModel) =
        CounterTemplate()
            .Value(string pageModel.value)
            .Increment(fun _ -> dispatch Increment)
            .Decrement(fun _ -> dispatch Decrement)

    let enterValues (pageModel: EnterValuesModel) =
        EnterValuesTemplate()
            .EnterValue(pageModel.value, fun value -> dispatch (EnterValue value))

    let viewComponents (pageModel: ViewComponentsModel) =
        ecomp<InputComponent, _, _> [] pageModel.value (fun value -> dispatch (EnterViewComponentValue value))

    match model.page with
    | Main ->
        main.Body("").Elt()
    | Counter pageModel ->
        main.Body((counter pageModel.Model).Elt()).Elt()
    | EnterValues pageModel ->
        main.Body((enterValues pageModel.Model).Elt()).Elt()
    | ViewComponents pageModel->
        main.Body((viewComponents pageModel.Model)).Elt()

Podobnie, jak w przypadku funkcji update, w pierwszej kolejności musimy rozpoznać, która strona ma być wyświetlona - match model.page with. Pomocnicze funkcje counter, enterValues oraz viewComponents renderują odpowiedni HTML Template. Każda funkcja przyjmuje w parametrze model, należący do danej strony. Wartości modelu wstawiane są w odpowiednie Holes.

Na koniec definiujemy start aplikacji:

type MyApp() =
    inherit ProgramComponent<Model, Message>()

    override this.Program =
        Program.mkSimple (fun _ -> initModel) update view
        |> Program.withRouter router

To tyle, jeśli chodzi o programowanie w Bolero z użyciem Page Models.

Poznane do tej pory właściwości, pozwalają programować tzw. Frontend. Okazuje się, że Bolero posiada dodatkową cechę zwaną Remoting, która pozwala kodować punkt wejścia do Backendu. Przyjrzymy się temu w następnym artykule.

F# Bolero - A cóż to takiego? - routing

2021-04-11T00:00:00+00:00

Posty z tej serii:

Wspólną cechą omawianych do tej pory przykładów jest to, że dane wyświetlane są na jednej stronie. W rzeczywistości systemy webowe zawierają wiele stron. Adres aktualnie przeglądanej strony pokazywany jest w pasku przeglądarki internetowej. W Bolero taki efekt można uzyskać, wykorzystując mechanizm o nazwie Routing.

Bolero nie definiuje pojęcia strony. Mamy do dyspozycji widok, który sami musimy zaprojektować pod wymagane potrzeby. Weźmy dla przykładu aplikację, która zawiera trzy przyciski:

Counter
EnterValues
ViewComponents

Po kliknięciu odpowiedniego przycisku, widok powinien pokazać jedną z funkcjonalności omawianych w poprzednich artykułach. Taki efekt możemy uzyskać, modelując kliknięty przycisk, a następnie na podstawie wartości modelu, wyświetlić prawidłowy HTML template. W ostateczności widok będzie się zmieniał, ale adres w pasku przeglądarki pozostanie ten sam. Dla uproszczenia poniższy przykład wyświetla prosty napis załadowanej funkcjonalności:

Jeśli chcemy, aby każdy z wyświetlanych widoków posiadał swój unikalny adres, wyświetlany w pasku przeglądarki, musimy skorzystać z mechanizmu Routing’u.

Zaprojektujmy oraz zaprogramujmy taki efekt. Zamienimy jedną rzecz w stosunku do powyższego przykładu - zamiast wyświetlać przyciski, wyświetlimy linki. Dzięki temu zobaczymy, w jaki sposób możemy skorzystać z jednej z właściwości Routing’u pozwalającej na pobranie adresu URL dla wybranej strony.

Kod opisanych przykładów znajdziesz na GitHub’e.

Końcowy wynik będzie wyglądał tak:

W pierwszym kroku tworzymy plik main.html z poniższym kodem i umieszczamy w katalogu wwwroot:

Choose:
 href="${MainLink}">Main  
 href="${CounterLink}">Counter  
 href="${EnterValuesLink}">EnterValues  
 href="${ViewComponentsLink}">ViewComponents  
 />
${Body}

Holes zdefiniowane w atrybutach href reprezentują linki do poszczególnych stron. $Body reprezentuje zawartość aktualnie wyświetlanej strony.

Definiujemy proste Templates dla poszczególnych stron:

Counter - plik wwwroot/counter.html

Counter

EnterValues - plik wwwroot/entervalues.html

EnterValues

ViewComponents - plik wwwroot/viewcomponents.html

ViewComponents

Modelujemy dostępne strony oraz ustawiamy stronę startową:

type Page =
    | [<EndPoint "/">] Main
    | [<EndPoint "/counter">] Counter
    | [<EndPoint "/entervalues">] EnterValues
    | [<EndPoint "/viewcomponents">] ViewComponents

type Model =
    {
        page: Page
    }

let initModel =
    {
        page = Main
    }

Union Type Page reprezentuje strony. Atrybut EntryPoint pozwala konstruować wzorce dla ścieżki URL. Przykładowo definicja [] wymagałby podania w URL id licznika. W naszym przykładzie nie są wymagane żadne parametry. W takim przypadku można pominąć atrybut EntryPoint, ale zostawiamy go dla lepszej czytelności.

Główną stroną jest strona, która nie wyświetla nic (patrz screen powyżej).

Definiujemy message, który będzie ustawiał stronę:

type Message =
    | SetPage of Page

Definiujemy logikę funkcji update, która zaktualizuje stan o wybraną stronę:

let update message model =
    match message with
    | SetPage p -> { model with page = p }

Definiujemy Type Templates dla stron:

type MainTemplate = Template<"wwwroot/main.html">
type CounterTemplate = Template<"wwwroot/counter.html">
type EnterValuesTemplate = Template<"wwwroot/entervalues.html">
type ViewComponentsTemplate = Template<"wwwroot/viewcomponents.html">

Definiujemy funkcję view, która wyświetli widok w zależności od stanu modelu:

let view model dispatch =
    let main =
        MainTemplate()
            .MainLink(router.Link Main)
            .CounterLink(router.Link Counter)
            .EnterValuesLink(router.Link EnterValues)
            .ViewComponentsLink(router.Link ViewComponents)

    match model.page with
    | Main ->
        main.Body("").Elt()
    | Counter ->
        main.Body(CounterTemplate().Elt()).Elt()
    | EnterValues ->
        main.Body(EnterValuesTemplate().Elt()).Elt()
    | ViewComponents ->
        main.Body(ViewComponentsTemplate().Elt()).Elt()

Pomocnicza funkcja main zwraca reprezentację strony głównej. W miejsce Body wstawiamy zawartość, w zależności od tego, jaki link został kliknięty lub jaki adres został podany w przeglądarce.

W przykładzie widzimy, że link do strony generowany jest przez member router.Link przyjmujący w parametrze wartość modelu Page. Definicja value router wygląda tak:

let router = Router.infer SetPage (fun m -> m.page)

Funkcja infer z modułu Router, należącego do Bolero, zwraca konfigurację Routing’u bazując na message, który ustawia stronę oraz na modelu reprezentującym stronę.

To samo value wykorzystujemy, aby poinstruować całą aplikację o zdefiniowanym Routing’u, wołając Program.withRouter router:

type MyApp() =
    inherit ProgramComponent<Model, Message>()

    override this.Program =
        Program.mkSimple (fun _ -> initModel) update view
        |> Program.withRouter router

W taki sposób można wykorzystać Bolero Routing do symulowania funkcjonalności przechodzenia pomiędzy stronami systemu webowego.

Mechanizm Routing’u zawiera właściwość Page Models, która pozwala zamodelować stan dla konkretnej strony. Zajmiemy się tym tematem w następnym artykule.

Anonymous

Great post. Thank you :)

2021-05-06 00:20 UTC

mikedevbo

Thank you very much :)

2021-05-06 03:54 UTC

F# Bolero - A cóż to takiego? - view components

2021-02-28T00:00:00+00:00

Posty z tej serii:

W procesie rozwijania oprogramowania czasami trzeba zatrzymać dorabianie nowych funkcjonalności, ponieważ istotne stają się kwestie wydajnościowe. System działał w akceptowalny sposób i nagle zaczął działać wolniej. W takim przypadku poszukiwane są miejsca, które sprawiają problemy. Zdarza się, że rozwiązanie dostarcza technologia, której używamy.

Bolero posiada mechanizm View Components pozwalający optymalizować renderowanie widoku. Przy każdej aktualizacji Bolero porównuje cały widok i odświeża zmienione elementy. Porównywane są również te elementy, które nie uległy zmianie. Zajmuje to pewną jednostkę obliczeniową. Mechanizm View Components pozwala definiować, kiedy poszczególne elementy mają być porównane i odświeżone. W ten sposób skracany jest czas renderowania całego widoku.

Zobaczmy, jak to działa na przykładzie. Tym razem zacznijmy od efektu końcowego:

Pierwszy trzy elementy Nickname, Website oraz Sport renderowane są zawsze, niezależnie od tego, w którym polu tekstowym wprowadzono zmianę. Aktualizacja nastąpiła w tej samej sekundzie i prawie w tej same milisekundzie- element Last Update.

Kolejne trzy elementy Nickname, Website oraz Sport zrealizowane są z użyciem View Components. Każdy z elementów renderuje się tylko wtedy, kiedy wprowadzono zmianę w przypisanym do niego polu tekstowym. Aktualizacje nastąpiły w różnych sekundach i milisekundach - element Last Update.

Zobaczymy, w jaki sposób można zaprogramować View Components. Cały kod znajdziesz na GitHub’e.

Tworzymy plik vieComponents.html z poniższym kodem i umieszczamy w katalogu wwwroot:

No Components
${NickNameInput}
${WebsiteInput}
${SportInput}
 />
View Components
${NickNameInputComp}
${WebsiteInputComp}
${SportInputComp}

 id="InputValue">
    
        ${Label}:  type="text" bind="${Value}"/>
        Last Update: ${ValueRenderDate}

Wykorzystujemy poznane w poprzedniej część HTML Templates.

Definiujemy konwencję nazewniczą wg, której wszystkie elementy z końcówką Comp reprezentują części związane z View Components.

W pliku Main.fs programujemy logikę działania:

Model:

type Model =
    {
        Nickname: string
        Website: string
        Sport: string
        NicknameComp: string
        WebsiteComp: string
        SportComp: string
    }

Wszystkie wartości typu string.

Init Model:

let initModel =
    {
        Nickname = ""
        Website = ""
        Sport = ""
        NicknameComp = ""
        WebsiteComp = ""
        SportComp = ""
    }

Na początku nic nie jest wprowadzone/wyświetlane.

Message:

type Message =
    | SetNickname of string
    | SetWebsite of string
    | SetSport of string
    | SetNicknameComp of string
    | SetWebsiteComp of string
    | SetSportComp of string

Każdy element aktualizowany jest osobno.

Update:

let update message model =
    match message with
    | SetNickname value -> {model with Nickname = value}
    | SetWebsite value -> {model with Website = value}
    | SetSport value -> {model with Sport = value}
    | SetNicknameComp value -> {model with NicknameComp = value}
    | SetWebsiteComp value -> {model with WebsiteComp = value}
    | SetSportComp value -> {model with SportComp = value}

Aktualizacja poszczególnych elementów modelu.

Template + elementy pomocnicze:

type ViewComponents = Template<"wwwroot/viewComponents.html">

let NicknameLabel = "Nickname"
let WebsiteLabel = "Website"
let SportLabel = "Sport"

let viewInput (label:string) value setValue =
    ViewComponents.InputValue()
        .Label(label)
        .Value(value, fun vp -> setValue vp)
        .ValueRenderDate(DateTime.Now.ToString("ss.ffff"))
        .Elt()

ViewComponents reprezentuje Template. Definiujemy pomocne labels oraz funkcję viewInput, która renderuje poszczególne elementy widoku. Konkretne wartości przekazywane są w parametrach funkcji. Pokazywany jest również punkt w czasie (w sekundach i milisekundach), w którym nastąpiło renderowanie widoku.

To jest cała istota programowania funkcyjnego - dziel elementy na małe funkcje i składaj je w jedną działającą całość :)

Definicja View Components:

type InputComponentModel = { label: string; value: string }

type InputComponent() =
    inherit ElmishComponent<InputComponentModel, string>()

    override this.ShouldRender(oldModel, newModel) =
        oldModel.value <> newModel.value

    override this.View model dispatch =
        viewInput model.label model.value dispatch

View Component zazwyczaj przyjmuje tylko część z całego modelu. W naszym przypadku model reprezentowany jest przez InputComponentModel, który zawiera label oraz value.

View Component tworzymy przez dziedziczenie po klasie ElmishComponent podając w parametrach generycznych model type oraz message type. W naszym przypadku są to InputComponentModel oraz string. Sam komponent nazywamy InputComponent.

W metodzie ShouldRender określamy, kiedy komponent powinien odświeżyć swój widok. W naszym przypadku jest to moment, kiedy następuje zmiana wartości value.

Metoda View odświeża widok. W naszym przypadku wykorzystujemy wcześniej utworzoną funkcję viewInput.

Renderowanie całego widoku:

let view model dispatch =
    ViewComponents()
        .NickNameInput(viewInput NicknameLabel model.Nickname (fun value -> dispatch (SetNickname value)))
        .WebsiteInput(viewInput WebsiteLabel model.Website (fun value -> dispatch (SetWebsite value)))
        .SportInput(viewInput SportLabel model.Sport (fun value -> dispatch (SetSport value)))
        .NickNameInputComp(ecomp<InputComponent, _, _> [] {label = NicknameLabel; value = model.NicknameComp} (fun value -> dispatch (SetNicknameComp value)))
        .WebsiteInputComp(ecomp<InputComponent, _, _> [] {label = WebsiteLabel; value = model.WebsiteComp} (fun value -> dispatch (SetWebsiteComp value)))
        .SportInputComp(ecomp<InputComponent, _, _> [] {label = SportLabel; value = model.SportComp} (fun value -> dispatch (SetSportComp value)))
        .Elt()

Instancję InputComponent tworzymy, wykorzystując, wbudowaną w Bolero, funkcję ecomp. W parametrach generycznych podajemy typ komponentu, a w parametrach funkcji model oraz funkcję dispatch, która zostanie wywołana w momencie wykonania akcji na komponencie.

W ten sposób możemy decydować, czy dany element widoku powinien być brany pod uwagę w momencie renderowania całości.

To tyle, jeśli chodzi o programowanie w Bolero z użyciem View Components. W następnym artykule sprawdzimy, jak działa mechanizm o nazwie Routing.

F# Bolero - A cóż to takiego? - HTML templates

2021-02-07T00:00:00+00:00

Posty z tej serii:

Konstruowanie elementów UI w kodzie F#. Czy jest to dobre podejście? Kiedy pierwszy raz zobaczyłem taką możliwość, pomyślałem - ciekawe, ale nie jestem do końca przekonany. Z jednej strony mamy wsparcie kompilatora, który pilnuje poprawności wyniku. Z drugiej strony, każda, nawet najmniejsza zmiana wymaga re-kompilacji całości. Z trzeciej strony, dla osób, które piszą backend, re-kompilacja po zmianie to norma. Z czwartej strony, nie da się podzielić pracy tak, aby projektowaniem UI oraz przygotowaniem prototypu zajmowały się osoby od projektowania, a programowaniem całości zajmowały się osoby od programowania. Wszystko jest w kodzie F#, więc wszystko trzeba zaprogramować. Na chwilę obecną nadal podchodzę z pewną rezerwą do takiego podejścia, ale nie skreślam całkowicie.

Bolero umożliwia także alternatywny sposób konstruowania elementów UI - za pomocą tzw. HTML Templates. Do realizacji używamy standardowych znaczników HTML, w których możemy zawrzeć tzw. Holes. Służą one jako łącznik pomiędzy kodem UI napisanym w HTML, a logiką napisaną w F#. Dzięki temu możemy wyświetlać dynamiczne elementy na stronie oraz pobierać informacje, wprowadzane w formularzach. Nazywa się to bindowaniem danych. Możemy również wydzielać powtarzalne części za pomocą tzw. Nested Templates.

Zobaczmy, na przykładach, jak to wszystko działa.

Całą implementację znajdziesz na GitHub’e.

Simple Counter

W poprzedniej części stworzyliśmy prosty licznik, przesuwający wartość w dwie strony. Zamienimy kod renderujący widok tak, aby używał HTML Templates.

Tworzymy plik counter.html z poniższym kodem i umieszczamy w katalogu wwwroot:


     onclick="${Decrement}">-
    ${Value}
     onclick="${Increment}">+


     onclick="${Reset}">Reset

Między znacznikami HTML znajdują się Holes ${Decrement}, ${Value}, ${Increment} oraz ${Reset} pod które podstawimy wartości w kodzie F#.

W pliku Main.fs definiujemy typ, który będzie reprezentował Template:

type Counter = Template<"wwwroot/counter.html">

Zamieniamy definicję funkcji view z:

let view model dispatch =
    concat [
        div [] [
            button [on.click (fun _ -> dispatch Decrement)] [text "-"]
            text (string model.value)
            button [on.click (fun _ -> dispatch Increment)] [text "+"]
        ]

        div [] [
            button [on.click (fun _ -> dispatch Reset)] [text "Reset"]
        ]
    ]

na:

let view model dispatch =
    Counter()
        .Decrement(fun _ -> dispatch Decrement)
        .Value(string model.value)
        .Increment(fun _ -> dispatch Increment)
        .Reset(fun _ -> dispatch Reset)
        .Elt()

Konstruktor Counter() inicjalizuje Template. Bolero rozpoznaje Holes zdefiniowane w pliku counter.html. Dla każdego tworzy odpowiednik w postaci metody z taką samą nazwą oraz pasującą sygnaturą. W ten sposób możemy zakodować zachowanie programu:

Decrement, Increment oraz Reset reprezentują kliknięcie odpowiedniego przycisku na stronie
Value reprezentuje wyświetlaną wartość licznika
Elt jest wewnętrzną metodą Bolero, która konwertuje całą definicję do końcowego typu

Wszystko jest silnie typowane. Mamy pełne wsparcie kompilatora oraz podpowiadanie składni. W JetBrains Rider wygląda to tak:

Stan licznika wyświetlamy, wołając metodę Value. Do parametru metody przekazujemy wartość model.value, skonwertowaną z typu int - taki przechowujemy w modelu, na typ string - takiego spodziewa się metoda. Służy do tego operator o nazwie string.

Zachowanie kodujemy, wykorzystując funkcję dispatch, której podajemy odpowiedni Message reprezentujący konkretną akcję.

A jak działa bindowanie? Sprawdźmy to, dodając do licznika funkcjonalność ustawiania liczby, która będzie wskazywać, o ile licznik ma się przesuwać.

Rozszerzamy counter.html o możliwość wprowadzenia wartości:


    
        Step:  type="text"  bind="${Step}" onkeydown="${KeyDown}" />
        Key: ${Key} - Key Code: ${KeyCode}

Atrybut bind łączy wartość znacznika input z Hole ${Step}. Przykład zawiera dodatkową funkcjonalność - wyświetlenie informacji o naciśniętym klawiszu - Holes ${KeyDown}, ${Key} oraz ${KeyCode}

Rozszerzamy model dodając elementy step, key oraz keyCode:

type Model =
    {
        // whole code you can see on GitHub
        // ...
        step: int
        key: string
        keyCode: string        
    }

Ustawiamy wartości początkowe initModel:

let initModel =
    {
        // whole code you can see on GitHub
        // ...
        step = 1
        key = ""
        keyCode = ""
    }

Dodajemy Message’e:

type Message =
    // whole code you can see on GitHub
    // ...
    | SetStep of int
    | KeyDown of string * string

SetStep - wysyłany w momencie wprowadzania nowej wartości przesunięcia licznika - wartość podawana w parametrze typu int

KeyDown - wysyłany w momencie naciśnięcia klawisza na klawiaturze - klawisz oraz jego kod podawane w parametrze typu string * string - Tuple

Aktualizujemy funkcję update:

let update message model =
    match message with
    | Increment -> { model with value = model.value + model.step }
    | Decrement -> { model with value = model.value - model.step }
    | Reset -> { model with value = 0; step = 1 }
    | SetStep step -> { model with step = step }
    | KeyDown (key, keyCode) -> { model with key = key; keyCode = keyCode }

Licznik przesuwany jest o wartość, zapamiętaną w model.step. Reset ustawia step na wartość początkową. SetStep ustawia wartość przesunięcia, a KeyDown informacje o naciśniętym klawiszu.

Rozszerzamy funkcję view:

let view model dispatch =
    // whole code you can see on GitHub
    // ...
    .Step(string model.step, fun inputStep ->
        match System.Int32.TryParse inputStep with
        | true, step -> dispatch (SetStep (step))
        | false, _ -> ())
    .Key(model.key)
    .KeyCode(model.keyCode)
    .KeyDown(fun key -> dispatch (KeyDown (key.Key, key.Code)))
    .Elt()

Metoda Step wyśle Message aktualizujący wartość przesunięcia tylko wtedy, kiedy wprowadzony napis jest liczbą. W tym miejscu powinna być pełna walidacja, ale dla uproszczenia pomijamy ten element. Metody Key oraz KeyCode wyświetlają informacje o klawiszu. Metoda KeyDown wysyła Message aktualizujący informacje o naciśniętym klawiszu. Tak jak w poprzednim przykładzie, tak i tu, wszystko jest silnie typowane i wspierane przez kompilator F#.

Ostatecznie otrzymujemy program:

Zobaczmy kolejny przykład.

Enter Values

W sytuacji, kiedy pewne elementy zawierają tę samą strukturę kodu HTML, ale różnią się wartościami, warto stworzyć dla nich re-używalny komponent. W Bolero możemy to zrobić, używając Nested Templates. Zobaczmy, jak to działa na przykładzie programu wyświetlającego wprowadzane napisy.

Definiujemy Template:


    Enter value and press ENTER:  type="text" bind-onchange="${NewValue}"/>
    Entered Values:
    ${EnteredValues}
     onclick="${ClearValues}">Clear


 id="ShowValue">
    
        ${Value}

Zasada działania jest taka sama jak w przykładzie z licznikiem - HTML + Holes:

${NewValue} - reprezentuje wprowadzaną wartość
${EnteredValues} - reprezentuje listę wprowadzonych wartości
${ClearValues} - reprezentuje naciśnięcie przycisku czyszczącego wprowadzone wartości

Nowością jest

Design Develop Test Deploy

2022 - Co było…Co jest…Co będzie…

Co było…

Co jest…

Design

Develop

Test

Deploy

Blog

Co będzie…

ADSD - NServiceBus - C# - F# - Reloaded

Host

Policy

Saga Mapping

SQL Persistence

Endpoint Common

Multiple Message Conventions

Object Expressions

Testy

Podsumowanie

F# Bolero - A cóż to takiego? - remoting

Koniec Serii

F# Bolero - A cóż to takiego? - routing - page models

F# Bolero - A cóż to takiego? - routing

F# Bolero - A cóż to takiego? - view components

No Components

View Components

F# Bolero - A cóż to takiego? - HTML templates

Simple Counter

Enter Values

Hot Reloading

F# Bolero - A cóż to takiego? - wprowadzenie

Simple Program

Klasa MyApp

Funkcja view

Funkcja update

Discriminated Union Message

Value initModel

Record Model

Simple Counter

Początek Serii

2021 - Co było…Co jest…Co będzie…

Co było…

Co jest…

Design

Develop

Test

Deploy

DDTD

Blog

Co będzie…

F# 5 - NServiceBus Saga - idealne dopasowanie

NServiceBus Saga - F# 4

NServiceBus Saga - F# 5