[elm-discuss] Re: How do you name messages?

2016-10-24 Thread Birowsky
Thanx for this discussion, fellas. I cannot fully digest it at the moment, 
but I'm sure I'll be coming back to this as I go.

-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[elm-discuss] Re: How do you name messages?

2016-10-22 Thread Lars Jacobsson

>
>
>
>
>- What is the system supposed to do: RegisterWithCredentials String 
>String
>- What happened in the system: ClickRegistrationSubmit String String / 
>TapRegistrationSubmit String String
>
>
> Let's have an argumented discussion around this :}
>

I think one of the main arguments for the *second* approach, is that you 
may want to reuse and action like "RegisterWithCredentials" in other 
messages. Hence it is better suited to be a regular function that can be 
reused. 

-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[elm-discuss] Re: How do you name messages?

2016-10-21 Thread Daniel Walker
Using past tense I think helps separate concerns. For example, switching 
from this:

   ClickRegistrationSubmit form ->
 let vErrors = validate form in
 vErrors 
|> Maybe.map (\ve -> update (ShowValidationErrors ve))
|> Maybe.withDefault (update (SubmitForm form))

to this:

   RegistrationAttempted form ->
let vErrors = validate form in
vErrors
   |> Maybe.map (\ve -> update (RegistrationValidationFailed ve))
   |> Maybe.withDefault (update (RegistrationValidationOK form))

The difference here is that this piece of code knows only that the 
validation failed, or it was OK. It ought to know nothing about what 
happens next. That is the responsibility of whoever is listening to these 
messages. Saying `ShowValidationErrors` potentially clashes with something 
else in the future when the requirements become more sophisticated (such as 
sending them to some log, or sending out a notification or whatever).

On Friday, October 21, 2016 at 10:47:35 AM UTC-6, art yerkes wrote:
>
> I'd be on board with using both:
>
> case action of
>...
>ClickRegistrationSubmit form ->
>   let vErrors = validate form in
>   vErrors 
> |> Maybe.map (\ve -> update (ShowValidationErrors ve))
> |> Maybe.withDefault (update (SubmitForm form))
>
> separates concerns and levels of abstraction
> each message has clear intent
> validation errors coming back from the server could follow the same path 
> as local validation errors
> SubmitForm doesn't need to decide whether to submit a form
>
> On Friday, October 21, 2016 at 7:56:04 AM UTC-7, Birowsky wrote:
>>
>> Well, they leaned towards the second approach. The reason was: *what if 
>> that action is not possible*. 
>>
>> What if on SubmitForm, instead of sending the registration form, the app 
>> would need to display validation errors? 
>>
>> I see that ambiguity. But from this perspective, it doesn't seem like a 
>> burden to me. 
>>
>> I would, however, like to know where do experienced elm devs lean on. 
>> Does the first approach cause ambiguity when working in a team?
>>
>>

-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[elm-discuss] Re: How do you name messages?

2016-10-21 Thread art yerkes
I'd be on board with using both:

case action of
   ...
   ClickRegistrationSubmit form ->
  let vErrors = validate form in
  vErrors 
|> Maybe.map (\ve -> update (ShowValidationErrors ve))
|> Maybe.withDefault (update (SubmitForm form))

separates concerns and levels of abstraction
each message has clear intent
validation errors coming back from the server could follow the same path as 
local validation errors
SubmitForm doesn't need to decide whether to submit a form

On Friday, October 21, 2016 at 7:56:04 AM UTC-7, Birowsky wrote:
>
> Well, they leaned towards the second approach. The reason was: *what if 
> that action is not possible*. 
>
> What if on SubmitForm, instead of sending the registration form, the app 
> would need to display validation errors? 
>
> I see that ambiguity. But from this perspective, it doesn't seem like a 
> burden to me. 
>
> I would, however, like to know where do experienced elm devs lean on. Does 
> the first approach cause ambiguity when working in a team?
>
>

-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[elm-discuss] Re: How do you name messages?

2016-10-21 Thread Birowsky
Well, they leaned towards the second approach. The reason was: *what if 
that action is not possible*. 

What if on SubmitForm, instead of sending the registration form, the app 
would need to display validation errors? 

I see that ambiguity. But from this perspective, it doesn't seem like a 
burden to me. 

I would, however, like to know where do experienced elm devs lean on. Does 
the first approach cause ambiguity when working in a team?

-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[elm-discuss] Re: How do you name messages?

2016-10-21 Thread Simone Vittori
Why not both?

Usually I find myself using the first approach more, especially when I have 
"actions" coming from the view (e.g. ChangeInput, SubmitForm).

However I also use the second approach when I get some value back from a 
task (e.g. ParsedInput, ReceivedData).

On Friday, 21 October 2016 09:10:34 UTC+1, Birowsky wrote:
>
> In the latest ElmTown episode they had this discussion, which seems like a 
> valid one, but i couldn't catch any good pro or con argument.
>
> So the two approaches are:
>
>
>- What is the system supposed to do: RegisterWithCredentials String 
>String
>- What happened in the system: ClickRegistrationSubmit String String / 
>TapRegistrationSubmit String String
>
>
> Let's have an argumented discussion around this :}
>

-- 
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.