QueryManager, fix "invalidate" -> "invalidated" typo i think.

[quazzie]

Was hunting for another bug and came across this.
I didn't find any other reference to "invalidate" property only "invalidated".

Someone with more knowledge of the code maybe knows better.

[hwillson]

Thanks for pointing this out @quazzie! This is a bug, although it's benign since the misuse of invalidate: false doesn't impact any functionality. That being said, this problem could have been avoided if the setQuery function signature was updated to not use a TS any:

apollo-client/packages/apollo-client/src/core/QueryManager.ts

Line 1233 in 1f1aafd

private setQuery(queryId: string, updater: (prev: QueryInfo) => any) {

Your PR is correct, but I'd like to leave this open a bit longer, to get a proper TS fix in place. Thanks!

[danilobuerger]

@hwillson
I don’t think it is possible to tighten the typing of setQuery to catch that error. First thought would be to use Partial<QueryInfo>. However, there is no excess checking on the object literals. So it still wouldn't catch a typo. I would suggest modifying setQuery to:

private setQuery(queryId: string, updater: (prev: QueryInfo) => QueryInfo)

and having callers merge the prev into the result instead of doing that in setQuery.
If you agree, I would create a PR for this.

[hwillson]

@danilobuerger Hmmm - setQuery is called quite a bit in the QueryManager, so moving shared functionality out of it might be a bit of a headache (especially if people forget to handle the prev merging themselves in the future). This isn't a big issue though, so we could just fix the typo and move on. Thanks!

[danilobuerger]

@hwillson They couldn't forget it because of the return type being the full QueryInfo. So either they specify the whole QueryInfo in which case they don't need prev anyway since that gets overwritten, or they only specify it partially and that will throw a type error. So there is no way to forget it. But if we leave it like it is now, there will always be the chance of typos getting in.

[hwillson]

Thanks @danilobuerger - we'll definitely review a PR for this!

[danilobuerger]

Actually, what I said is not working either, as this suffers from the same lack of excess checking. I however found a solution with Pick that keeps setQuery working as is. Will PR now.

[hwillson]

Thanks @quazzie!