Http.send behavior

[smiley325]

From the mailing list:

Right now, the way Http.send works, the Waiting state only occurs for the first request. If the URL changes thereafter, it will maintain the previous Response until the new response comes in. I can see why that would be a useful behavior to have, especially if you hook up your output/views directly to the response signal.

In more stateful applications however, it would be useful to have a different Http.send (not sure what I would name it) which, when the URL changes, will revert to the Waiting state while waiting for the new response to come in. This would allow someone to have a loading animation be displayed whenever requests to the server are happening, so the user is aware that something is being waited on. In this style, if the programmer wants to display the old results while the new results are fetching, he can do that by storing results in his/her application state.

Jeff Smits added that under this new behavior, "you can do a dropIf ((==) Waiting) Waiting to get the old heaviour back." Whereas you cannot derive this new behavior from the old behavior.

Just wanted to put this suggestion out there for the next revision of Http. The change itself is just a single line swap in Native/Http.js

[evancz]

Oh, I thought I made it the way you described it should be. So maybe that's a bug?

Here's the thing though, I am redesigning this library right now, so the next release should be strictly better in a ton of different ways. I think this will be part of that. So the answer is sort of, everything's gonna be better soon.

[evancz]

Oh, I thought I made it the way you described it should be. So maybe that's a bug?

Here's the thing though, I am redesigning this library right now, so the next release should be strictly better in a ton of different ways. I think this will be part of that. So the answer is sort of, everything's gonna be better soon.

[smiley325]

Bug or not, I think at this point it is what it is, especially since you're redesigning now. Is there a design doc or some kind of notes to preview the new redesign? And how will the version bump look?

I have some rather garish offline/online caching stuff that depends heavily on Http, just wanted to make sure the semantics I chose are not overly dissonant from the new Http that's coming.

[smiley325]

Bug or not, I think at this point it is what it is, especially since you're redesigning now. Is there a design doc or some kind of notes to preview the new redesign? And how will the version bump look?

I have some rather garish offline/online caching stuff that depends heavily on Http, just wanted to make sure the semantics I chose are not overly dissonant from the new Http that's coming.

[evancz]

Still early stages, I'll share on the mailing list when there's something more solid. It should be possible to recreate the old API with it if you really want to.

[evancz]

Still early stages, I'll share on the mailing list when there's something more solid. It should be possible to recreate the old API with it if you really want to.

[evancz]

This stuff lives in evancz/elm-http now.

[evancz]

This stuff lives in evancz/elm-http now.