Symbol.dispose

[ronag]

NodeJS is starting to add support for Symbol.dispose (before it lands in V8). Maybe would be a good idea to add support for this (when available) for the Subscription class?

[ronag]

@benjamingr

[benjamingr]

Spoke with @benlesh on the other issue about this. I think it's reasonable for Subscription to be disposable for starters :) That could offload all the "aggregating subscriptions and cleanup" work from RxJS to the standard.

Also cc @ronbuckton

[tonivj5]

I think you're tagging @rbuckton 😄

[voliva]

I don't fully understand how Symbol.disposable works - anyone would care to elaborate?

I can only find information about it on the TC39 proposal (which is hard to read for mortals), the TC39 repository, or on this article about how it will be available in Typescript 5.2

If I understood it correctly, this is useful for resources which need to be cleaned up whenever the scope of that resource is destroyed. A good example would be for file handles, from the TC39 repo:

// Without Symbol.dispose
function * g() {
  const handle = acquireFileHandle(); // critical resource
  try {
    ...
  }
  finally {
    handle.release(); // need to manually cleanup
  }
}

// With Symbol.dispose
function * g() {
  using handle = acquireFileHandle(); // block-scoped critical resource
  ...
  // handle is automatically cleaned up, the runtime calls `handle[Symbol.dispose]()` once out of scope
}

However, I don't see how this would work or help on RxJS regarding subscriptions. A subscription is not a "handle" of something that you would use and needs to be disposed off when no longer relevant.

I find it hard to find an example where this would be useful:

using mySubscription = source$.subscribe(value => /* do something with values getting pushed */);

I can't find a case where I would want mySubscription to get cleaned up as soon as it's out from any scope.

I can understand it for generators, or anything really where the actual resource (what you declare with using) has a purpose other than getting disposed.

Also I fail to understand how these can be composed or grouped together.

[rbuckton]

In the simplest terms, [Symbol.dispose]() would equate to subscription.unsubscribe(). However, disposables are useful for more than just using, and for more than just short-lived operations tied to a block scope. Disposables can be composed into other disposables, either by explicitly calling Symbol.dispose, or by using DisposableStack:

class Application {
  #db;
  #httpServer;
  #disposables;
  constructor() {
    using stack = new DisposableStack();
    // 1. open db
    this.#db = stack.use(openDatabase());
    // 2. create server
    this.#httpServer = stack.use(new HttpServer());
    // 3. listen for requests
    stack.use(fromEvent(this.#httpServer, 'request').subscribe(req => { ... }));
    this.#disposables = stack.move();
  }
  [Symbol.dispose]() {
    // dispose above operations in reverse order:
    // 3. unsubscribe from #httpServer's 'request'
    // 2. dispose #httpServer
    // 1. dispose #db
    this.#disposables.dispose();
  }
}

// elsewhere
async function main() {
  using app = new Application();
  console.log('Press ESC to stop server.');
  await new Promise(resolve => {
    waitForEscapeKey(resolve);
  });
}

// or just
const app = new Application();
process.on('SIGINT', () => app[Symbol.dispose]());

Having a Symbol.dispose method only implies that an object has a specific lifetime, and that cleanup will occur when that method is called. What that lifetime is will be determined by the consumer of the resource, be it a short-lived operation inside of a Block, or a longer-lived operation associated with some container. Subscription's unsubscribe() has the same meaning, and is also a very low-level API, meaning that there is value in them being composable. In fact, RX.NET's Subscribe returns an IDisposable, which is exactly the same concept: https://github.com/dotnet/reactive/blob/main/Rx.NET/Source/src/System.Reactive/ObservableBase.cs#L26

[benlesh]

Yes, we're going to implement this. Although the use cases are maybe thin, they do exist. And it's a small enough add.

Basically you could use it with use and an async function (or even an async generator or generator function) to have the subscription live for the life of that function scope. It's interesting, if maybe unintuitive for some.

async function addNumbersFromTwoUsers() {
  let otherUserValue = 0;
  using updatesFromOtherUser$.subscribe(value => {
    otherUserValue = value;
  })

  const userValue = await getValueFromCurrentUser()
  
  return otherUserValue + userValue;
}

I mean, that's a contrived example, I suppose... but again, it's a trivial add. It also makes our Subscription one of the more ergonomic primitives for creating a ubiquitous teardown for things.