Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disambiguate the request interface #11

Open
secobarbital opened this issue Oct 22, 2015 · 2 comments
Open

Disambiguate the request interface #11

secobarbital opened this issue Oct 22, 2015 · 2 comments

Comments

@secobarbital
Copy link
Collaborator

Currently the driver takes in either a string or an object with url, input, init keys. These keys were based on the function signature in the MDN documentation but they are not intuitive names and url does not exist in the MDN doc.

Discussion started in #6
/cc @teohhanhui

@secobarbital
Copy link
Collaborator Author

How about the following sink interface:

(url: String) |
(args: [input: String|Request, init: Object]) |
(request: { args: [input: String|Request, init: Object], key: String })

That is, the user can pass a string, an array or an object. The string would be interpreted as the url, the array would be interpreted as an argument list for fetch, and an object would have an args field with the argument list for fetch with an optional key field with an arbitrary string key for response filtering.

On the source side, we would continue to attach the original request object to the response observable and allowing filtering by the key or the request object (JSON.stringify??).

@fiatjaf
Copy link

fiatjaf commented Feb 22, 2016

I agree.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants