Hi everyone.

 I have been writing (mostly for myself !) a series of articles about Elm.
The overall goal is to implement an app to create "Tail end" diagram, 
similar to those found on the excellent blog waitbutwhy.com.

The first part of the series is available here 
<https://phtrivier.github.io/2016/08/21/elm-tail-end-part-1.html>, but I 
would like to have your opinion about how to improve the last part : 

https://phtrivier.github.io/2017/02/04/elm-tail-end-part-4.html

I am in a state where my page has two main parts :


   - a couple of inputs where you type your age, and how long you expect to 
   live. That defines the "period" that the tail end represents.
   - an actual view of the period.


In terms of Elm code, I now have :

* a model that contains the values of the input fields

type alias Model =
    { age : String
    , expected : String
    }



* an 'inputs' view functions that displays the model string values

inputs : Model -> Html Msg
inputs model =
    div []
        [ input
            [ placeholder "Age"
            , value model.age
            , onInput ChangeAge
            ]
            []
        , input
            [ placeholder "Expected"
            , value model.expected
            , onInput ChangeExpected
            ]
            []
        ]



* simple Actions to change the values

update : Msg -> Model -> ( Model, Cmd Msg )
update action model =
    case action of
        Start ->
            ( model, Cmd.none )

        ChangeAge a ->
            ( { model | age = a }, Cmd.none )

        ChangeExpected e ->
            ( { model | expected = e }, Cmd.none )




* some code to convert those raw inputs into a valid "Period" type

type alias Period =
    { age : Int
    , expected : Int
    }

type PeriodError
    = InvalidValues
    | InvalidAge
    | InvalidExpected
    | InvalidRange

toPeriod : Model -> Result PeriodError Period
...




* a view function that displays a proper Period

periodView : Period -> HtmlMsg



At this point, I would like refactor things (because my app is starting to 
get too big.)
Coming from a 'Component' mindset, I initially wanted to create a 
'PeriodPicker' component, that would 'own' the two string fields,
the ChangeAge / ChangeExpected actions, and the validation.

However, reading the Elm Guide here, it seems that it would not be a good 
idea : https://guide.elm-lang.org/reuse/

If you are coming from JavaScript, you are probably wondering “where are my 
> reusable components?” and “how do I do parent-child communication between 
> them?” A great deal of time and effort is spent on these questions in 
> JavaScript, but it just works different in Elm. *We do not think in terms 
> of reusable components.* Instead, we focus on reusable *functions*. It is 
> a functional language after all
>


Also, I don't really see how you can 'hide' the ChangeX actions and put 
them in a separate module, since the function that displays the inputs
must return the same (Html Msg) type as every other function in the 
application.

So what would the proper way to attack this refactoring ?


   - should I keep a Model with Strings ? Or should I create a type in a 
   'Period' module ?
   - should I keep all the actions in the global module ? Is there a way to 
   'split' the message type ?
   - should I try to factor the part of 'update' that deals with 'changing 
   inputs' into a separate module ?
   

The full code is available here : 
https://github.com/phtrivier/tailend/blob/part4/src/elm/Tailend.elm

Thanks for any advice !

-- 
You received this message because you are subscribed to the Google Groups "Elm 
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to