Driver name in example should be HTTP about cycle-fetch-driver HOT 6 CLOSED

Thanks, @teohhanhui, I think that makes sense.

The problem in this case is that besides the goal being the same, the interface actually differs from the http driver on the response end: res.text() vs res.body and res.json() vs JSON.stringify(res.body), not to mention flatMap vs map.

Do you think it might be confusing to users if we presented it as a drop-in replacement for the http driver?

from cycle-fetch-driver.

It's not a drop-in replacement but an alternative driver serving the same purpose (handling HTTP requests and responses). Some confusion is inevitable for those who don't read but I don't think it should be a serious concern.

Alternatively, we could change the examples of existing HTTP driver to use xhr but do we really need / want the user to be conscious of the implementation?

p/s: The current name Fetch is in the wrong case IMO; how I wish those were named dom and http respectively to avoid such confusion.

from cycle-fetch-driver.

I think the difference in interface is not a problem as even a major version of the same driver can change the interface.

from cycle-fetch-driver.

That's a good point. Let me think this through.

Re: the case of the driver keys, I understand where you're coming from, CamelCase convention is for classes, but staltz just picked it to differentiate it from normal observables, for which he used the convention xyz$. User is certainly free to use any valid keys for them.

from cycle-fetch-driver.

Re: the case of the driver keys, not really: https://github.com/cyclejs/todomvc-cycle/blob/e5f42b0ecf061d356e89d32b14fd3a9e2a3202b4/src/app.js

I think DOM and HTTP are only uppercase because those are abbreviations, but apparently it has led to confusion.

from cycle-fetch-driver.

Sold! Will update once I get the chance. You are welcome to send a PR if you get to it sooner.

from cycle-fetch-driver.