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 [email protected].
For more options, visit https://groups.google.com/d/optout.
