Fix documentation for include and select

[MatrixFrog]

These both can accept either a string, or an array of strings

[flovilmart]

Why isn’t the change reflected in the type of the keys param?

[MatrixFrog]

Ah, thanks, I totally missed that you're using both type annotations in comments, and TS annotations

[codecov]

Codecov Report

Merging #601 into master will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##           master     #601   +/-   ##
=======================================
  Coverage   84.57%   84.57%           
=======================================
  Files          48       48           
  Lines        4039     4039           
  Branches      911      911           
=======================================
  Hits         3416     3416           
  Misses        623      623

Impacted Files	Coverage Δ
src/ParseQuery.js	93.8% <100%> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 2640391...c94ee64. Read the comment docs.

[flovilmart]

I believe there’s still a mismatch, the thing is, the keys are spread, So it’s already accurate, a single string, an array of string are valid values.

[MatrixFrog]

I'm not sure what you want it to say. The way it's written, you could pass multiple arrays of strings, like include(['foo'], ['foo.bar', 'bar']) though I don't know if you want to document that as being supported.

I was following the docs at https://www.typescriptlang.org/docs/handbook/functions.html#rest-parameters which seem to imply that the type of a ... param is always an array. But I'm not sure if you're actually using TypeScript or Flow, and it's possible they disagree slightly on this.

[flovilmart]

Right, that’s this part that’s confusing ...String|Array<string> as it should be read:

(spread of (string or arrays of strings) ) instead of ((spread of string) or (array of strings))

In doubt that’s confusing and even if it’s supported it’s rather make the documentation unambiguous even if it means sacrificing a ‘feature’ or corner case. What do you think?

In the end, it supports only arrays, which can be strings of arrays of strings. So we should remove the spread operator from the jsdocs as it’s confusing (me) an perhaps others.

What do you think?

[MatrixFrog]

Okay so you can basically call it in two ways: You can call it as though the @param annotation in the JSDoc was {...String} or you can just pass a single array as though it was {Array<String>}. (Other ways of calling it are possible but rare enough that we don't want to document them.)

I'm not sure how to represent that in the JSDoc. Maybe just what I have in the PR currently, except with parens: {(...String)|Array<string>}

[flovilmart]

The parens may help with the readability.

[MatrixFrog]

Thanks!