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.
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
[#324] Use Moya as the main Network Layer #394
[#324] Use Moya as the main Network Layer #394
Changes from 1 commit
653aa94
7cfad00
d37a1e0
f7d5b3c
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Correct me if I'm wrong. I don't think that we need to filter the status code here. If there's a server error with code 5xx, will this request have no response?
filterSuccessfulStatusAndRedirectCodes() filters status codes that are in the 200-300 range.
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.
RequestConfiguration
was a protocol to define a blueprint for every request. It couldn't be an enum or struct like this since we will have a specific config for each group of APIs based on the endpoint, e.guser
->UserRequestConfiguration
.It's also great if we keep
RequestConfiguration
as its responsibility withAlamofire
, which means it's like a wrapper of Moya. Let's say we will not use Moya and change to another one in the future, so we don't need to update every "RequestConfiguration" to conform to the new lib. Conversely, we're going to import Moya to every request config to be able conformTargetType
(and yeah, now it should be namedABCTarget
).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.
@vnntsu I am a bit confused about this.. Are you suggesting to keep the
RequestConfiguration
protocol unchanged?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.
@vnntsu We're using Moya, so I think using Enum will be fine. In case we have different groups of APIs, we can create another RequestConfiguration like UserRequestConfiguration, as long as we implement the protocol TargetType
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.
@Shayokh144 I suggest keeping
RequestConfiguration
protocol as a wrapper of TargetType; otherwise, we remove it.The enum
RequestConfiguration
is redundancy. We will have specific request configs such asUserRequestConfiguration
orOtherRequestConfiguration
, etc.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.
Before Moya, our
RequestConfiguration
isTargetType
, and it's a wrapper for Alamofire. We are moving toMoya
, so I prefer to removeRequestConfiguration
.@vnntsu did raise a good point about changing to another networking library in the feature. We might need to update every
RequestConfiguration
to conform to the new library. In this case, I prefer to have a typealias:Let's say if we decide to remove Moya and go back to Alamofire, then we just need to implement the protocol
TargetType
(with baseURL, method...) in the network layer.P.s: The reason I suggest
typealias TargetType = Moya.TargetType
instead oftypealias RequestConfiguration = Moya.TargetType
because it's more clear, usingRequestConfiguration
might confuse developers when we are using Moya.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.
@suho typealias added and RequestConfiguration is deleted
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.
No need for documentation comments, it's ok to see on Moya's repository.
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.
No need for documentation comments, it's ok to see on Moya's repository. And for other comments here.
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.
No need to include optional vars.
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.
This has a default value, user of the repo can modify this by themself.