Bugzilla

I'm currently restructuring the async iterable code quite a bit (see bug 1788969, bug 1777145 and bug 1782400), and I'm hoping to add some documentation this week. After those changes land you'll need to make some changes to your implementation.

1) The data that you need to store per iterator should be in a `struct` or `class` named `IteratorData`, publicly declared nested inside the C++ class that implements the iterable (I think `ReadableStream` in this case)
2) `InitAsyncIterator` should have the signature `void InitAsyncIteratorData(IteratorData& aData, Iterator::IteratorType aType, [any arguments coming from the asynchronously iterable declaration, ]ErrorResult& aError)`. This needs to implement the *asynchronous iterator initialization steps*, probably setting members in `aData` in the process. 
3) `DestroyAsyncIterator` goes away
4) If the `IteratorData` holds things that should be cycle collected then it should have `void Traverse(nsCycleCollectionTraversalCallback& cb)` and `void Unlink()` methods to traverse and unlink that data.
5) The `AsyncIterableIterator<…>` has a `Data()` method for getting the data.
6) `GetNextPromise` should have the signature `already_AddRefed<Promise> GetNextPromise(Iterator* aIterator, ErrorResult& aError)`. This just needs to implement the *get the next iteration result* algorithm (it wasn't clear before, we used to also expect this to implement a big part of the steps for `next` in https://webidl.spec.whatwg.org/#es-asynchronous-iterator-prototype-object but not anymore). The code should resolve the promise that this returns either simply with the value (no need to call `iterator_utils::ResolvePromiseWithKeyOrValue`, which is going away, but just `Promise::MaybeResolve`) or by calling `iterator_utils::ResolvePromiseForFinished(promise)`.
7) If there is an *asynchronous iterator return algorithm* then the async iterable declaration needs to have a `[GenerateReturnMethod]` extended attribute in the WebIDL, and there needs to be a `Return` method that has the signature `already_AddRefed<Promise> Return(JSContext* aCx, Iterator* aIterator, JS::Handle<JS::Value> aValue, ErrorResult& aError)` and which implements that algorithm.

I hope I didn't miss anything. Do let me know if there's anything that doesn't work or that makes things difficult!

I do see that we might need to change the `GetNextPromise` signature to pass you a `JSContext*` again? I seem to have missed that when doing my changes.

I'm currently restructuring the async iterable code quite a bit (see bug 1788969, bug 1777145 and bug 1782400), and I'm hoping to add some documentation this week. After those changes land you'll need to make some changes to your implementation.

1) The data that you need to store per iterator should be in a `struct` or `class` named `IteratorData`, publicly declared nested inside the C++ class that implements the iterable (I think `ReadableStream` in this case)
2) `InitAsyncIterator` should have the signature `void InitAsyncIteratorData(IteratorData& aData, Iterator::IteratorType aType, [any arguments coming from the asynchronously iterable declaration, ]ErrorResult& aError)`. This needs to implement the *asynchronous iterator initialization steps*, probably setting members in `aData` in the process. 
3) `DestroyAsyncIterator` goes away
4) If the `IteratorData` holds things that should be cycle collected then it should have `void Traverse(nsCycleCollectionTraversalCallback& cb)` and `void Unlink()` methods to traverse and unlink that data.
5) The `AsyncIterableIterator<…>` has a `Data()` method for getting the data.
6) `GetNextIterationResult` should have the signature `already_AddRefed<Promise> GetNextIterationResult(Iterator* aIterator, ErrorResult& aError)`. This just needs to implement the *get the next iteration result* algorithm (it wasn't clear before, we used to also expect this to implement a big part of the steps for `next` in https://webidl.spec.whatwg.org/#es-asynchronous-iterator-prototype-object but not anymore). The code should resolve the promise that this returns either simply with the value (no need to call `iterator_utils::ResolvePromiseWithKeyOrValue`, which is going away, but just `Promise::MaybeResolve`) or by calling `iterator_utils::ResolvePromiseForFinished(promise)`.
7) If there is an *asynchronous iterator return algorithm* then the async iterable declaration needs to have a `[GenerateReturnMethod]` extended attribute in the WebIDL, and there needs to be a `IteratorReturn` method that has the signature `already_AddRefed<Promise> IteratorReturn(JSContext* aCx, Iterator* aIterator, JS::Handle<JS::Value> aValue, ErrorResult& aError)` and which implements that algorithm.

I hope I didn't miss anything. Do let me know if there's anything that doesn't work or that makes things difficult!

I do see that we might need to change the `GetNextIterationResult` signature to pass you a `JSContext*` again? I seem to have missed that when doing my changes.