Conversation
358291c to
584122e
Compare
|
View your CI Pipeline Execution ↗ for commit e4af13b.
☁️ Nx Cloud last updated this comment at |
7aaa320 to
cbc141a
Compare
83d6847 to
c2d7f28
Compare
c2d7f28 to
d1ebcca
Compare
843054d to
44f54ae
Compare
Codecov Report❌ Patch coverage is ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
055d1be to
3dae4b0
Compare
|
|
||
| The time to interactive is quite tricky as it not only depends on the relevant data readiness, but also on | ||
| component internal display mechanics. | ||
| If you know exactly where javascript will trigger a layout change (e.g. by passing a boolean variable to true), it's possible to measure the upper bound for the rendering. |
There was a problem hiding this comment.
It is a bit vague, maybe an implemented example could help the user understand better here
| If you know exactly where javascript will trigger a layout change (e.g. by passing a boolean variable to true), it's possible to measure the upper bound for the rendering. | ||
|
|
||
| In addition, during a component development, you can't possibly know beforehand if the component will be relevant for a TTI or not, since it depends on the page itself. | ||
| For example, the display of a cart component may be relevant for TTI in a given page and not relevant at all in others. |
There was a problem hiding this comment.
(product selection vs product recap?)
| As the browser can't understand when a route event happens in an SPA, the NavigationTimingAPI can't be directly used apart from the first page load at most. | ||
| Subsequent routing changes won't profit of the API connection timings. | ||
|
|
||
| In regard of the __server fetches__ (filter out from the resource timing API), the [PerformanceMetricPlugin](https://github.com/AmadeusITGroup/otter/blob/main/packages/@ama-sdk/core/src/plugins/perf-metric/perf-metric.fetch.ts) |
There was a problem hiding this comment.
| In regard of the __server fetches__ (filter out from the resource timing API), the [PerformanceMetricPlugin](https://github.com/AmadeusITGroup/otter/blob/main/packages/@ama-sdk/core/src/plugins/perf-metric/perf-metric.fetch.ts) | |
| In regard of the __server fetches__ (filtered out from the resource timing API), the [PerformanceMetricPlugin](https://github.com/AmadeusITGroup/otter/blob/main/packages/@ama-sdk/core/src/plugins/perf-metric/perf-metric.fetch.ts) |
@sdo-1A : could you confirm this one please?
| ... | ||
|
|
||
| somethingHappened() { | ||
| this.eventTrackService.addUiEvent(new analyticsEvents.dummyEvent()) |
There was a problem hiding this comment.
What does dummyEvent look like?
|
|
||
| ## TrackEventsModule | ||
|
|
||
| The `TrackEventsModule` contains directives to help you track standard event such as the `TrackClickDirective` or |
There was a problem hiding this comment.
| The `TrackEventsModule` contains directives to help you track standard event such as the `TrackClickDirective` or | |
| The `TrackEventsModule` contains directives to help you track standard events such as the `TrackClickDirective` or |
|
|
||
| The `TrackEventsModule` contains directives to help you track standard event such as the `TrackClickDirective` or | ||
| `TrackFocusDirective`. | ||
| You can track more standard ui event with the `TrackEventsDirective` and even create your own component events |
There was a problem hiding this comment.
| You can track more standard ui event with the `TrackEventsDirective` and even create your own component events | |
| You can track more standard ui events with the `TrackEventsDirective` and even create your own component events |
| <button | ||
| (click)="doSomethingElse()" | ||
| trackClick | ||
| [trackEventContext]="analyticsEvents.runtimeDummyEvent('You could send runtime data here')"></button> |
There was a problem hiding this comment.
you should probably explain how these events look like before using them in the documentation
|
|
||
| ### TrackEvents directive | ||
|
|
||
| The directive will listen to the events on the element on which was applied and will expose the event captured using the track service. |
There was a problem hiding this comment.
| The directive will listen to the events on the element on which was applied and will expose the event captured using the track service. | |
| The directive will listen to the events on the element on which it was applied to, and will expose the event captured using the track service. |
| | trackEvents | List of events which have to be tracked | ['mouseover', 'mouseenter'] | | ||
| | trackEventContext | Custom object to be exposed when the event is captured | {context: 'continueBtnClicked'} | | ||
|
|
||
| A specific directive for the click event was created, as it is the most used tracked event. |
There was a problem hiding this comment.
| A specific directive for the click event was created, as it is the most used tracked event. | |
| As the click is the most tracked event, the `@o3r/analytics` provides a dedicated directive to support it. |
|
|
||
| ### Application level | ||
|
|
||
| At application level a subscription can be done to the observable emitted by the track events service. |
There was a problem hiding this comment.
| At application level a subscription can be done to the observable emitted by the track events service. | |
| At application level, the track events service can subscribe to observables emitted by tracking events. |
packages/@o3r/analytics/src/fixtures/jasmine/event-track.service.fixture.jasmine.ts
Outdated
Show resolved
Hide resolved
3dae4b0 to
4ede4dd
Compare
4ede4dd to
e4af13b
Compare
|
This pull request has had no activity for 6 months and has been marked as stale. Please push new commits or comment to keep it open; otherwise it will be auto-closed in another 3 months. |
Proposed change
Provide a way to emit Analytics events to multiple providers:
Missing