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.
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-430] new session strategy #343
✨[RUMF-430] new session strategy #343
Changes from 8 commits
6dbed1c
b5db9cb
34e43da
742d842
3ac7581
c07170f
d6546d7
88260f9
a0969e7
a1c550a
f96e1cd
b6c783e
3b732ab
b3e79c8
c5bb1e7
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
IMO
trackVisibility
should expose anObservable
instead of a callback functionvisibilityStateProvider
, usedocument.visibilityState
directly. We can mockdocument.visibilityState
in testsThere 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 advantage do you see with it?
How would you do that?
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 think having a common strategy to pass data streams around would make things more future-proof. For now, our Observable implementation is quite limited, but in the future it could be extendend with a "destructor" when unused (example), and we would have a common way to remove listeners and stuff. This would make functions like this more self-contained and easier to test.
But if you feel that this is thinking too far ahead, I'm okay to keep a callback for now :)
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.
About observable instead of callbacks, I am not sure that observable pattern should be enforce in every situation.
I think it:
But it also adds an extra layer of abstraction.
About future-proof arguments, let's see when we will have the need to do more complicated stuff with our observable and address it at this time.
In this case, I am not sure to see much benefit to switch to observable.