Fix #146 : add a way to make queries that don't change the inner state

[bobylito]

Introducing searchOnce, a method to query an index without modifying the state stored in the helper.

[redox]

small typo, trailing ;

[redox]

I think I would start with a simpler example instead of calling addFacetRefinement, something like:

helper.searchOnce({hitsPerPage: 1}, function(error, content, state) { /*... */ });

[bobylito]

Ok makes sense. Actually I think this way of expressing the mutation of the state is nice but it involves creating a full new search state each time we call one of the methods which is not that wise...

[redox]

Since searchOnce is calling all the _getQueries, can I avoid the underlying requests by disabling the faceting with:

// search for the 3 first best (distinct) hits
helper.searchOnce({query: 'foo', disjunctiveFacets: [], facets: [], distinct: true, hitsPerPage: 3}, fn);

[bobylito]

Since searchOnce is calling all the _getQueries, can I avoid the underlying requests by disabling the faceting

Do you mean you want to avoid any other queries other than the main one (the one that does the search with all the filters)?

[redox]

Do you mean you want to avoid any other queries other than the main one (the one that does the search with all the filters)?

Yes, because most of the time the "extra" query we want to do is only to fetch "special" hits (like a query retrieving the top 3 products with promoted=1 or so).

[vvo]

Yaw.

About searchOnce, I did not explain why It was not my favourite naming: because the EventEmitter we have on the helper already introduce the once name:

helper.once('result');

So I thought that searchOnce could be understood as something related to the once of EventEmitter.

[bobylito]

Yes, because most of the time the "extra" query we want to do is only to fetch "special" hits (like a query retrieving the top 3 products with promoted=1 or so).

From what I see in the code, we do send the refinements wether or not we have facets or disjunctive facets set. So if the engine let us do that then we're good :)

So I thought that searchOnce could be understood as something related to the once of EventEmitter.

Ok I get it! I don't think it'll be that much of a problem because we are assuming people are reading the documentation to get information about the API and we don't put too much emphasise on once and it'll also be in different sections of the README/cheat sheet. On the other hand search+once is semantically very accurate for the purpose of this method, imho.

[vvo]

I don't think it'll be that much of a problem

Yes it should be ok.

we don't put too much emphasise on once

Exactly

[bobylito]

So after all, are we good to go on this PR? :)

[redox]

LGTM

[bobylito]

Cool :) Mergin'

[vvo]

For future PRs, can we agree not to commit the builded files? We should only build when releasing (I guess it was a mistake maybe)

[bobylito]

Yes sure :)