-
Notifications
You must be signed in to change notification settings - Fork 122
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
PathBuilder args merge of old & new values #102
Comments
@samueldepooter That's a good catch! I'd love to have PRs to help fix this. I have no idea where this bug is coming from. Additionally, you're right, we need to improve the docs. -- If you add to the docs under |
I'd like to get this fixed in v0.3.0 @samueldepooter -- do you think you can help make a PR to fix this? |
I think I accidentally closed this! |
Heya, I just added a unit test that appears to disprove this case (227538e) , maybe there's something else going on @samueldepooter? Please let me know what you think, and I can reopen the issue. |
Hi @fbartho,
On running this we can see the variables are being passed correctly but the pathBuilderFunction has the original variables as the function args. Any help around this would be much appreciated. |
Hey @tomevans18 I have no experience working with I'm going on vacation in a week, and in crunch until then, so I wouldn't expect any movement from my side until mid August. |
@fbartho thanks for the quick reply. |
Hi,
I was using the apollo-link-rest pathBuilder to map props to the request options. But I noticed that the pathBuilder function receives args
that consist of a merge of old and new variables. So if I make an initial request with param1
and later make another request with only param2, the second request will consist of param1 and param2 unless I nullify param1
Current behaviour
PathBuilder args consist of both old & new variable values
Expected behaviour
It would make more sense to me if the pathBuilder would only use the params stated in the variables object.
This has the same behaviour as seen when using fetchMore. For fetchMore it makes sense since your next request is based on the first request, but in this case it's a request that is not tied to the previous one.
It would also be nice to have some updated documentation around this feature since I cannot find it anywhere but in the source code!
The text was updated successfully, but these errors were encountered: