Fabulous: Naming of "Cmd"

[dsyme]

The Elmish framework use the name "Cmd" to mean _something that, when started, may asynchronously generate messages_.

There are issues with using "command" in the context of Xamarin.Forms programming (also WPF) because ICommand, Command etc. are used in Xaml/WPF/XF docs. I've also never really liked the name for these reasons, though I'm suspect Fable-Elmish people are ok with it.

I do wonder if we should find another name for this in the context of EXF, or simply not really have a name for it at all. In EXF samples people tend to make cmd values from

• Async<Msg> (Cmd.ofAsyncMsg)
• Async<Msg option> (Cmd.ofAsyncMsgOption)
• AsyncSeq<Msg> (used to be used but wanted to remove dependency on FSharp.Control.AsyncSeq)
• (I guess people could also use IObservable<Msg> and it would be basically equivalent)

Then also Cmd.batch to merge two commands together.

It's hard to rename though since likely all other good names are taken (action, process, async). Any thoughts?

[Zaid-Ajaj]

The name comes from the original Elm architecture, anyone who uses or has used Elm is already familiar with the concept of a “Cmd”, I don’t think it is a problem with WPF /XF because if you use Elmish, you don’t explicitly use IConmand anymore

[slang25]

Not having done much Elm, I have to say this was a head scratcher for me and my team to begin with, for some people message and commands are logically interchangeable.

My mental model is that a message can be either an event, or a command (explicitly side effecting), in which case the current name mostly makes sense. However it's not a message, it's an async event, so I was scratching my head. Now I know this, it's not a problem, I just tell myself Cmd = Async.

Being consistent with Elm and other Elmish terminology I would bet is important and may be worth keeping everything the way it is, I just wanted to share that your concerns around this is something that people are experiencing.

[TimLariviere]

I agree with @Zaid-Ajaj
ICommand/RelayCommand/etc do not exist in the "Dynamic" EXF world, as they are strongly related to MVVM.

Furthermore Cmd is a core concept of every Elmish apps, so even if new developers could get confused at the beginning, I think they will quickly learn to dissociate the two.
Being myself a WPF/Xamarin dev without prior knowledge of Elmish, I did not even think once that Cmd was anything like ICommand (just found odd that some properties are named command and expect a function).

Another important factor is that with Cmd, we benefit from the extensive docs and samples from Fable-Elmish/SAFE.
As an example, I directly copied the ExternalMsg mecanism from a SAFE sample.

Several people even asked if they could share the update logic between Fable-Elmish and EXF, which would only be possible if you keep the same naming.

I think keeping Cmd is better than just choosing another term which might be more obscur.

[dsyme]

Cool. Let's keep this open and keep collecting points of view. It can inform teaching (what order we teach concepts in and how we explain them) and perhaps naming.

There are a number of ways that EXF sits awkwardly in naming conventions, e.g. when you look at small EXF samples the Elmish-style abbreviated naming Cmd, mk and so on looks a little odd, poking out between more normal F# naming. In the end F# is F# and Elm is Elm and we should ultimately follow F# conventions for an F# framework. But it's not too bad, and core F# does embrace some use of abbreviated names (though the guidelines don't particularly encourage expanding on this)

I agree that the ability to share and learn from Fable-Elmish architectural coding patterns is really useful, ExtenalMsg being a good example

[dsyme]

I do tend to think of Command as something originating from the user.

I notice Facebook Flux (a similar architecture for web) uses the more neutral "Action" http://facebook.github.io/flux/docs/in-depth-overview.html#content

• Model = Store
• Command = Action
• View = View
• Update = Dispatcher

Action is not without its problems also

[Zaid-Ajaj]

⚠️ HEAD UPS, personal opinions coming ahead

@dsyme This will introduce many confusions:

• Action is used to constuct tagged events (eventName + payload) in Redux (what is called Msg in Elm)
  
  
  
  • Dispatcher is what sends the message to the runtime (the "dispatch loop") but update doesn't dispatch anything directly
  
  

I do tend to think of Command as something originating from the user.

This applies to messages coming (dispatched) from the view and you can call them "User commands", but in an Elm app, that is only one source of messages, you have subscribed messages, external messages, other custom messages etc.

I personally would prefere the name of Cmd stays the same in accordance with the Elm equivalent but If you really want to change Cmd, why not choose a name that reflects what a Cmd is? Here is a suggestion: I like to think of Command as a "Scheduled message dispatcher", the implementation of the command has control over a dispatch function (provided by the the runtime) and thus can decide when to send a message into the dispatch loop or do some other side effects that don't necessarily send messages:

let update msg state = 
  match msg with 
  | Increment -> { state with Count = state.Count + 1 }, Schedule.nothing() 
  | IncrementDelayed -> state, Schedule.msgAfterTimeout 1000 Increment

[rbrus]

I see Model as Model and View as View.

Command sounds correct to me, whereas Action on a first look sounds okay, however after a while, it confuses me what real is the action. Is it a command or is it an action called by control when ... and now question what and when?

Dispatcher sounds like a Subject (Rx) or network dispatcher (broker). Update is more intuitive to me, it must be method called when something - window is updated / refreshed, similar to win32 UpdateWindow.

I think I would be lost if those names would be changed to the others, at least to the one from flux :)

[dsyme]

I'm not necessarily looking for a change :) It's just that I'm always dissatisfied with having to explain "Cmd". Everything else in the model is so 100% intuitive - as soon as people read the code they get it.

Schedule is actually good, in the sense that the code Schedule.nothing, Schedule.msgAfter, Schedule.asyncMsg etc. is very clear. People will know exactly what that is doing (and know it is doing nothing more than it says). Perhaps that's partly because schedule can be both noun and verb in english and either interpretation here makes sense.

Again not saying we should change, just mentioning it as a problem (for Elmish in all its forms)