Seems like this is trying to normalize operations to CRUD. I would be
careful of over-standardizing early. Because later you will likely have to
break those abstractions to implement new features. For example, the way I
would implement a Customer merge would not fit semantically into one of
those operations.
There are a few steps involved in creating a new code path to an API, but
most of it seems pretty reasonable. And there's nothing preventing you from
making helper functions if you find yourself repeating mostly the same code
for different calls.
On Tuesday, October 4, 2016 at 10:24:45 AM UTC-5, Rupert Smith wrote:
>
> On Friday, September 30, 2016 at 2:37:35 PM UTC+1, Rupert Smith wrote:
>>
>> Firstly, I define a set of call-back functions which will be notified
>> when REST operations complete:
>>
>> callbacks : Account.Service.Callbacks Model Msg
>> callbacks =
>> { findAll = accountList
>> , findByExample = accountList
>> , create = \account -> \model -> ( model, Cmd.none )
>> , retrieve = \account -> \model -> ( model, Cmd.none )
>> , update = \account -> \model -> ( model, Cmd.none )
>> , delete = \response -> \model -> ( model, Cmd.none )
>> , error = error
>> }
>>
>
> One addition I am making to this, is to define a default set of 'no
> action' callbacks in the service. Always -> ( model, Cmd.none). Then the
> consumer of the service just needs to override and specify which events
> they are interested in handling.
>
--
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.
