-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Reduce scheduler footprint for default usage of shareReplay, timeInterval, and timestamp #4973
Reduce scheduler footprint for default usage of shareReplay, timeInterval, and timestamp #4973
Conversation
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.
LGTM. Just minor nit and an unused import.
@@ -1,5 +1,4 @@ | |||
import { async } from '../scheduler/async'; | |||
import { OperatorFunction, SchedulerLike, Timestamp as TimestampInterface } from '../types'; | |||
import { OperatorFunction, Timestamp as TimestampInterface, TimestampProvider, Timestamp } from '../types'; |
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.
Timestamp as TimestampInterface
does not appear to be used.
return (this.scheduler || queue).now(); | ||
private _getNow(): number { | ||
const { timestampProvider: scheduler } = this; | ||
return scheduler ? scheduler.now() : Date.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.
Is there anything to be gained by keeping the scheduler terminology in here? I mean, it could be a scheduler, but it's entirely possible it could be something else. Why not just use timestampProvider
as the name for the local const?
The aim here is to simplify `ReplaySubject` by removing a unnecessary feature that pulled in a lot of scheduler code via `QueueScheduler` and `ObserveOnSubscriber`, which in turn pulled in `AsyncScheduler`, and a lot of other related code. Instead, we're going to pull in a new, smaller `TimestampProvider` type, that simply has the necessary `now` method on it, meaning that `Date` or `performance` could be used as arguments to the `ReplaySubject` constructor. BREAKING CHANGE: `ReplaySubject` no longer schedules emissions when a scheduler is provided. If you need that behavior, please compose in `observeOn` using `pipe`, for example: `new ReplaySubject(2, 3000).pipe(observeOn(asap))`
Refactors timestamp to accept a `TimestampProvider`, which is any object with a `now` method that returns a number. This means pulling in less code for the use of the `timestamp` operator. Also removes unecessary internal class `Timestamp` which could have just been an interface that we already had.
f5c083f
to
3c3d807
Compare
Refactors
ReplaySubject
,timeInterval
, andtimestamp
to remove reliance on Schedulers that were not necessary. This should help drastically reduce the amount of code pulled in for defaultshareReplay
usage ortimestamp
usage.See commit messages for more details.
NOTE: Breaking change in that
ReplaySubject
will no longer have inherentobserveOn
behavior if provided a scheduler.