Skip to content
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

Merged
merged 4 commits into from
Apr 3, 2020

Conversation

benlesh
Copy link
Member

@benlesh benlesh commented Aug 20, 2019

Refactors ReplaySubject, timeInterval, and timestamp to remove reliance on Schedulers that were not necessary. This should help drastically reduce the amount of code pulled in for default shareReplay usage or timestamp usage.

See commit messages for more details.

NOTE: Breaking change in that ReplaySubject will no longer have inherent observeOn behavior if provided a scheduler.

@benlesh benlesh requested a review from kwonoj August 20, 2019 14:28
@benlesh benlesh changed the title Replaysubject remove observeon Reduce scheduler footprint for default usage of shareReplay, timeInterval, and timestamp Aug 20, 2019
Copy link
Collaborator

@cartant cartant left a 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';
Copy link
Collaborator

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();
Copy link
Collaborator

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?

benlesh added 3 commits April 2, 2020 18:47
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.
@benlesh benlesh force-pushed the replaysubject-remove-observeon branch from f5c083f to 3c3d807 Compare April 2, 2020 23:48
@benlesh benlesh merged commit b2e67e3 into ReactiveX:master Apr 3, 2020
@lock lock bot locked as resolved and limited conversation to collaborators May 5, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants