-
Notifications
You must be signed in to change notification settings - Fork 144
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-1517] reorganise some components #2124
Conversation
Current dependencies on/for this PR:
This comment was auto-generated by Graphite. |
if it was domain logic, we should not use it on tools code
it had dependency on domain
since it manipulates RawError, it should be on domain
while it wraps a browser API, it is mainly used to control the execution flow
dependency on adEventListener and highly browser specific
69225ac
to
3c44e94
Compare
This reverts commit 3c44e94.
Codecov Report
@@ Coverage Diff @@
## main #2124 +/- ##
==========================================
+ Coverage 93.60% 93.64% +0.03%
==========================================
Files 178 178
Lines 5976 5976
Branches 1341 1341
==========================================
+ Hits 5594 5596 +2
+ Misses 382 380 -2
... and 1 file with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
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.
❓ question: I'm wondering what made you move timer.ts
in tools
? For me, this module is similar to addEventListener.ts
(provide safer or easier to use alternative to browser functions). Is it because setTimeout
is more "JavaScript-y" and addEventListener
is more DOM-oriented (thus "browser")?
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.
Yes, it is what I tried to express with:
while it wraps a browser API, it is mainly used to control the execution flow
Components needing to react to window or document events would most likely be under domain or browser directories.
For timer APIs, any component needing to perform asynchronous operation could need them and we have usage from various areas of the code base.
The main driver is that it would avoid to have some tools components depending on code outside of tools.
Motivation
Housekeeping + preventing potential cyclic dependencies
Changes
error
todomain
eventRateLimiter
todomain
runOnReadyState
tobrowser
experimentalFeatures
totools
timer
totools
Testing
I have gone over the contributing documentation.