-
Notifications
You must be signed in to change notification settings - Fork 530
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
feat(core): expose metadata of widgets #4604
Conversation
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit fa6a645:
|
6cef37d
to
45fc64c
Compare
when the user agent of the crawler is detected a meta tag is added to the document head with the widget parameters for the added widgets. Co-authored-by: François Chalifour <[email protected]> Co-authored-by: Eunjae Lee <[email protected]> Co-authored-by: Yannick Croissant <[email protected]> Co-authored-by: Clément Vannicatte <[email protected]>
45fc64c
to
a18daff
Compare
i noticed this was the only place where the unintuitive $0 is used after #4604, so i suggest this change as well
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.
It looks good to me. It'd be good to have a snapshot test on the telemetry payload, so that we can have a quick glance on how it looks like, but not a blocker to merge the PR.
let widgetParams = {}; | ||
|
||
if (widget.getWidgetRenderState) { | ||
const renderState = widget.getWidgetRenderState(initOptions); |
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.
The problem is by using widgetParams
from the renderState
you do not get the parameters used by the user but the ones passed to the connector, that can be different depending of what was done in the widget (some are not passed to the connector, others can added or transformed). So we do not really get a view of what parameters was used by the user, defeating the main purpose of the project 😢
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.
I actually had a look, and while we are missing the parameters that are not sent to the connector (visual-only ones), we still retrieve all the values without their defaults, since those are only assigned on the destructuring on the connector. I think that's a fair tradeoff that doesn't require rewriting all widgets. I will however after this do a pass on all widgets, and make sure they don't set any defaults that are also set in the connectors
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.
I think in a second pass, we actually could send the visual-only parameters to the connector as well, since it's impossible for the parameters to clash significantly
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.
I think this is a mandatory step, in the current PR we are missing a lot of information (see https://github.com/algolia/instantsearch.js/blob/2431b966e771d8d9386d919eb469c79b27b5b24a/src/widgets/pagination/pagination.js for example, only totalPages
and padding
are sent to the connector, we are missing templates
, showFirst
, showLast
, etc.)
Also in most widget the parameters are send after destructuring, so with their default values.
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.
so with their default values
I've checked, and that's not really true. They're destructured, but the default value is applied in the connector
src/types/widget.ts
Outdated
/** | ||
* private marker on widgets to differentiate a widget from a connector | ||
*/ | ||
$$official?: boolean; |
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.
Why can't we base this on the ais
namespace? ($$type.startsWith('ais.')
).
It'd be nice not having to extend our APIs for this.
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.
the goal is to differentiate between a widget and a connector. Do you see another way?
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.
going with $widgetType in a separate PR
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.
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.
We don't test that the Telemetry middleware is added to the InstantSearch instance when the crawler agent is present.
this prevents it from being classed as a response
this adds a new middleware (enabled by default) which calls
getWidgetRenderState
on all widgets to get the widgetParams