-
Notifications
You must be signed in to change notification settings - Fork 344
Conversation
cebff49
to
da22c35
Compare
Generated by 🚫 dangerJS |
Codecov Report
@@ Coverage Diff @@
## master #490 +/- ##
=========================================
- Coverage 91.35% 91.3% -0.05%
=========================================
Files 19 19
Lines 798 828 +30
Branches 196 204 +8
=========================================
+ Hits 729 756 +27
- Misses 64 67 +3
Partials 5 5
Continue to review full report at Codecov.
|
600bc69
to
fe3aa2f
Compare
Hmm, both the template and the bot tell me to update AUTHORS. But does this repo actually have AUTHORS? They also refer to making and linking to docs PRs, but for this repo docs are inside the repo, right? |
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.
Looks really good! fromError
is great. A couple documentation suggestions. Otherwise looks good to me.
fetch: customFetch | ||
}); | ||
``` | ||
You can use the `fetch` option when creating an http-link to do a lot of custom networking. This is useful if you want to modify the request based on the headers calculated or calculate the uri based on the operation: |
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 think "request based on the calculated headers or calculate" would be better
@@ -44,6 +44,14 @@ export interface UriFunction { | |||
(operation: Operation): string; | |||
} | |||
|
|||
// The body of a GraphQL-over-HTTP-POST request. | |||
export interface Body { |
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.
We may be able to have Body be an interface that extends Partial, see this SO. GraphQLRequest
is exported from apollo-link
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.
query
is a string rather than a DocumentNode (and there's no context
), so I don't think that'll work?
In my experience over the entire open source and commercial Apollo codebase, guessing what type is going to be in a field or variable called query
is the most challenging part :)
packages/apollo-link-http/README.md
Outdated
fetch: customFetch | ||
}); | ||
``` | ||
You can use the `fetch` option when creating an http-link to do a lot of custom networking. This is useful if you want to modify the request based on the headers calculated or calculate the uri based on the operation: |
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.
calculated headers sounds a bit better in my head
fetchMock.post('begin:data', makePromise(data)); | ||
beforeEach(() => { | ||
fetchMock.restore(); | ||
fetchMock.post('begin:http://data/', makePromise(data)); |
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.
the uri's are nice! Much more descriptive
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.
Heh, back when I implemented this using the URL web API it didn't work without this :)
@@ -233,18 +241,18 @@ export const selectHttpOptionsAndBody = ( | |||
}; | |||
}; | |||
|
|||
export const serializeFetchBody = body => { | |||
let serializedBody; | |||
export const serializeFetchParameter = (p, label) => { |
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.
@jaydenseric This is going to be a breaking change for [email protected]
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.
Is this OK? I thought this hadn't been released yet so it was an OK interface to break without documenting.
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 ok if the change is documented in a changelog entry, and a new version of apollo-link-http-common
is published with a semver major (breaking change).
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.
Ah, I didn't realize Evans had published a non alpha version of the package.
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.
Evans, should I just revert the name change or something, or bump to 0.2.0?
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.
If you keep the breaking changes, please bump to v1.0.0, breaking changes in semver minor releases are the devil.
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.
@glasser We can bump to v1.0.0, since it will make Jayden's life easier. I'm not worried about having the version number bloat and it might force better practice. The plan for apollo-link-common-http was to be a semi private API(without documentation due to overhead) that developers of links can look at if they want to align with apollo-link-http and apollo-link-batch-http. In that goal I think attempting to follow SemVer would be make keeping up with the changes easier
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.
Sorry I am wrong ^. Let's do v0.2, since we are pre v1.0 SemVer says that a breaking change should be a minor version. Also it looks like we should be okay for Jayden's upload-client
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.
All 3 things should be assumed to be true for every npm package that can be publically installed. There are only upsides and no downsides to bumping the major version number if there is ever a breaking change.
FB in particular is the absolute worst for this. react
jumping from v0.14 to v15 was an admission of guilt they had it wrong for 14 major versions. graphql
being a v0.x causes great disruption to the ecosystem every update.
4b4c63f
to
30539b1
Compare
OK, I bumped the version of apollo-link-http-common to 0.2.0. This should be ready to merge (please don't squash). @evans / @jbaxleyiii I'll let you do the merge — @evans said you were trying to get another release out soon and it would be great to get this in it. |
There is no spec for batching over GET. I don't believe apollo-server supports it given that there's no spec. We can always come up with a spec and implement it later.
30539b1
to
fffde25
Compare
Review commits separately. In addition to explicitly supporting GETs in apollo-link-http, we ban GETs in apollo-link-batch-http, and add an Observable helper
fromError
.