-
Notifications
You must be signed in to change notification settings - Fork 79
throw timeout error not as XHRError Exn.Error
, but as separate error
#156
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm on board with this, though it would be good to get another look from @garyb or @eric-corumdigital if y'all have a moment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just one request wrt minimizing the diff, and otherwise 👍 I'm happy to merge this.
src/Affjax.purs
Outdated
@@ -168,8 +174,50 @@ patch_ url = map void <<< patch ResponseFormat.ignore url | |||
-- | get json "/resource" | |||
-- | ``` | |||
request :: forall a. Request a -> Aff (Either Error (Response a)) | |||
request req = | |||
case req.content of | |||
request = \req -> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you return this function to its prior formatting, ie.
request :: forall a. Request a -> Aff (Either Error (Response a))
request req =
case req.content of
Nothing ->
send (toNullable Nothing)
Just content ->
case extractContent content of
Right c ->
send (toNullable (Just c))
Left err ->
pure $ Left (RequestContentError err)
It's not necessary to move ajaxRequest
, send
, headers
, and fromResponse
out of the where
clause where they were before (I tested moving them back locally and things compile just fine). Can you move them back? That will minimize the diff and prevent us from splitting some functions into let
bindings and others underneath where
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I write why I did this - for speed and makes easier to see what is dependent on args and what is not
Fix anyway?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't examined the output code -- in what way does this improve performance? I'm genuinely curious.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
currently it compiles to
now
var request = (function () {
var notDependentOnArg1 = function (v) { ... }
var notDependentOnArg2 = function (v) { ... }
return function(req) {
var dependentOnArg1 = function (v) { ... req ... }
var dependentOnArg2 = function (v) { ... req ... }
...
}
})()
request = \req ->
let
dependentOnArg1 = ..
dependentOnArg2 = ..
in ...
where
notDependentOnArg1 = ..
notDependentOnArg2 = ..
before
var request = function(req) {
var notDependentOnArg1 = function (v) { ... }
var notDependentOnArg2 = function (v) { ... }
var dependentOnArg1 = function (v) { ... req ... }
var dependentOnArg2 = function (v) { ... req ... }
...
}
request req = ...
where
dependentOnArg1 = ..
dependentOnArg2 = ..
notDependentOnArg1 = ..
notDependentOnArg2 = ..
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Premature optimization is the root of all evil (or at least most of it) in programming
This is code that is always run in conjunction with a network request. You'll never be able to notice any difference here because network latency dominates a couple of closure allocations, so readability/uniformity has way higher priority.
I can appreciate the argument about making the scoping clearer, but I don't think mixing let
and where
like that actually does that, because you have to read from the top and bottom to find the sandwiched piece of logic in the middle.
…FailedError and XHROtherError
example of
if one forgets to use |
Description of the change
fixes #155
Checklist: