-
Notifications
You must be signed in to change notification settings - Fork 787
Conversation
955eae7
to
de8899c
Compare
@glasser do you know what the circumstance that leads to this bug is? Seems likely to be either: a) component receives new props before it has mounted Neither seems like valid react lifecycle but I'm not initimately aware of the rules surrounding it. Can we figure out which it is so we can add a test? |
1036a23
to
baa329f
Compare
34032af
to
c2af14a
Compare
@glasser I ended up getting rid of promise code, not really needed in jasmine (I had my mocha hat on). |
|
||
networkInterface.query = (request) => { | ||
console.log('failing') | ||
fail(new Error('query ran even though skip present')); |
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 can't figure out what fail
is. It's not in https://facebook.github.io/jest/docs/api.html or defined in the file. But it does seem to work (I tested with the change reverted...)
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 guess fail
is a Jasmine thing. Jest's docs seem a bit incomplete.
@@ -495,6 +614,44 @@ describe('queries', () => { | |||
renderer.create(<ProviderMock client={client}><ChangingProps /></ProviderMock>); | |||
}); | |||
|
|||
|
|||
fit('allows you to unmount a skipped query', (done) => { |
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.
Changing to it
const oldQuery = networkInterface.query; | ||
|
||
networkInterface.query = (request) => { | ||
console.log('failing') |
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.
Removing this line
renderer.create(<ProviderMock client={client}><Parent /></ProviderMock>); | ||
}); | ||
|
||
it('allows you to skip then unskip a query with opts syntax', (done) => { |
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 one wasn't actually failing (without the code change). Or maybe it was failing if you only reverted one bit of the code change but not the whole commit.
I've made it longer and more detailed, but then it doesn't actually pass any more: looks like I can't convince it to run the query again. Maybe that's due to some caching and that's a feature? I guess @tmeasday is asleep now; @jbaxleyiii want to take a look at my version of this test and help me figure out how to get it to fail? The goal is to trigger a now-fixed bug where the check on opts.skip
in subscribeToQuery doesn't delete querySubscription and thus never re-subscribe
s when unskipped.
networkInterface.query = (request) => { | ||
console.log('failing') | ||
fail(new Error('query ran even though skip present')); | ||
return oldQuery(request); |
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.
Lack of preserving this
caused problems when I copied this into other test. fixed.
a364db1
to
6845cb8
Compare
See #255. @glasser and I found a few bugs around the (old and new) skip options, and wrote some tests to confirm the fixes and stop regressions - didn't delete querySubscription in .unsubscribeFromQuery() - this mean if you skipped and then unskipped, it would break - not checking for querySubscription before .unsubscribe on unmounting - if you skip then unmount, you have problem - check for non-skip -> skip in willReceiveProps didn't return in the remain skipping case - mean "non skipping" code ran when remaining skipping. - Make the default data have an "errors" null field rather than "error" since that matches what is done elsewhere. - Also make sure to consistently set it to null rather than undefined. - Be a little more consistent about how we initialize and re-initialize this.data; for example, if we use the deprecated skip option to change an unskipped query to a skipped query, include "error: null" as well, and if we are switching from unskip to skip to unskip, make sure to re-initialize the full data object.
6845cb8
to
8ee1a1f
Compare
OK, I put a little more effort into this and got all the new tests to pass (and to fail without the graphql.tsx changes). This involved a few more changes to the real code, all of which I think are bug fixes, but I'm looking at all this code for the first time and I might be wrong! I'd love another round of review from @jbaxleyiii or @tmeasday or anyone familiar with the code! |
I wonder if rather than adding and removing the observable query fields from |
Or do we need the other parts of |
Or maybe we should just copy the properties over at render time and not attach them to data in the first place. I might do that. In any case, I am good with these changes. Merging. |
The main thing i was going for by inserting the initializeData call in subscribeToQuery was to ensure that when you "unskip" that you end up with I think the idea of handling skipping directly in render makes sense. |
I think we can go a bit further and actually not cache |
Also delete querySubscription when there is no subscription, since that
seems reasonable.
See #255.