questions about `safeSend`

[Harry Solovay]

I came across safeSend while investigating #1514. It seemingly provides devs an alternative to try/catch, as they can discriminate between PendingTransactionStatuses.

If there were other members in this union (aside from "pending" and "rejected"), I would agree with this approach... however it seems there are at most two paths (happy path vs. error handling). This leads me to believe the JS-idiomatic handling within send is good enough.

try {
  await tx.send()
} catch(e: TransactionFailedError) {
  // recover ...
}

Are there more use cases for safeSend that I'm missing?

[Gregor Mitscha-Baude]

I think what you've outlined is all that safeSend() is doing.

The thinking was that in situations where you definitely don't want any errors to bubble up (i.e. UI components), it would be more ergonomic to handle the transaction status than to add your own try-catch block

[Harry Solovay]

While it would be nice to have any error data in a type-safe manner, this isn't standard in JS. I sure do wish JS had an effect system :/ if it did, I'd imagine a Rust-like try implementation in this situation.

// If this produces an error, yield that error to the parent block
let pending = await tx.send()?
// `wait` exists on the result of calling `send` bc error variant is no longer handled in this block
// – aka. it is typed as solely the successful variant
pending.wait()

Without an effect system, safeSend's return type would cause interruption to subsequent chaining.

Regarding your comment about use case:

in situations where you definitely don't want any errors to bubble up (i.e. UI components)

In the context of UI creation, I believe framework-specific libraries would offer better error handling solutions. For instance, a hypothetical react-mina library could provide a useTransaction hook, which would account for Suspense's approach to error+loading states + the canary compiler's SSR + hydration quirks.