chore: Use fetch as default for browsers instead of reqwest #199
Conversation
| @@ -33,8 +33,8 @@ function fetchRequest(method, url, args) { | |||
| } | |||
| return result; | |||
| }; | |||
| if (response.headers.get('Accept') && | |||
| response.headers.get('Accept').toLowerCase().indexOf('application/json') >= 0) { | |||
| if (response.headers.get('Content-Type') && | |||
There was a problem hiding this comment.
Corrected, should be Content-Type in response.
There was a problem hiding this comment.
Double checking - now that we're using cross-fetch in our tests, are we able to catch this error?
Also, did notice that we're not mocking out the response.text() function here - do we need to? In general, when will be have a response that's not application/json?
There was a problem hiding this comment.
Yes, now we are able to catch that!
fyi, response.text() was working properly anyway for our flow, since we always do a JSON.parse in http https://github.com/okta/okta-auth-js/blob/master/lib/http.js#L60, this is why I haven't notice that during manual testing.
For what I have seen all our response should be application/json, so maybe should I remove the if/else?
There was a problem hiding this comment.
Seems reasonable if we're catching it downstream. Would also be curious why we have that code to handle it in the first place - my hunch is that at some point we'd occasionally return an error that was not a json response. This might be fixed now though.
manueltanzi-okta
force-pushed
the
manueltanzi-use-fetch-in-browser
branch
from
ad380bf
to
7f2df4f
Compare
manueltanzi-okta
force-pushed
the
manueltanzi-use-fetch-in-browser
branch
from
7f2df4f
to
47be450
Compare
|
some thoughts on refactor dirctory
|
|
@haishengwu-okta good points! But as for /jquery, planning on doing those later when we bump major version, since they would be breaking changes (except for the third bullet). |
| @@ -33,8 +33,8 @@ function fetchRequest(method, url, args) { | |||
| } | |||
| return result; | |||
| }; | |||
| if (response.headers.get('Accept') && | |||
| response.headers.get('Accept').toLowerCase().indexOf('application/json') >= 0) { | |||
| if (response.headers.get('Content-Type') && | |||
There was a problem hiding this comment.
Double checking - now that we're using cross-fetch in our tests, are we able to catch this error?
Also, did notice that we're not mocking out the response.text() function here - do we need to? In general, when will be have a response that's not application/json?
|
@haishengwu-okta Sorry for the wait, took long time to get the cross browser testing completed. But, good news! They all passed!
|
manueltanzi-okta
force-pushed
the
manueltanzi-use-fetch-in-browser
branch
from
cf1a8ec
to
b5e3dc0
Compare
|
@haishengwu-okta fyi, @vijetmahabaleshwar-okta just completed the embedded browser testing (thank you Vijet!), everything good 👍 |
|
Completed sanity testing your branch. Everything looks good. |
Description
okta-auth-jsusereqwestby default as a http request library, this change make it usecross-fetchinstead.jqueryas a request library, converted it to usecross-fetchinstead.Note: Will now try with alpha versions if it works in okta-signing-widget + okta-core before merging.
Note2: Haven't removed the possibility to use jquery as a request library (and the jquery dependency) because it would be a breaking change. But we can easily remove it next time we bump major version.
Reviewers
@haishengwu-okta @jmelberg-okta @rchild-okta