-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
keep results on search failure #1747
Conversation
src/core/core.js
Outdated
@@ -323,9 +323,6 @@ export default class Core { | |||
window.performance.mark('yext.answers.verticalQueryResponseRendered'); | |||
}).catch(error => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make sense to move this catch immediately after coreLibrary.verticalSearch is called, so that it only catches errors thrown by answers-core? We could then have another catch here at the bottom for all other types of errors
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yea that works, I will update
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
per discussion with oshi offline, the throw error should already be clear on where the issue is from. Adding additional catch statements here would require handling breaking the then/catch chain mid way or add logic to avoid bleeding into the later catch statements (potentially end up with duplicate update loading state calls and console errors)
Rendering failures leading to the catch statements in Universal and Vertical search would clear all results. User would still expects other results from the response to render on page. This pr updates the
storage.set
calls to only update the searchState, instead of storing a new empty results, so the non-problematic result sets can still be render.The catch statements in core.js will terminate any further rendering of sub components once it encounter a problematic sub component. User expects sdk to render as much as it can. To ensure non-problematic sub-components can still render, this pr added more catch statements in component.js to gracefully handle errors coming from individual child component's data transformation, initialization and mount stage.
J=none
TEST=manual
use
dev-keep-data-on-search-failure
for SDK version (from this test branch) in the config file of the site with the issue. Searched 'Listings', and see that the same error appeared in console but the other cards still render as normal.use
dev-dont-clear-data-on-failure
to test changes in this pr through local html pages that use SDK directly. See that errors are logged but the loading icon is reset to complete during error handling process