Cmd.OfFunc.whatever

[davedawkins]

Cmd.OfFunc.whatever

[davedawkins]

Perhaps this is what Cmd.ofEffect is for

[MangelMaxime]

In my project I often add a similar helpers and more.

The code is the same as yours just using the same structure as Elmish code base

I call it Cmd.OfFunc.exec:

module Elmish

open Elmish

module Cmd =

    module OfFunc =

        let exec
            (task: 'a -> _)
            (arg: 'a) : Cmd<'msg> =

            let bind _dispatch =
                try
                    task arg
                with x ->
                    ()

            [ bind ]

	// Other variants for Async, Promise, etc.

@et1975 We can probably add such variant to Elmish core what do you think?

[et1975]

if you don't care about either outcome, why bother involving elmish at all? Just invoke whatever you have yourself, no?

[davedawkins]

That wouldn't be executed after the model has been updated, and therefore the view etc.

[davedawkins]

To be clear - I'm working on Sutil's implementation of Elmish, and I don't want to introduce any new ideas into Sutil's Elmish that don't map back to ideas and concepts defined in this (master) repo. I'm saying this so you can judge the priority of the proposal accordingly.

[MangelMaxime]

I think I do it this way to have a similar looking code everywhere.

Like that all the "side effects" are triggered in the Cmd.XXX.YYY portion of the code.

It also happens after the model has been updated.

[et1975]

Those use-cases seem perfectly valid to me and you absolutely should have them supported in your prelude (library or application). But I think from conceptual/elmish perspective the commands are a way to feed results back into update loop. Which is why I don't think we should enshrine commands as something like delayed execution mechanism.

@kspeakman what's your take on this?

[kspeakman]

@et1975 TLDR; I agree with you to leave it out as not encouraged usage. It can be added in user space as needed.

I agree with @MangelMaxime that these side effects (ones triggered from update) belong as Cmds. In these rare cases, I typically dispatch a no-op return Msg. Logging for example. | Logged -> model, Cmd.none. That way I can see in the Msg log that it happened and the timing relative to other Msgs.

It is worth noting: Elm's internal API does not permit the usage in question.. A Task must return a single Msg.

Please feel free to poke holes in my reasoning, provide counter examples where these strategies are untenable, etc. If I'm missing something I would love to learn about it.

[kspeakman]

I can't help thinking that when one allows perform, attempt and Cmd.ofEffect, you have already prompted for the inclusion of Cmd.OfFunc.exec - they all ignore certain outcomes (mostly exceptions).

You make some good points. For context. The Cmd API permits not returning a msg. Which may make it appear that this is a good option. However, the choice of using dispatch is more of a pragmatic one. It's much easier to integrate with multiple UI platforms. There is another issue discussing ways to remove dispatch from the Elmish API without breaking the world. No solutions as yet.

I believe the fns you mentioned were inspired by Elm's Task API. The difference being that F# doesn't tightly restrict side effects as Elm does. Anything can throw. A safe default is for failing side effects to not crash the app. So all these fns wrap the provided fn in a try catch just in case.

To your point, this does change the semantic meaning of perform for example. In Elm it indicates "this can't fail" (which Elm enforces), but in F#/Elmish it effectively means "ignore failures". Which happens to make it suitable only for code that can't fail.