-
-
Notifications
You must be signed in to change notification settings - Fork 5
SF-3532 Dispose realtime docs when no longer in use #3199
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
base: master
Are you sure you want to change the base?
Conversation
abf739b
to
db6ad5d
Compare
❌ 38 Tests Failed:
View the top 3 failed test(s) by shortest run time
To view more test analytics, go to the Test Analytics Dashboard |
9fcd8f8
to
74cce2c
Compare
e689f5d
to
9d7185b
Compare
e689f5d
to
7842d29
Compare
7842d29
to
b990402
Compare
5a61ab3
to
89e0fd9
Compare
simply doing `spy(await env.getQuestionDoc('q6Id'))` with ts-mockito spy results in later errors: > Error: Uncaught (in promise): TypeError: Cannot read properties of undefined (reading 'get') > TypeError: Cannot read properties of undefined (reading 'get') > at Spy.getEmptyMethodStub (node_modules/ts-mockito/lib/Spy.js:41:48) Perhaps more awaiting needed to happen first for something to be populated. Not being able to pin it down, there was instead success in moving to jasmine spyOn.
89e0fd9
to
d59fd6c
Compare
Hello @Nateowami , Thank you for your work on this! Here are some comments on the code. I find positive names to be easier to understand than negative names, when using boolean logic. I suggest to consider renaming Can you explain more about the use of Rather than provide DocSubscription.unsubscribe for situations where a DestroyRef|Observable was not provided to DocSubscription.constructor, do you think we could always require clients to do one of
It looks like if we removed DocSubscription.unsubscribe, and instead had clients pass an Observable, that might look something like // New client field
private readonly bye$ = new Subject<void>();
...
// Pass in constructor
new DocSubscription('DraftGenerationStepsComponent', this.bye$.asObservable())
...
// New client method
wave(): void {
this.bye$.next();
this.bye$.complete();
} I want to mention that we could further reduce the complexity of DocSubscription by changing the constructor destroyRef argument from new DocSubscription('DraftGenerationStepsComponent', this.destroyRef) to something like new DocSubscription('DraftGenerationStepsComponent', new Observable(subscriber => this.destroyRef.onDestroy(() => subscriber.next()))) That makes the client code more complex just to simplify DocSubscription.constructor by a couple lines, so I'm not too inclined toward it. But I wanted to mention that idea in case it inspires other ideas. Sometimes when working in TypeScript it seems like it could be useful to have a standard disposable system. In C#, there is an IDisposable interface, and implementing classes have a
In C#, the IDisposal.dispose method is automatically called if you are |
This is still work in progress, but I want to put it out here as it appears to be working.
This change is