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
Move mutator interfaces to a separate service #25296
Conversation
31b7ec9
to
5f1351a
Compare
01b7e7d
to
fba17df
Compare
fba17df
to
0d66374
Compare
Hey @gmajoulet, these files were changed:
Hey @newmuis, these files were changed:
|
c18bbef
to
c617e95
Compare
c617e95
to
2edc325
Compare
/** | ||
* Schedules the work pass at the latest with the specified delay. | ||
*/ | ||
schedulePassVsync() {} |
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.
@dvoytenko I'm wondering why we have schedulePass & schedlePassVsync. why do we need to batch in 2 different ways?
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.
At this point it might be unnecessary. Initially this code likely dealt with inconsistencies with multi-browser event/rAF scheduling.
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.
Got it, created a clean up task to track: #25793
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.
please do some manual testing with extensions that uses mutators in different environments.
This PR moves the implementation of mutator functions into a separate service. Behaviors that are different are:
I believe it is okay, because all mutation requests start from mutator-impl. If mutator is not loaded, this logic should be a no-op anyways, so it does not alter the behavior.
Added new public interfaces to resources-interface that are intended to be used by mutator only for the sake of refactoring. Plz take a look at that. It also is the cause of the bundle size increase.
How should we deal with InaboxMutator? Do we want to run an experiment? I splitted InaboxResources as well, should it be kept on a separate PR?
Maybe it is also a good idea to move changes to use resources to mutator in a separate PR?