RUM SDK: add more details on view lifecycle and beforeSend

[bcaudan]

What does this PR do? What is the motivation?

Document view event specificity to help customer integration with beforeSend

Merge instructions

Merge readiness:

• Ready for merge

For Datadog employees:
Merge queue is enabled in this repo. Your branch name MUST follow the <name>/<description> convention and include the forward slash (/). Without this format, your pull request will not pass in CI, the GitLab pipeline will not run, and you won't get a branch preview. Getting a branch preview makes it easier for us to check any issues with your PR, such as broken links.

If your branch doesn't follow this format, rename it or create a new branch and PR.

To have your PR automatically merged after it receives the required reviews, add the following PR comment:

/merge

Additional notes

[github-actions]

Preview links (active after the build_preview check completes)

Modified Files

• https://docs-staging.datadoghq.com/bcaudan/view-update/real_user_monitoring/browser/advanced_configuration

[janine-c]

Hey Bastien! I'm not a RUM expert, so I had some questions about the functionality we're suggesting here. If you could help me clarify these, that would be really helpful!

[janine-c]

I'm not clear about what behaviour the user would observe in the UI if they modified the view event content incorrectly (updating the view name?) or how this code sample is supposed to help users avoid that problem, or why the code sample is separate from the table that also contains information about view.name. Can we clarify this note to set expectations about what we'd like users to do more specifically? Happy to chat about how, if you'd find that helpful!

Suggested change

	**Note**: Unlike other events, view events are sent multiple times to Datadog to reflect the updates occurring during their lifecycle. An update on a previous view event can still be sent while a new view is active. So you should be mindful of this behavior when modifying the content of a view event.
	**Note**: Unlike other events, view events are sent multiple times to Datadog to reflect the updates occurring during their lifecycle. An update on a previous view event can still be sent while a new view is active. Datadog recommends being mindful of this behavior when modifying the content of a view event.

[bcaudan]

what behavior the user would observe in the UI if they modified the view event content incorrectly

with the view name discouraged example:

time	action	behavior
t0	user defines current view name to 'first'	getCurrentViewName returns 'first'
t1	sdk sends view 1	view 1 name is set to 'first'
t2	url changes
t3	user defines current view name to 'second'	getCurrentViewName returns 'second'
t4	sdk sends view 2	view 2 name is set to 'second'
t5	sdk sends view 1 update	view 1 name is incorrectly updated to 'second'

so in the UI, the view 1 will have the name 'second' instead of 'first'

why the code sample is separate from the table that also contains information about view.name

if you are referring to the Override default RUM view names section, it does not seem appropriate as:

• this section is not about modifying the event with the beforeSend API which is where a misconfiguration can occur if a user do not understand our behavior around view events
• all modifiable view attributes are concerned, not only the view.name

Can we clarify this note to set expectations about what we'd like users to do more specifically? Happy to chat about how, if you'd find that helpful!

This API allows users to update our behavior with their own logic so a bit complicated to tell them exactly what they should do 😕️
My intent here is more about clarifying our behavior in order for them to achieve what they want to do.
Maybe the team will have other ideas about to make that clearer as well.
Happy to chat more about it!

[janine-c]

Thanks! I appreciate that incredibly thorough explanation 🙂 I was referring to the table directly preceding this new content (under You can update the following event properties), but it's helpful to know that it applies to all view attributes, so disregard that.

That all sounds good - I usually worry that advising users to be mindful of something isn't clear enough, but if it's open-ended, I don't want that to be a blocker.