-
Notifications
You must be signed in to change notification settings - Fork 142
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
✨ [RUMF-945] allow users to customize the attribute used to define the action name #919
Conversation
@@ -42,6 +42,7 @@ export interface UserConfiguration { | |||
publicApiKey?: string // deprecated | |||
clientToken: string | |||
applicationId?: string | |||
actionNameAttribute?: string |
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'm wondering if the name is not misleading.
It can be confused with the name of the action object we collect
Maybe something like this is clearer:
- actionNameSelectorAttribute
- actionNameHtmlAttribute
- actionNameTrackingAttribute (to refer to the tracking section of the doc)
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 will add some doc about it to explain the usage so IMO it would be clearer enough.
@hdelaby @BenoitZugmeyer @webNeat any thoughts?
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.
About the wording: actionNameAttribute
+ doc LGTM, it's simple enough.
About the configuration: maybe we could have a more abstract getActionName(element, event)
function instead, to allow the customer to implement their own logic to add beside our logic? That would be a bit more flexible.
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.
a more abstract strategy sounds interesting but I'd be in favor of waiting to have the need, in order to see what could be the most relevant approach to do that.
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.
Sounds good to me!
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.
Yes, good to me too :)
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 was thinking that having an array of attributes to check for, instead of just one would offer more flexibility, but the function getActionName
also is interesting.
The current solution sounds enough to me for now.
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 function idea is great! Love that concept.
packages/rum-core/src/domain/rumEventsCollection/action/getActionNameFromElement.ts
Outdated
Show resolved
Hide resolved
packages/rum-core/src/domain/rumEventsCollection/action/getActionNameFromElement.ts
Outdated
Show resolved
Hide resolved
@@ -42,6 +42,7 @@ export interface UserConfiguration { | |||
publicApiKey?: string // deprecated | |||
clientToken: string | |||
applicationId?: string | |||
actionNameAttribute?: string |
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.
About the wording: actionNameAttribute
+ doc LGTM, it's simple enough.
About the configuration: maybe we could have a more abstract getActionName(element, event)
function instead, to allow the customer to implement their own logic to add beside our logic? That would be a bit more flexible.
Codecov Report
@@ Coverage Diff @@
## main #919 +/- ##
==========================================
- Coverage 89.10% 89.09% -0.02%
==========================================
Files 81 81
Lines 3838 3841 +3
Branches 855 857 +2
==========================================
+ Hits 3420 3422 +2
- Misses 418 419 +1
Continue to review full report at Codecov.
|
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.
Nice!
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.
LGTM, just added a small question.
// Proceed to get the action name in two steps: | ||
// * first, get the name programmatically, explicitly defined by the user. | ||
// * then, use strategies that are known to return good results. Those strategies will be used on | ||
// the element and a few parents, but it's likely that they won't succeed at all. | ||
// * if no name is found this way, use strategies returning less accurate names as a fallback. | ||
// Those are much likely to succeed. | ||
return ( | ||
getActionNameFromElementProgrammatically(element) || | ||
getActionNameFromElementProgrammatically(element, DEFAULT_PROGRAMMATIC_ATTRIBUTE) || | ||
(userProgrammaticAttribute && getActionNameFromElementProgrammatically(element, userProgrammaticAttribute)) || |
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.
Can you please explain why the default attribute has priority over the user custom attribute?
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 seemed more convenient for reusing a previous tagging but allow to override some elements with our own attribute if needed
@@ -42,6 +42,7 @@ export interface UserConfiguration { | |||
publicApiKey?: string // deprecated | |||
clientToken: string | |||
applicationId?: string | |||
actionNameAttribute?: string |
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 was thinking that having an array of attributes to check for, instead of just one would offer more flexibility, but the function getActionName
also is interesting.
The current solution sounds enough to me for now.
…e action name (#919) * ✨ allow users to customize the attribute used to define the action name * fix lint/format issues * style tweaks * 🐛 fix userConfig -> config * ✨ allow to have both data-dd-action-name et user configured attribute Co-authored-by: Bazyli Brzóska <bazyli.brzoska@gmail.com>
Motivation
It can be useful to reuse existing tagging in the html to retrieve the action name rather than forcing customer to duplicate their tagging for every third party that need to retrieve this info.
take over of #903
Changes
Introduce new
actionNameAttribute
init configuration optionUsage:
Both
data-dd-action-name
and configured attribute can be used,data-dd-action-name
is favored when both are present on an element.Testing
unit, locally
I have gone over the contributing documentation.