Skip to content

Resource-specific properties set by resource service subclass#67

Open
samdods wants to merge 2 commits intomainfrom
feature/sdods-resource-specific-settings
Open

Resource-specific properties set by resource service subclass#67
samdods wants to merge 2 commits intomainfrom
feature/sdods-resource-specific-settings

Conversation

@samdods
Copy link
Contributor

@samdods samdods commented Jan 11, 2018

🛠 Description & Reasoning

Adding a resource argument to the "additional" functions of the resource service - the functions that are intended to be overridden by subclasses.

Providing the subclass with the resource gives that subclass an opportunity to set parameters of the URL request based on the resource. This is different to the resource providing those parameters itself, e.g. the resource could implement the httpHeaderFields and queryItems properties.

Consider a subclass that adds the requirement that its resources must conform to a protocol GraphQLResouce. The GraphQLResouce protocol requires a property queryName: String to be implemented by its conformers.

The NetworkDataResourceService can now add in the queryName to either the HTTP header fields or the URL query items. It would be unreliable to expect all resources to implement the queryItems and httpHeaderFields to add the queryName key/value.

NOTE: This only impacts consumers that subclass NetworkDataResourceService and override the additionalHeaderFields implementation.

⚠️ API-Breaking Changes

This PR modifies the NetworkDataResourceService.additionalHeaderFields function by adding an argument to the function. This function is overridden (not invoked explicitly), which is why we cannot provide a default argument value. For this reason, this is an API-breaking change.

✨ Other Changes

The addition of the NetworkDataResourceService.additionalQueryParameters function. This serves the same purpose as the additionalHeaderFields function, but for URL query parameters.

@codecov-io
Copy link

codecov-io commented Jan 11, 2018

Codecov Report

Merging #67 into master will increase coverage by 0.15%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master      #67      +/-   ##
==========================================
+ Coverage   86.12%   86.28%   +0.15%     
==========================================
  Files          22       22              
  Lines         346      350       +4     
  Branches       30       30              
==========================================
+ Hits          298      302       +4     
  Misses         48       48

testService.fetch(resource: mockResource) { _ in }
XCTAssertEqual(mockSession.capturedRequest!.allHTTPHeaderFields!, resourceHTTPHeaderFields)
let expectedHeaderFields = [commonKey: "resource", resourceNameKey: mockResourceName]
XCTAssertEqual(mockSession.capturedRequest!.allHTTPHeaderFields!, expectedHeaderFields)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you wanted to avoid the force unwraps here you could use optional chaining with a default value?

mockSession.capturedRequest?.allHTTPHeaderFields ?? [:] should work? It'll still fail but won't crash the tests

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good point @KaneCheshire. i just modified what was already there. didn't even notice the force unwraps.

*/
func urlRequest() -> URLRequest?

func urlRequest(with: [URLQueryItem]) -> URLRequest?
Copy link

@manojmahapatra manojmahapatra Jan 26, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you also please include additionalQueryParameters in the function signature as the parameter name just to go w/ the comment above.

@MarcoGuerrieriTAB MarcoGuerrieriTAB changed the base branch from master to main September 15, 2020 09:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants