Make bugs into type errors

[choonkeat]

A few months ago, I asked this question (which I can’t find in Slack anymore):

Background: Lifecycle of a RemoteData.WebData

1. Set value as NotAsked initially
2. When making API call, set value as Loading
3. When API result comes back
   a. If error, set value as Failure
   b. If success, set value as Success

When firing off an API call, we need to anticipate which model fields are going to be affected and preemptively set them as RemoteData.Loading.

I find this wiring quite fragile. e.g. if I forget to set thing = RemoteData.Loading here, everything compiles. Or if update changes and now this API affects more/fewer fields, how do I remember to make corresponding updates in other places?

Is there a way to make this more robust?

My coworker jsegura and I recently stumbled upon this approach while recalling this dissatisfaction. Looking for feedback or better approaches

Make bugs into type errors

[berend]

This example is extremely artificial. The update for most people is simply:

 ResponseReceived response -> 
    ( { model | response = response }, Cmd.none )

so your artificial situation can’t even occur.

[choonkeat]

We use the remote data pattern a lot and sets up the loading indicator when firing off the request

+ RequestSent param -> 
+     ( {model | response = Loading }, sendRequest param )
  ResponseReceived response -> 
      ( { model | response = response }, Cmd.none )

We use GraphQL, and it’s not uncommon for 1 http request to be multiple queries; each updating different parts of the model

  ResponseReceived response -> 
      ( { model | thing = response.thing, categories = response.categories }, Cmd.none )

[berend]

Didn’t know about that GraphQL library, that’s brilliant. After using dillonkearns/elm-graphql I was looking for a way to write GraphQL in GraphQL.