fix(insideBoundingBox): allow type to be a string too#1310
fix(insideBoundingBox): allow type to be a string too#1310Haroenv merged 1 commit intoalgolia:masterfrom bidoubiwa:fix/instantsearch-4916
Conversation
…nd instantsearch.js
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit de46145:
|
|
If this is changed, what impact does this have on InstantSearch.js for example, does it make the ts-ignore unneeded or does the parameter now need to be checked @bidoubiwa ? |
|
I packed the package and tried it in instantSearch. I works great! See https://github.com/bidoubiwa/instantsearch.js/pull/1 I also implemented in another PR the simplification it brings in the code of instantSearch where the type does not require to be enforced anymore. see: https://github.com/bidoubiwa/instantsearch.js/pull/2/files |
|
Once it is released and the package is updated in instantsearch.je should I make the other pr's as well? Or do you prefer handling it when bumping the version? Both solution (or none) are good to me :) |
|
I'll release here now, updating the version bump on InstantSearch' side would definitely be welcome, thanks @bidoubiwa ! |
This PR adds the possibility for the
insideBoundingBoxtype to be a string as well. The reason behind this improvement comes from the usage ofinsideBoundingBoxin instantsearch.js where it is used as a string.More details in this issue in instantsearch.js.
I suppose this PR adds breaking changes as functions using
insideBoundingBoxwith the sole expectation of it to beReadonlyArray<readonly number[]>will have to be updated to check if it is one of both.Here is an example of how it would be breaking:
( I searched to point this PR to v5 since it introduces breaking changes but could not find the related branch 😕)