-
Notifications
You must be signed in to change notification settings - Fork 44
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
fix: update the logic of tag_name to prefer a ph-label from a parent … #154
fix: update the logic of tag_name to prefer a ph-label from a parent … #154
Conversation
…over a display name or similar
I'd say this is considered a fix/improvement to the current behavior as discussed before. @steffanlevet thanks for the PR. |
@steffanlevet lint and tests (only 1) are broken, would you mind addressing them? |
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, thanks @steffanlevet
@marandaneto I addressed the lint and bumped the version/updated the changelog. |
@steffanlevet did you commit/push your changes? I don't see any changelog changes. Tests are green now, just the changelog missing really. |
@marandaneto you are right 🤦 . That is all here now. |
Improve
tag_name
when touch events are nestedProblem
This addresses #145
Specifically; when using react-native-gesture-handler, and the
ph-label
is set on aTouchableOpacity
or similar, the label is obscured, because the touch event is triggered against a nested child.An example of such a case:
Changes
This change adds an additional pass over the selected elements to promote any ph-label from a parent onto a child.
In the case above, this would result in the nested
View
andText
children getting thetag_name
'my-label' rather than the current inferred value, be it the displayName or similar.This change also works when there are multiple
ph-label
properties set in the tree, the nearest parent with a label is chosen.In the case there is no
ph-label
the existing behaviour is preserved.This change makes the display of these captured touches far more reasonable when viewing them in the dashboard - instead of "My Heading" being the tag_name attached to an event, the intended label is used.
It is worth noting, this could be considered a breaking change. The breaking nature is really quite minor, and it is unlikely the behaviour changing is depended upon, but the information presented in the dashboard could be different for any given touch before and after this release.
Finally, it is also possible an event receives a tag_name that seems non sensical. Consider the following:
Here, when the
TouchableOpacity
receives the touch, the resulting tag_name will be 'my-top-level-scroll'. That could be quite confusing to say the least. This seems like a reasonable trade off since it seems like an anti-pattern to be using ph-label in this way.Release info Sub-libraries affected
Bump level
Libraries affected
Changelog notes