-
Notifications
You must be signed in to change notification settings - Fork 148
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-1207] collect concurrent actions groundwork - move action history closer to action collection #1432
Conversation
Previously, we updated the view parent context because it included the current URL. Now that we have a dedicated `UrlContext` for this, we don't need to update the view context anymore: all values are immutable (view id and name).
This commit moves the "currentAction" ownership to the main `trackActions` function. This will allow future commits to iterate over the concept of "currentAction" and expose an API to access this information. To keep things more or less simple, the event listener logic has been moved away from the `trackActions` function. The `PendingAutoAction` class has been replaced with a `createAction` function, to follow the trend of preferring function over classes. It is also in charge of waiting the page to be idle, to make it self-contained: the whole action lifecycle is now in the same function. This will make it easier to track concurrent actions. This design might change drastically in "frustration-signals" future tasks.
Instead of using a plain variable, let's use the ContextHistory class directly! In future commits will use this history instead of the one in parentContexts.
@@ -24,15 +24,6 @@ export function startParentContexts(lifeCycle: LifeCycle): ParentContexts { | |||
viewContextHistory.setCurrent(buildViewContext(view), view.startClocks.relative) | |||
}) | |||
|
|||
lifeCycle.subscribe(LifeCycleEventType.VIEW_UPDATED, (view) => { |
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.
This change is unrelated to the PR, and I meant to include it in a follow-up PR, but I merged it on staging before realizing it was there. Sorry about that! I think it's small enough to include it here, you'll let me know.
@@ -41,117 +50,135 @@ export interface AutoActionCreatedEvent { | |||
|
|||
// Maximum duration for automatic actions | |||
export const AUTO_ACTION_MAX_DURATION = 10 * ONE_SECOND | |||
export const ACTION_CONTEXT_TIME_OUT_DELAY = 5 * ONE_MINUTE // arbitrary | |||
|
|||
interface ActionController { |
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.
What about ActionContext
instead of ActionController
? I think it would be more consistent with other context history
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 would be fine with it, but this type has a discard()
method, which is not really context-y (like, it wouldn't be compatible with actual Context typings), don't you think?
packages/rum-core/src/domain/rumEventsCollection/action/trackActions.ts
Outdated
Show resolved
Hide resolved
Codecov Report
@@ Coverage Diff @@
## main #1432 +/- ##
==========================================
+ Coverage 89.79% 89.82% +0.02%
==========================================
Files 105 105
Lines 4292 4274 -18
Branches 955 952 -3
==========================================
- Hits 3854 3839 -15
+ Misses 438 435 -3
📣 Codecov can now indicate which changes are the most critical in Pull Requests. Learn more |
Motivation
Currently, actions are collected in
actionCollection
, and an history is built inparentContext
. To communicate between the twoLifeCycle
events are used, and the currently active action is stored in those two places.With concurrent actions, this implementation will be a bit more complex because
LifeCycle
events will need to be extended to track which actions are created/discarded, and a list of current actions have to be maintained in both places. This makes the whole process unnecessarily complex and error-prone.To make things a bit simpler, let's make the action collection in charge of managing the action history, and expose an
ActionContexts
class the same way we do for URLs and sessions.Changes
See commits.
Testing
I have gone over the contributing documentation.