🎨 [PANA-5260] Consolidate recorder object id tracking code

[sethfowler-datadog]

Motivation

To correlate references to the same object in different records, the recording code needs to assign ids to these objects. Today, we track ids for two kinds of objects:

• DOM nodes. (Node objects.)
• Events. (Event objects.)

The objects that manage these two kinds of ids are defined in an almost identical way; the only real difference is the naming scheme of the methods.

The new data format will add to the duplication by tracking ids for two new kinds of objects:

• Strings. (string values.)
• Stylesheets. (CSSStyleSheet objects.)

The new data format also requires the capability to clear these mappings, so the implementation of the tracking code will get slightly more complicated.

Instead of following the existing pattern and duplicating nearly identical code in four places, let's build a single implementation that can handle id tracking for any kind of object or value.

Changes

This PR replaces the existing EventIds and NodeIds implementations with simple wrappers around a shared generic type, ItemIds. It also implements the new id tracking facilities that the new data format will need by adding StringIds and StyleSheetIds wrappers.

As the number of id collections grows, createRecordingScope() is starting to require a large number of function arguments. Since these are simple data structures with very little behavior, there isn't much benefit in using dependency injection for them. So, createRecordingScope() now just creates the id collections internally, simplifying its interface.

The NodeIds collection was a special case in that it had a unique method, NodeIds#areAssignedForNodeAndAncestors(). This is only called in one place, trackMutations.ts, so I've moved the implementation there as a free function, and moved the tests to trackMutations.spec.ts.

Test instructions

This is pure refactoring; there are no functional changes. So, testing that recording continues to work with the browser SDK extension is enough.

Checklist

• Tested locally
• Tested on staging
• Added unit tests for this change.
• Added e2e/integration tests for this change.

[cit-pr-commenter]

Bundles Sizes Evolution

📦 Bundle Name	Base Size	Local Size	𝚫	𝚫%	Status
Rum	164.34 KiB	164.34 KiB	0 B	0.00%	✅
Rum Profiler	4.32 KiB	4.32 KiB	0 B	0.00%	✅
Rum Recorder	20.03 KiB	20.01 KiB	-21 B	-0.10%	✅
Logs	56.14 KiB	56.14 KiB	0 B	0.00%	✅
Flagging	944 B	944 B	0 B	0.00%	✅
Rum Slim	121.62 KiB	121.62 KiB	0 B	0.00%	✅
Worker	23.63 KiB	23.63 KiB	0 B	0.00%	✅

🚀 CPU Performance

Action Name	Base CPU Time (ms)	Local CPU Time (ms)	𝚫%
RUM - add global context	0.0049	0.0056	+14.29%
RUM - add action	0.0137	0.015	+9.49%
RUM - add error	0.0128	0.0166	+29.69%
RUM - add timing	0.0027	0.0032	+18.52%
RUM - start view	0.0041	0.0036	-12.20%
RUM - start/stop session replay recording	0.0011	0.0008	-27.27%
Logs - log message	0.0198	0.0169	-14.65%

🧠 Memory Performance

Action Name	Base Memory Consumption	Local Memory Consumption	𝚫
RUM - add global context	25.75 KiB	25.99 KiB	+251 B
RUM - add action	48.31 KiB	48.56 KiB	+255 B
RUM - add timing	24.03 KiB	24.44 KiB	+421 B
RUM - add error	55.78 KiB	53.84 KiB	-1.95 KiB
RUM - start/stop session replay recording	23.54 KiB	23.98 KiB	+459 B
RUM - start view	426.42 KiB	422.10 KiB	-4.32 KiB
Logs - log message	44.58 KiB	44.28 KiB	-305 B

🔗 RealWorld

[datadog-datadog-prod-us1]

✅ Tests

🎉 All green!

❄️ No new flaky tests detected
🧪 All tests passed

🎯 Code Coverage
• Patch Coverage: 84.62%
• Overall Coverage: 77.25% (+0.01%)

View detailed report

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: f63d749 | Docs | Datadog PR Page | Was this helpful? Give us feedback!}

[sethfowler-datadog]

This method was called assign() for the old NodeIds and getIdForEvent() for the old EventIds, but it had the same behavior in both cases. I've renamed it to use the same name as the standard Map method that does essentially the same thing. I think this name makes the behavior a bit clearer than either of the previous names.

[sethfowler-datadog]

We need two variations here because strings cannot be stored in a WeakMap, since they're value types.

[gonzalezreal]

Looks good!
Just one question: What triggers clearing the ID mappings? (especially for StringIds which, as far as I understand, don't auto-GC)