Improved ajax by pangratz · Pull Request #171 · emberjs/rfcs

pangratz · 2016-10-11T11:50:03Z

nathanhammond · 2016-10-11T16:49:41Z

If we're going through this effort is it worth trying to build something that decouples us from the underlying jQuery implementation? There is hopefully a future in which we don't ship that by default and it would be sad to require jQuery just for $.ajax.

See: https://github.com/ember-cli/ember-ajax

pangratz · 2016-10-11T17:08:17Z

@nathanhammond yep, I definitely agree. The hooks should be designed to be agnostic of the specific library/implementation which does the actual request. I forgot to mention that explicitly in the RFC...

markcellus · 2016-10-11T20:38:14Z

@nathanhammond fetch maybe?

- `makeRequest` is public - smaller adjustments

tchak · 2016-10-25T16:53:49Z

I think the hooks as described in this RFC have no dependency on $.ajax. They are some examples based on $.ajax usage, men we could remove them, or add more examples with fetch for example.

One suggestion I have is that we are passing to makeRequest() a hash of options. The hash looks like this:

{
  url: 'https://api.com/posts',
  method: 'POST',
  headers: {},
  body: '{ post: {} }'
}

There is a spec for a Request object (as part of fetch). I am not saying we should use it directly, but, I think we should model a Request object in ember-data after it. DS.Request? I would also expect both be compatible and so once we support fetch, it would be possible to pass in native Request object.

bmac · 2016-10-25T18:07:50Z

+  let headers = this.headersForRequest(params);
+  let body    = this.bodyForRequest(params);
+
+  return RSVP.hash({ method, url, headers, body });


Should _requestFor be made a public method in case the user wants to add some other config property?

and it could return a "standard" Request object :)

bmac · 2016-10-25T18:13:02Z

+  @param request Object containing all properties for the request which should be made
+  @return Promise
+ */
+makeRequest(request) {


I think we should enumerate all of the properties Ember Data expects/supports on the request object.

Good point!

Based on my reading of this rfc it looks like it supports url, method, headers and body. With the exception of url all of these properties are shared by the 2nd argument to fetch (See: https://fetch.spec.whatwg.org/#requestinit). Which may lead a user to believe it supports all the properties that fetch supports.

This leads me to ask 2 questions.

How much of the RequestInit api should Ember Data implement?

Should the url property be pulled out of the request object and makeRequest API be change to align more closely with the fetch api? makeRequest(url, requestInit)

fetch can also take a single argument with Request instance. This is kinda what I was proposing in my other comments. But align makeRequest with fetch options is 👍

bmac · 2016-10-26T13:30:39Z

@tchak I'm not sold on a DS.Request class. What is the advantage of that wrapping the request state in a class instance vs just having users return a plain object with the same properties?

bmac · 2016-10-26T14:51:25Z

@pangratz in response to you unresolved questions section at the end of the rfc.

currently requestType is used to indicate the specific adapter operation, but that name might not be to expressive. Should this be renamed to the more verbose, like adapterOperation?

I'm in favor of renaming requestType to adapterOperation.

should queryForRequest be named queryParamsForRequest?

Again I like this change but I don't feel very strongly about it.

should there be more hooks within urlForRequest, as outlined in the Syntax section on the URLs wiki page?

I do not think we need any more hooks inside urlForRequest other then what is described in this rfc. I believe the current hooks satisfy most of not all of the requests for customization points in the url that we've seen in the Ember Data repo over the years. I suspect if we added more hooks they would be unused in 99% of cases and the remaining cases users can still override urlForRequest to generate the url they need.

the currently proposed API doesn't allow to only use public API to customize the json-api-adapter, though the current implementation could be changed to set the Content-Type header instead (which would be more agnostic anyway). This might be an indicator that the proposed API still needs some adjustments so json-api adapter uses only public API.

what hooks are missing?

setting the dataType #4357?

I was originally thinking _requestFor should be made public so users can return other config options that the fetch api supports besides headers, method and body. But that doesn't solve the case of special jquery specific configuration.

2 possible approches:

Limit the ajax adapter to only allow configuring of jQuery ajax features that can be described using a fetch api. (For example contentType would use the Content-Type header but configuring dataType would be unsupported.) The rational being this would make it easier to move the rest adapter to a service worker some day since xhr isn't supported inside a service worker but fetch is.
Add a jqueryAjaxOptions() method and document that it will only be called when jQuery is being used for makeRequest() (Possibly difficult to detect).

bmac · 2016-12-13T23:42:32Z

+    warning("use queryForRequest to specify query params");
+  } else if (query) {
+    let sortedQueryParams = this.sortQueryParams(query);
+    let queryParams = Ember.$.param(sortedQueryParams);


I think we may want to expose a public method for serializing query params that users can override if needed.

You mean additionally to queryForRequest?

Yes. Something that transforms the object returned from queryForRequest() into a string.

Hmm, I see. Maybe queryStringForRequest()?

But then we would have 5 hooks which are involved getting the URL for a request:

urlForRequest

pathForRequest

queryForRequest

sortQueryParams

queryStringForRequest

For now I am not convinced that an additional hook is necessary. Can you think of an use case where such a hook would come in handy?

I've seen a few comments on slack recently were people want arrays or nested query params to be serialized differently from how $.param does it.

I wonder how widely used sortQueryParams is and I wonder if we could deprecate that and let users do that work in queryForRequest or queryStringForRequest if they need it.

Ah, arrays and nested queries are definitely a valid use case 👍

Deprecating sortQueryParams in favor of queryStringForRequest sounds reasonable to me!

woprandi · 2017-03-09T15:58:26Z

+##### `methodForRequest`
+
+Invoked to get the HTTP method for the request. Should return one of `"GET"`,
+`"PUT"`, `"POST"` or `"DELETE"`.


Why not "PATCH" ?

amiel · 2017-03-14T16:12:40Z

This will help resolve some issues we've had with ember-data-url-templates :)

Fix incorrect docs about headersForRequest being used for ember-data versions >= 2.7. This is on hold until emberjs/rfcs#171 gets resolved

* Update data-adapter-mixin.js Fix incorrect docs about headersForRequest being used for ember-data versions >= 2.7. This is on hold until emberjs/rfcs#171 gets resolved * Update data-adapter-mixin.js

cibernox · 2017-06-07T20:42:40Z

This seems to have fallen idle. This would be much needed in order the build a reasonable compatibility layer to be able to swap jQuery by just raw fetch.
At the moment adapters setup headers using the beforeSend function on ajax, which has no fetch counterpart and it is hard, if not plain impossible, to introspect.

Is there any open question or significant pushback from anyone that prevents this from advancing?

* Update data-adapter-mixin.js Fix incorrect docs about headersForRequest being used for ember-data versions >= 2.7. This is on hold until emberjs/rfcs#171 gets resolved * Update data-adapter-mixin.js

denzo · 2017-10-11T23:31:07Z

Same as above comment. It has been a while, it would be great to know where it's at or where it is on the timeline.

Will be happy to contribute to speed it up, if anything at all is needed.

The fact that https://emberjs.com/api/ember-data/2.16/classes/DS.RESTAdapter/methods/headersForRequest?anchor=headersForRequest is still in the docs but can not be used isn't ideal.

@pangratz @bmac @tchak

tchak · 2018-01-21T22:12:54Z

Her is the list of remarks and concerns so far on this RFC:

make requestFor public
~~the RFC dose not provide a way to customise json-api adapter with public methods~~ just set Content-Type header (?)
queryForRequest -> queryParamsForRequest
deprecating sortQueryParams in favour of queryStringForRequest

"make things more standard":

return Request object from requestFor (?)
makeRequest to take Request (?)
return a URLSearchParams from queryParamsForRequest (?)

wycats · 2018-01-22T04:05:24Z

@emberjs/ember-data-contributors @igorT what do we need to do to make progress on these questions?

sandstrom · 2018-02-02T15:29:46Z

Regarding headersForRequest, I think it would be good if it returned a promise that resolved to a hash of headers (i.e. any consumer must expect either an object or a promise).

It's common to append authentication/session tokens in headers, and they may be stored asynchronously (for example in IndexedDB).

fivetanley · 2018-02-16T15:23:28Z

return a URLSearchParams from queryParamsForRequest

@tchak is this polyfillable? This isn't supported by Internet Explorer natively.

rwjblue · 2018-06-15T15:18:16Z

Where are we on this? Is this still a direction we would like to go?

tchak · 2018-06-15T16:13:32Z

@rwjblue I think we want to finish migration to fetch in ember-data before adding anything else to the network layer. For what it worth, I implemented this RFC (and other things) in an addon https://github.com/tchak/ember-fetch-adapter

runspired · 2018-06-27T16:45:37Z

Closing as we are definitely moving in a very different direction. Keep your eyes open for a new RFC :)

ember-data: improved ajax

e8161d9

pangratz added the T-ember-data RFCs that impact the ember-data library label Oct 11, 2016

pangratz mentioned this pull request Oct 11, 2016

Detect version of EmberData to conditionally define ajaxOptions mainmatter/ember-simple-auth#1081

Closed

pangratz added 3 commits October 19, 2016 00:15

Minor improvements

ef3d10b

- `makeRequest` is public - smaller adjustments

Improve summary

df4e1f1

Fix typo

db42d4b

wecc mentioned this pull request Oct 20, 2016

RestAdapter does not allow to set the XHR withCredentials flag warp-drive-data/warp-drive#4563

Closed

bmac reviewed Oct 25, 2016

View reviewed changes

pangratz mentioned this pull request Nov 30, 2016

[FEATURE ds-improved-ajax] Disable feature warp-drive-data/warp-drive#4686

Merged

bmac reviewed Dec 13, 2016

View reviewed changes

marcoow mentioned this pull request Mar 8, 2017

Defining ajaxOptions in DataAdapterMixin disables ds-improved-ajax mainmatter/ember-simple-auth#1042

Closed

woprandi reviewed Mar 9, 2017

View reviewed changes

bartocc mentioned this pull request Apr 25, 2017

Update data-adapter-mixin.js mainmatter/ember-simple-auth#1297

Closed

marcoow pushed a commit to mainmatter/ember-simple-auth that referenced this pull request Jun 7, 2017

Update data-adapter-mixin.js

d948f6c

Fix incorrect docs about headersForRequest being used for ember-data versions >= 2.7. This is on hold until emberjs/rfcs#171 gets resolved

marcoow mentioned this pull request Jun 7, 2017

Update DataAdapterMixin docs mainmatter/ember-simple-auth#1366

Merged

marcoow pushed a commit to mainmatter/ember-simple-auth that referenced this pull request Jun 7, 2017

Update data-adapter-mixin.js

1f453b7

Fix incorrect docs about headersForRequest being used for ember-data versions >= 2.7. This is on hold until emberjs/rfcs#171 gets resolved

sandstrom mentioned this pull request Jan 18, 2018

[QUEST] Making jQuery Optional warp-drive-data/warp-drive#5320

Closed

6 tasks done

runspired closed this Jun 27, 2018

amiel mentioned this pull request Oct 26, 2018

Fix bug (Array params have indexes) and upgrade ember-cli amiel/ember-data-url-templates#48

Closed

Conversation

pangratz commented Oct 11, 2016

Uh oh!

nathanhammond commented Oct 11, 2016

Uh oh!

pangratz commented Oct 11, 2016

Uh oh!

markcellus commented Oct 11, 2016

Uh oh!

tchak commented Oct 25, 2016

Uh oh!

bmac Oct 25, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tchak Oct 25, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bmac commented Oct 26, 2016

Uh oh!

bmac commented Oct 26, 2016

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

amiel commented Mar 14, 2017

Uh oh!

cibernox commented Jun 7, 2017

Uh oh!

denzo commented Oct 11, 2017

Uh oh!

tchak commented Jan 21, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wycats commented Jan 22, 2018

Uh oh!

sandstrom commented Feb 2, 2018

Uh oh!

fivetanley commented Feb 16, 2018

Uh oh!

rwjblue commented Jun 15, 2018

Uh oh!

tchak commented Jun 15, 2018

Uh oh!

runspired commented Jun 27, 2018

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

15 participants

bmac Oct 25, 2016 •

edited

Loading

tchak Oct 25, 2016 •

edited

Loading

tchak commented Jan 21, 2018 •

edited

Loading