-
Notifications
You must be signed in to change notification settings - Fork 125
refactor to make request non-throwing #56
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
Closed
Closed
Changes from all commits
Commits
Show all changes
8 commits
Select commit
Hold shift + click to select a range
96f4114
refactor to make request non-throwing
artemredkin 543e6a4
fix missing test on linux
artemredkin e1872a8
Merge branch 'master' into non_throwing_request_init
artemredkin e1ddb85
review fix: remove version field
artemredkin f9e2027
Merge branch 'master' into non_throwing_request_init
artemredkin c22aa55
Merge branch 'master' into non_throwing_request_init
weissi 8e43a4d
Merge branch 'master' into non_throwing_request_init
artemredkin b733bbe
make non-throwing
artemredkin File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 sorry, I don't quite follow why this is necessary. I must be missing something... Couldn't we treat a
Request
'surl
property as the source of truth and control access to that?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.
It's not about access control.
URL
'shost
property is optional, but we require it to be non-optional (so we know where to connect, what default domain to use in cookies and how to redirect using relativeURL
). Before that we would unwraphost
(or throw) and then store in the request, but this leads to two downsides:host
andurl
properties (and we cannot throw if we change a property, so url property would have to be set using a function, and this is a bit ugly, imho)To address those two points I propose to introduce new internal type, sort of like "validated request", where user will not be able to change it and
Request
will not be throwing.Does that make sense?
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.
Thanks for the explanation, I see now.
As we control the
URL
so we know its host property is set, can't we force unwrap instead of throwing?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.
What do you mean control the
URL
?URL
is passed in by the user, so we don't know what will be inside it.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.
Doh. I'm sorry, I see now. So we swap the throwing initializer for a failed future from
execute()
. I guess that's a better tradeoff although it does mean that one initializer throws and the other doesn't.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 prefer non-throwing APIs
another option here is to define a custom url type in which host is not optional, and with [optional] initializers from string and URL
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.
converted to optional. I'm not sure having our own URL type is the way to go atm,
URL
is used everywhere.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.
@artemredkin the point was that instead of an internal RequestWithHost you can create and internal UrlWithHost (or whatever), as this is really what you want here, not a custom request object. this will help remove all the boilerplate wrapping eg L105-121
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.
But how one would pass it further? Handler needs access to URL, host, method and headers. If we don't want to expose
UrlWithHost
we will still need some wrapper to pass bothRequest
andUrlWithHost
to `TaskHandler. Does it make sense?Uh oh!
There was an error while loading. Please reload this page.
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.
as i was working on demonstrating what i meant above, i believe i ended up with an even simpler and safer approach: #66
also fixes a bunch of other small bugs and removes runtime preconditions
wdyt?