Move jsonp to its own method?

[lhorie]

Totally bikeshedding, but what do you guys think about moving jsonp to its own method in v1.0?

Current behavior:

//xhr
m.request({url: url, method: "GET"})

//jsonp
m.request({url: url, dataType: "jsonp"})

Proposed:

//xhr
m.xhr({url: url, method: "GET"})

//jsonp
m.jsonp({url: url})

[dead-claudia]

Works for me. Also, a plain string URL should be accepted for the common case IMO, using the "GET" for m.xhr.

//xhr
m.xhr({url: url, method: "GET"})
m.xhr({url: url})
m.xhr(url)

//jsonp
m.jsonp({url: url})
m.jsonp(url)

Although...isn't XHR moot with the Fetch API? Beyond a few infrequent cases like progress notifications and cancellability (not just "don't care" that's being proposed at WHATWG), what's the benefit?

[Naddiseo]

• +0.5 for moving jsonp its own method.
• -0 for m.xhr, seems like an implementation detail that is leaking to the API. I think either keeping the current m.request, and/or having shortcut methods, such as m.get/m.post/m.json, allows the implementation to change later without the API changing.
• +1 for allowing plain string argument.

[dead-claudia]

@Naddiseo Leo is just considering separating the two methods completely. The two cases share deceptively little code in the first place, anyways.

As for the name, I'd prefer m.xhr to remain m.request, minus the JSONP knowledge. Keep in mind, though, as long as XMLHttpRequests are created and exposed via something like config, it's no longer an implementation detail. And if it's using fetch behind the scenes, it's still not just an implementation detail, because it'll need polyfilled.

[lhorie]

They actually share a lot of code, but it just seems somewhat silly that the signature completely changes based on whether there's a dataType option. Also, the two are fundamentally different things under the hood

[dead-claudia]

@lhorie Eh...I didn't remember all the common option handling until after I wrote that...

They share quite a bit of code, but it's the actual launching of the request that's very different. There's just a lot less to configure with JSONP than with XHRs.

[lhorie]

Ok so I kept m.request for xhr and added m.jsonp for jsonp