Generalize RemoteData for PUT, POST and DELETE

gyzerok commented 7 years ago

Hi @krisajenkins!

First of all thank you for such a great concept and library. It makes it so much better to work with over http data using your library!

Recently I was using RemoteData to represent state of a POST request in my forms. The reason for that is that I need same 4 states which do not fit in just Result or Maybe Result.

This use case led me to thought that there could be a better, more generic names for RemoteData and it's labels. Currently names heavily imply usage alongside GET requests. Which makes code a bit misleading if it is used for POST/PUT.

Let's take a look on the example. Let's say we have a login form. Then we can model it this way:

type alias Model =
    { username : String
    , password : String
    , requestState : RemoteData.WebData ()
    }

init : Model
init =
    { username : ""
    , password : ""
    , requestState = RemoteData.NotAsked
    }

It is working nicely this way. Now we are able to understand in which state our request is and show spinner/error/nothing based on what our requestState is.

However it starts looking a bit weird since we are not talking abount any "data" here per say. We are only interested in the request state.

Specifically names NotAsked, Loading and RemoteData feels misleading to me in this scenario. I don't ask any data and thus it is not loading, but rather request is processing.

So rough example would be type RemoteRequest = NotSent | Processing | Failed | Succeeded feels a bit more correct. Of course names are subject to discussion. The point is - do you feel that this can make sense to do?

Note

If other folks are planing to participate in this discusson, please, omit naming suggestions. The purpose is first of all to discuss general idea and if it's worth making proposed changes. Naming is a subject for separate discussion.

krisajenkins commented 7 years ago

To my way of thinking, you are interested in the response here. You send something to the server, and you don't really care about the request except in so far as you must have a request to get a response.

For your use case, technically the response you're interested in is 200 (or 201). But any successful response will make you happy.

Where the confusion comes is that there's not really a payload with the Success. There's no data - merely a successful response is sufficient.

In those cases, I'm perfectly happy to use Success (). The meaning of that is clear to me. (It's probably a 201, if the backend developer is committed to the REST spec.) However, on some projects I've done this to make it more explicit:

-- Create an ACK type, with only one constructor:
type Acknowledgement = Acknowledgement

-- Create your form:
type alias Model =
    { username : String
    , password : String
    , requestState : WebData Acknowledgement
    }

-- Fetch the data:
login url payload = Http.post url payload (Decode.succeed Acknowledgement)

When the login succeeds you'll get Success Acknowledgement. It's totally equivalent to Success () but more self-documenting.

So I think this fits the login-response tracking just fine. I'm happy with the names as they are. :-)

gyzerok commented 7 years ago

Ok, I see your point, thanks for response.

krisajenkins / remotedata

Generalize RemoteData for PUT, POST and DELETE #18

Note