@voltro/client 0.25.0 → 0.27.0

package/dist/index.d.ts

@@ -768,6 +768,30 @@ export declare const getMutationNotifier: () => MutationNotifier | undefined;
 /** Read the current feed. Newest-first; up to MAX_MUTATIONS entries. */
 export declare const getMutations: () => ReadonlyArray<MutationEvent>;
 
+/**
+ * Is this the loading baseline rather than a resolved api?
+ *
+ * The stub is deliberately *usable* — that is what lets a provider-less render
+ * proceed instead of crashing — so nothing about its shape says "not ready".
+ * Reads go through `LoadingSubscriptionCache`, whose `subscribe` is a
+ * non-fetching no-op, and that covers every hook that reads through the cache.
+ *
+ * A hook that instead forks its own fiber on `handle.runtime` has no such
+ * backstop, and gets a worse failure than a crash: `useEvent` retries a dropped
+ * subscription forever by design, so forking against the stub's client proxy —
+ * which throws on any call — is an unbounded retry loop, not a one-off error.
+ * Such a hook must gate on this instead.
+ *
+ * It asks about the CAPABILITY, not about object identity, and that is
+ * load-bearing rather than stylistic. `handle === ssrStubHandle` is the obvious
+ * spelling and it is wrong here: a host that loads a bundled copy of this
+ * package alongside this one — `@voltro/web`'s dist does exactly that — has its
+ * own `ssrStubHandle`, so the comparison answers "resolved" for a stub and the
+ * caller forks into the crash anyway. Asking whether the runtime can fork is
+ * true of every real runtime and false of every stub, in any number of copies.
+ */
+export declare const isUnresolvedApi: (handle: ApiHandle) => boolean;
+
 declare type Listener = () => void;
 
 /**