Why not use: update fn state = fn state

Learn
21

I wrote:

The responses more than adequately answer my question. They allow me to take an informed decision regarding the msg or fn architectural question, in the app I intend to write.

I’ve little interest at this time in discussing the further question, as to which architecture is best. If you’d like to discuss that, I suggest you start a new topic.

Thank you everyone for your contributions. Not only have you answered my question, but you’ve also broadened my general appreciation and understanding of Elm and its wonderful community.

2 Likes
22

Elm + AWS Lambdas sounds really interesting @rupert. Do you (or anyone else) have write-up somewhere that I can check out?

23

Just this: GitHub - the-sett/elm-serverless-demo: Demo applications for elm-serverless.

1 Like
24

I have started doing something similar, but always chaining/applying so you do not need to start off with (model,Cmd.none) for each case:

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

                NoOp ->
                    identity

                SomeMsg pos -> 
                   doThingThing1 
                        >> doThing2 pos
                        >> doThing3
                ...
2 Likes
25

It is not quite the same thing.

The Debugger is presenting the use the state of the app. It is also presenting the user the previous states of the app and the messages responsible for the state transitions.

Because Elm is pure and the view is just a transformation of the Model, this allows the programmer to easier understand what happens. They can check the branch that handles the message, they can check the view functions that translate the model. Their investigations are very well located.

Once you put functions into messages you lose this locality. You’ll receive a generic and uninformative message UpdateModelUsingThisFunction (Model -> (Model, Cmd Msg)) and that function could come from anywhere. You will have to hunt for it and you will not have any information for your hunt. If the source code of the module is small that might be obvious but as the number of lines of code grows, things will get progressively more difficult. If you have 5 of these functions is one thing. If you have 60, it is a completely different thing.

1 Like
26

I get it, but this is a limitation of the debugging tool. In theory it wouldn’t be hard to tie some distinguishing information to named functions (lambdas are a different story).
Besides, I might not even care about this information; Message is still a separate type, it might just incorporate a function: instead of your example I would probably see something along the lines of ChangePageLanguage (Model -> (Model, Cmd Msg)). I don’t need to see the body of the function to know what it does - and while an explicit ChangePageLanguage Language would show me the parameter as well, it’s not that important.

In practice I don’t even use Elm’s debugging facilities. I am not even sure on how to use the time traveling debugger: it’s something I’ve been hearing about for years, but every time I try to get a grasp of how to use it my researches yield nothing.

1 Like
27

Well said. I have some ideas along these lines. When they are better thought out I’ll create a Request Feedback topic. In the meantime, I have an app to write.

My question has been well answered, so I’ll mark this issue as solved.

2 Likes
28

if you compile with --debug flag (i.e. elm make src/Main.elm --debug) , you will get the time traveling debugger in the lower right corner of your screen. To travel through time, just click in the history of your messages (on the left) and the app will revert to the state of that message. You can also import and export list.

2 Likes
29

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.