Search Results: fix navigation issues #1641
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
This PR contains a number of bug fixes related to the Search Results page navigation.
If fixes #1170 and #1312 by separating the current navigation page between "Products" and "News & Information" tabs. It becomes possible, for example, to be at "page 3" in one tab, and at "page 1" in the other tab.
It also improves the fix to #1442, provided by commit 5322976. Now, the back button also works when there is a switch between "Products" and "News & Information" tabs, when navigating backwards.
And it also fixes the dynamic loading of search results for the "News & Information" tab. The AJAX load/update only worked for the "Products" tab. Now, it works also for the "News & Information" tab.
It also fixes the annoying "re-load" of the search results immediately after the first load of the search results page.
While working in this PR, another search results navigation issue was found, but the problem is at
stencil-utils
. It has been reported at bigcommerce/stencil-utils#110 (comment) and a PR for the fix has been submitted at bigcommerce/stencil-utils#117Technical Details
In this section, I will explain the code changes in this PR.
1️⃣ Changes to
search.html
template:We already had
{{> components/search/product-listing}}
for the products results and{{> components/search/product-count}}
for the products count, as partials for the Products tab.Now, we introduce
{{> components/search/content-listing}}
and{{> components/search/content-count}}
partials for the News & Information tab results and count.Note that we always want to render the container elements, in order to support toggling between a "zero results page" and a "page with results". We can't keep rendering the containers conditionally (only if there are results) at this upper level (
search.html
)... if the containers are not rendered, when receiving non-empty search results from a future AJAX call, we are not be able to update the DOM.2️⃣ New
content-count.html
partial and changes toproduct-count.html
partial:As part of the strategy of keeping the page number of each tab separated, we update only the respective section (
content
orproduct
) when updating the DOM. In other words: when theproduct
section is updated, thecontent
section will NOT be updated; and when thecontent
section is updated, theproduct
section will NOT be updated. Makes sense.To achieve the expected results, we output the search
url
andcount
values asdata
attributes in a dummy wrapperspan
element, for later retrieval and usage in the JavaScript code.3️⃣ New
content-listing.html
partial:search.html
to its own partial, so it is possible to update it dynamically.4️⃣ Changes to
search.js
code:Let's see the changes to
initFacetedSearch()
first:content-*
components in the list of partials to retrieve.content-*
partials;content
orproduct
elements, according to the requested section (instead of updating everything);showProducts
orshowContent
method, to switch to the proper tab; this ensures the proper tab is displayed after using the back button to browse backwards.The changes to
showProducts
andshowContent
are similar. Note that these functions do two things: update the UI, showing the product or content tab; and they also trigger the dynamic load/update of results.navigate
parameter (with default totrue
, to keep the previous behaviour). This way, it is possible to "separate" the two things that these functions do. If we want to switch the UI tab only, without doing AJAX request to load contents, we can do it by passingfalse
as argument to thenavigate
parameter.navigate
istrue
, instead of using thewindow.location.href
, which can point to a different tab, we are looking into thedata-url
anddata-count
attributes introduced to the*-count
partials. The query string parameter forsection
will be always correct. And, if thecount
is zero, we force the query string parameterpage
to1
. (The use case here is when the initial load was for a page greater than1
, and the tab didn't contain results for that page.)These are the minimal changes to make the existing navigation in a working state. There is room for further improvements.
Tickets / Documentation
Screenshots (if appropriate)
N/A