An end user will likely navigate back and forth between search and detail in a slush-marklogic-node project to review the results more closely in search for the appropriate result. Because of the way Angular works, going back to search will rerun the slush SearchCtrl construction, which by default calls the init() function inherited from SearchCtrl.init() in ml-search-ng. This init is now designed to always parse the URL parameters, and always make a call to mlRest.search(). This could cause the user experience to suffer, and depending on the network bandwidth, and latency maybe suffer badly.
It is easy to preserve a copy of earlier search results in memory in Angular (a developer could opt to do that), and feed that back into the new instance of SearchCtrl. The init from ml-search-ng could look for presence of these results, skip parsing URL params in that case, and thereby not make the call to mlRest.search(). To guard against URL param changes without reload, you could add a comparison between preserved state, and the actual URL params.
function urlChanged() {
var params = _.chain( $location.search() )
.omit( ctrl.mlSearch.getParamsKeys() )
.merge( ctrl.mlSearch.getParams() )
.value();
return !_.isEmpty($location.$$search) && !_.isEqual($location.$$search, params);
}
if (ctrl.mlSearch.results.results && !urlChanged()) {
ctrl.response = ctrl.mlSearch.results;
ctrl.updateURLParams();
var d = $q.defer();
d.resolve(ctrl.response);
return d.promise;
} else {
return ctrl.mlSearch.fromParams().then( ctrl._search.bind(ctrl) );
}
If mlSearch and results are not preserved, and feeded back into subsequent SearchCtrl instances, the if part will always be skipped. That would give the old behavior.
This also supports deeplinks. mlSearch will be feeded into the initial SearchCtrl instance, but mlSearch.results will be empty, so a call to MarkLogic will be made after all.
The urlChanged check even supports making internal links that change the URL params, for instance to change facet selection via URL params. The check will detect that the preserved results don't match the URL params search, and do a search after all.
An end user will likely navigate back and forth between search and detail in a slush-marklogic-node project to review the results more closely in search for the appropriate result. Because of the way Angular works, going back to search will rerun the slush SearchCtrl construction, which by default calls the init() function inherited from SearchCtrl.init() in ml-search-ng. This init is now designed to always parse the URL parameters, and always make a call to mlRest.search(). This could cause the user experience to suffer, and depending on the network bandwidth, and latency maybe suffer badly.
It is easy to preserve a copy of earlier search results in memory in Angular (a developer could opt to do that), and feed that back into the new instance of SearchCtrl. The init from ml-search-ng could look for presence of these results, skip parsing URL params in that case, and thereby not make the call to mlRest.search(). To guard against URL param changes without reload, you could add a comparison between preserved state, and the actual URL params.
It would involve replacing lines 106 and 107 in search.controller.js with something along these lines:
If mlSearch and results are not preserved, and feeded back into subsequent SearchCtrl instances, the if part will always be skipped. That would give the old behavior.
This also supports deeplinks. mlSearch will be feeded into the initial SearchCtrl instance, but mlSearch.results will be empty, so a call to MarkLogic will be made after all.
The urlChanged check even supports making internal links that change the URL params, for instance to change facet selection via URL params. The check will detect that the preserved results don't match the URL params search, and do a search after all.