Do you have an opinion over which helps either you or your colleagues reason about your applications better?
Past tense: DetailsUpdated
Imperativ...
For further actions, you may consider blocking this person and/or reporting abuse
I personally use the imperative tense.
Since messages in Elm are a declarative, I feel it makes sense to name the action according to what it will do. It would feel strange seeing a past-tense name when reading the code which actually triggers an action.
vs
The string passed to
textin the second example would still be"Start Game"of course. But yes, that in itself is a good example of the trade-off being made if you're using past-tense for messages.Thanks for catching that. Fixed the code block.
I feel the same re: naming the action according to what it will do, for what it's worth. I'm just starting to wonder if perhaps it makes more sense to name them based on how they're used, you know what I mean?
By the time the application is processing the message, the message in question has already been sent by the user; so when you look at it in the debugging tools (in
debugmode of course), it feels like it makes more sense to be in past tense. Hmm...I get your point, but it's only in the dev tools or logs where that comes up.
Most of my time is spent reading the source code, so I optimize for that.
If a new person from your team reads your
.elmfile for the first time, the imperative message names make the intention of the code more clear.What might be neat is if the dev tools could accept a function that lets you translate Msg names to a "display name". Then you get the best of both styles.
I'm really thinking out loud here btw, rather than actively trying to convince you (or me) that this is a change worth making.
My approach:
GameStartedis a lie, andStartGameimplies that the view is somehow responsible for telling the update what to do. I prefer the view to be a pure description of the UI with messages describing what has happened. The view dispatches aStartGameClickedevent, which is purely factual, and the update is free to create a new model based on this in whatever way it wants to.I like the advice given in this talk,
and/or in this comment.