Skip to content
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

Merged
merged 12 commits into from
Mar 23, 2022

Conversation

BenoitZugmeyer
Copy link
Member

Motivation

Currently, actions are collected in actionCollection, and an history is built in parentContext. To communicate between the two LifeCycle 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

  • Local
  • Staging
  • Unit
  • End to end

I have gone over the contributing documentation.

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.
@BenoitZugmeyer BenoitZugmeyer requested a review from a team as a code owner March 21, 2022 11:37
@@ -24,15 +24,6 @@ export function startParentContexts(lifeCycle: LifeCycle): ParentContexts {
viewContextHistory.setCurrent(buildViewContext(view), view.startClocks.relative)
})

lifeCycle.subscribe(LifeCycleEventType.VIEW_UPDATED, (view) => {
Copy link
Member Author

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.

@BenoitZugmeyer BenoitZugmeyer changed the title ♻️ [RUMF-1207] implement concurrent actions - move action history closer to action collection ♻️ [RUMF-1207] collect concurrent actions groundwork - move action history closer to action collection Mar 21, 2022
@@ -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 {
Copy link
Collaborator

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

Copy link
Member Author

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?

@BenoitZugmeyer BenoitZugmeyer requested a review from a team as a code owner March 22, 2022 16:31
@codecov-commenter
Copy link

codecov-commenter commented Mar 22, 2022

Codecov Report

Merging #1432 (59b01f6) into main (3cf99fc) will increase coverage by 0.02%.
The diff coverage is 92.94%.

@@            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     
Impacted Files Coverage Δ
packages/rum-core/src/boot/rumPublicApi.ts 94.73% <ø> (ø)
packages/rum-core/src/domain/lifeCycle.ts 100.00% <ø> (ø)
packages/rum/src/boot/startRecording.ts 100.00% <ø> (ø)
...ain/rumEventsCollection/action/actionCollection.ts 95.45% <50.00%> (+0.21%) ⬆️
packages/rum-core/src/boot/startRum.ts 22.22% <57.14%> (+2.65%) ⬆️
.../domain/rumEventsCollection/action/trackActions.ts 96.29% <96.00%> (-1.79%) ⬇️
packages/rum-core/src/domain/assembly.ts 100.00% <100.00%> (ø)
packages/rum-core/src/domain/internalContext.ts 100.00% <100.00%> (+9.09%) ⬆️
packages/rum-core/src/domain/viewContexts.ts 100.00% <100.00%> (ø)
packages/rum/src/boot/recorderApi.ts 95.91% <100.00%> (ø)
... and 3 more

📣 Codecov can now indicate which changes are the most critical in Pull Requests. Learn more

@BenoitZugmeyer BenoitZugmeyer merged commit 7316a1b into main Mar 23, 2022
@BenoitZugmeyer BenoitZugmeyer deleted the benoit/concurrent-actions-1 branch March 23, 2022 14:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants