TransformAsync cancellation token?

[glen-nicol]

Is it possible to get a cancellation token attached to the underlying rx subscription from TransformAsync? Do I need to use Observable.FromAsync with some adapters to do it?

[JakenVeina]

You should be able to accomplish the same thing with Observable.FromAsync() and .TransformOnObservable() yes.

I'm not exactly against adding an overload that provides a CancellationToken to the transformer, but I'm honestly not keen to sit down and do it. Not with Observable.FromAsync() and .TransformOnObservable() as a very easy workaround. And that's roughly what we'd be doing under the hood anyway.

I wouldn't object to a PR for it, if you're so inclined.

[glen-nicol]

Sounds good, I will try to work that sometime soon.

[glen-nicol]

I am not finished, but curious about your take on this approach? I will cleanup documentation and add support for lists if you're okay with how I modified the internal class.

I realized that using TransformOnObservable and FromAsync is quick and dirty but doesn't provide a great means of concurrency control. So I opted to add it into the existing implementation to take advantage of what is already there.

[JakenVeina]

Looks roughly fine. A few points, though:

• I'm not sure what the need is to swap existing .TransformAsync() operators to use .TransformAsyncCancel() internally. If you've got a reason for it, feel free to explain in the PR. Otherwise, you should do your best to leave existing operators alone.
• If you can get away with just adding an overload to .TransformAsync() instead of adding a whole new .TransformAsyncCancel() operator, do that. But do check that it doesn't result in ambiguous method errors for consumers (assuming that's not already why you added the "Cancel" suffix").
• If you do have to stick with .TransformAsyncCancel() that should be a new sub-file off of ObservableCacheEx, as it's a unique operator name. Even if it's still using the same internal mechanisms as .TransformAsync().

why was this one Defer before instead of FromAsync all along?

Hell if I know. If all the tests pass, feel free to ignore it. If the tests DO reveal some reason that it works over .FromAsync(), go ahead and add a comment about it.

[glen-nicol]

you should do your best to leave existing operators alone.

I can revert most of the changes to the existing operators. But I have to change them anyways for the updated constructor to the internal class and so I figured it was a way to reduce duplicate code. Also, a way to prove the new overload works for the existing use cases by routing them through the new function.

(assuming that's not already why you added the "Cancel" suffix").

Yep, I had to add the TransformAsyncCancel overload for that exact reason, ambiguous reference when there are 2 lambda arguments without type declarations. I wanted to maintain compatibility with existing code. I'll move it to a separate file.