⚗️ Partial view updates — batch optimizations#4807
Draft
mormubis wants to merge 17 commits into
Draft
Conversation
Bundles Sizes Evolution
|
🎉 All green!🧪 All tests passed 🎯 Code Coverage (details) 🔗 Commit SHA: 6537cec | Docs | Datadog PR Page | Give us feedback! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
The initial partial view updates implementation (already on main) sends diffs via
batch.add(). Two inefficiencies: when the full VIEW is still in the current batch, intermediate updates add separateview_updateevents on top of it instead of replacing the VIEW in place. And when multiple updates land in the same batch, each one becomes a separateview_updateinstead of a single aggregate.Changes
batch.ts— addsflushObservable: Observable<{ upsertedKeys: string[] }>toBatch. Fires after each flush with the keys that were in the upsert buffer, so subscribers know exactly which entries were sent.startRumBatch.ts— refactored intocreateViewBatchRouterto make the routing logic unit-testable without the full batch setup. Two batch-level optimizations:If the current batch already has a full VIEW, intermediate updates replace it in the upsert buffer (
batchHasFullViewpath). Noview_updateemitted. Same as the non-experimental behavior.If the batch was already flushed, updates compute an aggregate diff from
batchBase(the last state the backend received) and upsert it under the same key. Multiple updates collapse to oneview_updateper batch.The router subscribes to
batch.flushObservableto advancebatchBaseand resetbatchHasFullViewonly when the VIEW was actually included in the flush — avoiding the sync-flush state race present in the previous approach.Test instructions
yarn dev, openhttp://localhost:8080enableExperimentalFeatures: ['partial_view_updates']to theDD_RUM.init()call insandbox/index.html/proxyOptimization 1 (no view_update emitted):
DD_RUM.setViewName('test')— update arrives while the VIEW is still in the batchwindow.dispatchEvent(new Event('beforeunload'))view_updateOptimization 2 (aggregate view_update sent):
window.dispatchEvent(new Event('beforeunload'))DD_RUM.setViewName('test2')— update arrives in a fresh batchwindow.dispatchEvent(new Event('beforeunload'))view_updatediff, not a full VIEWChecklist