Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Default Query - Should be Submitting with "retrieveFacets = true" #369

Closed
rosiegrant opened this issue Nov 18, 2019 · 3 comments
Closed

Default Query - Should be Submitting with "retrieveFacets = true" #369

rosiegrant opened this issue Nov 18, 2019 · 3 comments
Assignees
@data-enabler

Comments

@rosiegrant
Copy link
Contributor

If we submit a default query and the page has a facets component, the retrieveFacets parameter on the API call should always be set to true

Otherwise the default queries that we submit won't show facets:
https://answers-js-demo.netlify.com/sites/rose/employees.html
image
@data-enabler data-enabler self-assigned this Dec 5, 2019
@data-enabler
Copy link
Contributor

Looks like retrieveFacets doesn't get enabled until a Facets component gets added to the page, meaning that there's an ordering dependency here 😞. Haven't confirmed, but I suspect it would work if the Facets component were added before the SearchBar.

@data-enabler
Copy link
Contributor

Noticed that it stopped happening when I tried to reproduce it in 0.10.1, and it's because the location permission check added in #387 causes the initial search to happen asynchronously (and therefore after both components have been added to the page).

There are plans to add a retrieveFacets option to the top-level search config, but in the meantime I think making initial search always asynchronous (currently it isn't in browsers that don't support the permissions API) should fix this for 99% of cases (and make the behavior more consistent). Basically, as long as the Facets component isn't added asynchronously after the SearchBar, it should work as expected.

@data-enabler data-enabler mentioned this issue Dec 6, 2019
Merged
@data-enabler
Copy link
Contributor

Fixed in v0.10.1

@oshi97 oshi97 mentioned this issue Sep 9, 2020
Merged
oshi97 added a commit that referenced this issue Sep 9, 2020
@oshi97
downgrade regenerator-runtime due to unsafe eval usages (#1062)
1efcda1 
This commit downgrades regenerator-runtime from
^0.13.3 (currently 0.13.7) to being pinned to exactly
0.13.1. This is because there is a change in 0.13.2 which
adds back in a Function() constructor to define
regenerator runtime globally.
See #369 https://github.com/facebook/regenerator/commits/master/packages/regenerator-runtime

T=https://yextops.zendesk.com/agent/tickets/347915
TEST=manual

tested with a local apache httpd server on a searchbar only page
added below line to .htaccess, which sets the CSP to
the same as Syncreon

also test csp with a `<meta>` tag

tested both answers.js, answers.min.js, answers-modern.js, and answers-modern.min.js

double checked that our code still runs correctly in ie11, for both a searchbar only
page with no unsafe-eval csp, and a regular page with facets and results
that allows unsafe eval
oshi97 added a commit that referenced this issue Sep 9, 2020
@oshi97
downgrade regenerator-runtime due to unsafe eval usages (#1062)
e1b0826 
This commit downgrades regenerator-runtime from
^0.13.3 (currently 0.13.7) to being pinned to exactly
0.13.1. This is because there is a change in 0.13.2 which
adds back in a Function() constructor to define
regenerator runtime globally.
See #369 https://github.com/facebook/regenerator/commits/master/packages/regenerator-runtime

T=https://yextops.zendesk.com/agent/tickets/347915
TEST=manual

tested with a local apache httpd server on a searchbar only page
added below line to .htaccess, which sets the CSP to
the same as Syncreon

also test csp with a `<meta>` tag

tested both answers.js, answers.min.js, answers-modern.js, and answers-modern.min.js

double checked that our code still runs correctly in ie11, for both a searchbar only
page with no unsafe-eval csp, and a regular page with facets and results
that allows unsafe eval
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@data-enabler data-enabler

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@data-enabler @rosiegrant