-
-
Notifications
You must be signed in to change notification settings - Fork 155
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
Cannot compose createUploadLink #63
Comments
That error makes sense, it looks like you are concatenating the links in the wrong order. |
As mentioned in 1) and 2) I've tried it both ways. With uploadLink last as well. It appears to me what's happening is: When I don't compose it and just use the straight up uploadLink
I'm getting an upload "Promise" on the server side, which then lets me resolve the stream from it:
But, when I compose the link with my custom link:
The response on my server I just get a "preview" file upload, and no promise to resolve:
I'm not sure if I did something wrong? But before I wrote my code depending on a promise being sent to the server. So that's breaking. |
@dbelchev I'm aware you can concat in that manner too. I tried that and it yielded the same result:
Which is a un-promised preview file on the server:
or upload simply ends up null as shown below. The only thing I can think is that I'm using the
Here's what my object looks like before sending: Note that this input works when un-composed, and doesn't include the "__typename" prop. Here's the same object
At this point, depending on what the "dumb" link does, upload either ends up: |
This was an issue with my own link. Closing, and I apologize for any confusion. |
yes @flemwad I'm getting the same thing. please let us know how you fixed it. |
I have exactly the same issue, no idea how to figure out the cause of the problem. Maybe it would be also very useful if someone could provide an example how to correctly create a complex link both on the client and using ssr, and how to use it if the graphql schema is a bit more complex. |
I decided to avoid this package. I send base64 of whatever I want to upload to the server. |
I have a |
@bennypowers you can't have 2 terminating links, because, well, they are terminating. The last one will never happen! You can use the Apollo link |
My implementation, based on @Zn4rK's work, for avoiding ' You are calling concat on a terminating link, which will have no effect` while still using Batching etc. import { getMainDefinition } from 'apollo-utilities';
import { split } from 'apollo-link';
import { httpLink } from './httpLink.js';
import { wsLink } from './wsLink.js';
import { uploadLink } from './uploadLink.js';
const isFile = value => (
(typeof File !== 'undefined' && value instanceof File) ||
(typeof Blob !== 'undefined' && value instanceof Blob)
);
const isUpload = ({ variables }) =>
Object.values(variables).some(isFile);
const isSubscriptionOperation = ({ query }) => {
const { kind, operation } = getMainDefinition(query);
return kind === 'OperationDefinition' && operation === 'subscription';
};
const requestLink = split(isSubscriptionOperation, wsLink, httpLink);
export const terminalLink = split(isUpload, uploadLink, requestLink); |
I think it would be worthwhile to mention in the README that you can use |
I have this issue currently and tried to solve it by using @bennypowers 's method. Since my mutations are sometimes objects, i've used lodash's isPlainObject method to determine the terminal link. const requestLink = split(
({ query }) => {
const { kind, operation }: any = getMainDefinition(query)
console.log('requestLink', { query, kind, operation })
return kind === 'OperationDefinition' && operation === 'subscription'
},
wsLink,
httpLink
)
const uploadLink = createUploadLink({ uri: BACKEND_GQL })
const isFile = (value: any) => {
if (isPlainObject(value)) return Object.values(value).map(isFile).includes(true)
const isfile = typeof File !== 'undefined' && value instanceof File
const isblob = typeof Blob !== 'undefined' && value instanceof Blob
return isfile || isblob
}
const isUpload = ({ variables }) => Object.values(variables).some(isFile)
const terminalLink = split(isUpload, uploadLink, requestLink)
const link = ApolloLink.from([
authLink,
errorLink,
terminalLink
])
export const client = new ApolloClient({
link,
cache
}) The topic was closed and a little bid old. Therefore I'd like to ask if there is any update to this or any other solution, or more easy way? Because for each request I have make this decision, and 99% of the operations are not related to upload. |
The
My fix is to use a less aggressive omit __typename function with a check for file uploading first.
|
I'm trying to figure this one out. Would love some help if anyone notices an obvious blunder below
everything is working until I add uploadLink UPDATE: All I had to do was remove my httpLink which I guess is doing the same thing as uploadLink |
@acomito, I got the same issue, but the solution was on README in Apollo Client can only have 1 terminating Apollo Link that sends the GraphQL requests; if one such as HttpLink is already setup, remove it. It seems to better read the docs first for all of us 😂 |
This was mentioned in #35 already, but I'm still experiencing the same issue when trying to compose any other link with createUploadLink.
My code:
I've tried a combination of:
1)
concat(uploadLink, cleanTypenameFieldLink)
uploadLink.concat(cleanTypenameFieldLink)
my custom cleanTypenameFieldLink doesn't run, but the file will upload
The order above throws an apollo-link warning:
You are calling concat on a terminating link, which will have no effect
2)
concat(cleanTypenameFieldLink, uploadLink)
,cleanTypenameFieldLink.concat(uploadLink);
While this seems to work, but the upload promise is undefined when it hits the server. Which I'm assuming means the clientUploadLink never was ran when last.
3)
I've also tried the fix mentioned in the bottom of the issue of referencing the build
index.js
directly, to no avail.4)
Assumed my custom link wasn't working and tried something simple like HttpLink, I had the same results as 1 and 2 from above.
In that issue it was mentioned this might be a
.mjs
and CRA issue, but I've ejected my CRA and confirmed I have the merged code from the mentionedCRA PR
in #35. Which just seemed to be CRA support for.mjs
extensions.If I've missed anything please let me know! Everything has worked great otherwise, so thank you.
The text was updated successfully, but these errors were encountered: