Elm Architecture is a pattern and it is very useful to understand the ideas
behind that pattern.

The way I view it is like this:
- MODEL : Keep the structure of information as simple as possible, data
only so it will be very easy for the view to use the `lazy` functions
- VIEW : use the simple data from the model, and update only the minimum
required using lazy functions
- UPDATE : transform the simple data of the model based on simple messages.
If you need to customize the transformation, extend the list of parameters
to the left (add customization information at the beginning so that it can
be curried away). If you need to communicate upwards, extend the return.
- SUBSCRIPTIONS : treat them as one would treat the drivers in an OS,
isolate as much as possible, push towards the exterior of the code.

This way, one has all the flexibility and composability in the world.
All the complexity related to "behavior" will be in the UPDATE section, all
complexity related to representation in the MODEL section and all
complexity related to layout and other visual appearance stuff in the VIEW
section.

This mirrors the way I think about the code and how I start to implement
it.
First the model of the data needed by the program, then the visual
representation, then the behavior (updating of the data) and lastly the
subscriptions (if the update section needs something from the outside
world).




On Tue, Jun 14, 2016 at 9:59 AM, 诺铁 <[email protected]> wrote:

> thank you peter, I understand your point and agree with it.
> and now I understand that Elm architecture is only restrict at the
> "application" level, that is , the "main" program.   at component level,
> it's very easy to adjust according to our own purpose.
>
>
> On Tue, Jun 14, 2016 at 2:36 PM, Peter Damoc <[email protected]> wrote:
>
>> Elm let's you do that and you can definitely treat functions as just
>> data.
>>
>> That being said, I would advise against it. Keep your Models as pure data
>> types.
>>
>> If you imagine dividing your code in three sections: Model, Update and
>> View, keep all your transformations  and all your Cmd related stuff  in
>> Update.
>>
>> You can add another parameter to update:
>>
>> -- UPDATE
>>
>> doThis : Model -> Cmd Msg
>> doThis = doThisStuff
>>
>> doThat : Model -> Cmd Msg
>> doThat = doThatStuff
>>
>> doNothing : Model -> Cmd Msg
>> doNothing = always Cmd.none
>>
>> update : (Model -> Cmd Msg) -> Msg -> Model -> (Model, Cmd Msg)
>> update cmd msg model =
>>     case msg of
>>         SomeMsg ->
>>             let
>>                 newModel = someRelevantUpdating model
>>             in
>>                 newModel ! [cmd newModel]
>>
>>
>> and call it in the parent like
>>
>> newChild = Child.update Child.doThis childMsg model.child
>>
>>
>> Of course, if you have more than one command you can use a Context record
>> to keep the commands .
>>
>> type alias Context =
>>     { primary : Model -> Cmd Msg
>>     , secondary : Model -> Cmd Msg
>>     }
>>
>> update : Context -> Msg -> Model -> (Model, Cmd Msg)
>> update ctx msg model =
>>     case msg of
>>         SomeMsg ->
>>             let
>>                 newModel = someRelevantUpdating model
>>             in
>>                 newModel ! [ctx.primary model]
>>
>>
>> Just keep you Models and Views as simple and as free from processing as
>> possible.
>>
>>
>>
>> On Mon, Jun 13, 2016 at 12:09 PM, 诺铁 <[email protected]> wrote:
>>
>>> for example, in the http example
>>> <https://github.com/evancz/elm-architecture-tutorial/blob/master/examples/5-http.elm>,
>>>  the
>>>>
>>>> getRandomGif : String -> Cmd Msg
>>>
>>> can be sent to init function as a parameter, then call this parameter
>>> function in the update function, this might make it easier to test update
>>> function, and totally separate the component from the program.
>>>
>>> --
>>> 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.
>>>
>>
>>
>>
>> --
>> There is NO FATE, we are the creators.
>> blog: http://damoc.ro/
>>
>> --
>> 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.
>>
>
> --
> 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.
>



-- 
There is NO FATE, we are the creators.
blog: http://damoc.ro/

-- 
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