HTTP driver one time request helper

@staltz you’ve been mentioning read only HTTP driver that could get just some URL for one time. I think such API could be extended with some helper method on response$$ for example request that would make one request without need to send request to the sink.

HTTP.request({url: ...., method: ....})
  .switch().

Is it aligned with read only driver idea and whole cycle approach?

[staltz]

@whitecolor @laszlokorte just a reminder, that the read-only HTTP driver modifications were just a suggestion. At best, at this stage we are just experimenting with ideas. This one is valid too, but as Laszlo pointed out, we need to look out for the side effects.

Because I’ve seen people confused was is actually a side effect in the context of Cycle.js, or even what is a read effect and what is a write effect, I’ll attempt to make that a bit more clear.

It all boils down to this: http://cycle.js.org/dialogue.html.

• Read effects are messages/events coming from the external world, into our app
• Write effects are messages/events from the app to the external world

It’s just async message passing between actors.

You need to define what is the “external world” and what is the “application”. It’s pretty clear that graphics and mouse inputs are from the external world, but so is a server (in relation to a client app). Other not-so-obvious distinctions are e.g. storage. It’s not actually external to the computer, but it is external to the application, so we can consider it part of the external world.

On the other hand, we don’t in Cycle.js consider e.g. the memory heap as part of the external world. That’s why state in memory is not a side effect in Cycle apps.

About the proposed read only GET API for the HTTP driver, think of it as a read effect, in other words, a message from the external world to the app. It indeed is requested by the app, but it can be considered to be a pull based message. So it makes some sense if it can come from the sources.

That said, I’m not so sure about building it yet. HTTP interaction is very different to DOM interaction because in the former you have a 1-to-1 correspondence between sink event and source event, which you want to keep. On the DOM however, you don’t have any direct correspondence between DOM sink message (a VTree) and DOM source event (click, etc). For each rendered vtree, you may have zero or 1 or infinite click events related to that vtree. It’s not a 1-to-1 correspondence.

Stream I/O (what Cycle does) works well for modern user interfaces, but a monadic API works better for request&response I/O like with HTTP. The most convenient API would be therefore monadic, but I’m still trying to look for alternatives which would fit best the Stream I/O system in Cycle which emphasizes a readable and explicit dataflow. If you go for a custom solution where monadic I/O (just for HTTP) is mixed with stream I/O (just for DOM), you may gain in conciseness. The goal in Cycle.js is not necessarily to be as concise as possible. It’s instead to make the dataflow explicit, for readability and predictability. How to do this properly for any effects is what I’m after.

Maybe a radical approach may help, perhaps with GraphQL. Let’s explore some alternatives, but keeping in mind the Goal in Cycle.

[wclr]

@ronag it seems that it turns to be a disscussion about allowing HTTP driver to emulate/imitate (not sure about word) push source behaviour.