chore: expose hasFinishedLoading

[devceline]

Changes

• bump version to 0.16.2 (patch)
• add new function hasFinishedLoading: Checks if watchSubscriptions has succeeded and finalized

Why

The response for watch subscriptions is sometimes received before notify client's init function has resolved.

Consumers of this SDK should be able to tell when notify client has fetched all subscriptions to show appropriate loading states.

[bkrem]

The response for watch subscriptions is sometimes received before notify client's init function has resolved.

Consumers of this SDK should be able to tell when notify client has fetched all subscriptions to show appropriate loading states.

• I understand the possible race condition here between init and watchSubscriptions
• Why is this currently screwing over expectations for SDK consumers? E.g. if awaiting init and init happens after watchSubscriptions has already completed, why is this throwing off loading expectations?

[bkrem]

What about the error case here? If we hit the JsonRpcError case SDK consumers will never see finishedInitialLoad === true

[bkrem]

Annoying I know, but could we add a comment here please to highlight why this flag is needed.

[devceline]

Making the boolean to true in error case as well for now, since it technically finished loading

[devceline]

The response for watch subscriptions is sometimes received before notify client's init function has resolved.
Consumers of this SDK should be able to tell when notify client has fetched all subscriptions to show appropriate loading states.

• I understand the possible race condition here between init and watchSubscriptions
• Why is this currently screwing over expectations for SDK consumers? E.g. if awaiting init and init happens after watchSubscriptions has already completed, why is this throwing off loading expectations?

In web3inbox, there is an outstanding PR to show loading state while subscriptions are loading in. The way we've been telling if subscriptions are loading in is the notify_subscriptions_changed event. However, we've noticed that sometimes that event is being fired before init is complete.

The problem is that we are attaching event listeners on("notify_subscriptions_changed" after init. So by the time we attach the event listener, the event has already been fired and we missed. Therefore, we can't know when subscriptions have finished loading in.

Alternatives considered was passing event (EventEmitter) to notify client and listening to it from there but it felt unncessarily hacky

[bkrem]

The problem is that we are attaching event listeners on("notify_subscriptions_changed" after init.

This was the piece I was missing, thank you 👍