To anyone reading, I might have solved it myself : https://phtrivier.github.io/2017/02/05/elm-tail-end-part-5.html
Still, any comment is welcome ! Thanks Le samedi 4 février 2017 21:18:50 UTC+1, Pierre-Henri Trivier a écrit : > > 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.
