Should we provide an await/async style from our SDK?

[marcelomorgado]

I'm wondering if some of our users will want to work with async/await syntax whenever it's possible.
If it makes sense, maybe we can have a function like:

try {
  const message = await action.waitFor("confirmation")
} catch(error) {
  // timeout, action failed, reorg, etc.
}

try {
  // will wait until 3 confirmations
  const message = await action.waitFor("confirmation", 3) 
} catch(error) {
  // timeout, action failed, reorg, etc.
}

try {
  const message = await contract.waitFor("Transfer")
} catch(error) {
  // timeout, action failed, reorg, etc.
}

[pcowgill]

Possibly. But

(A) If we do that, we'd need to articulate what other value we provide over using ethers.js directly.

(B) I'd also want to see what a properly written component would look like with that approach.

///
// in componentDidMount
///

try {
  // redux action for shipped request
  if (!requestShipped) {
    action.send()
    return
  }
  if (requestShipped) {
    const message = await action.waitFor("confirmation")
    // redux action for confirmation arrived
    return
  }
  if (oneConfirmation) {
    const message = await action.waitFor("confirmation", 2)
    // redux action for 1 + 2 confirmations arrived
    return
  }
} catch(error) {
  // timeout, action failed, reorg, etc.
  // redux action for failed request
}

// ...

// in render
// Show proper state based on requestShipped vs. oneConfirmation vs. threeConfirmations

Perhaps that would work. But really I guess the requests probably should be happening outside of a single component - related to tasitlabs/tasit-apps#265

Even if the app were just a single screen, I feel like users are less likely to code it the above way and more likely to await for the final state, whereas listening implies potentially needing to react to lots of things more than just once. Await is a better fit for a database wrapped with an API, because the API won't have as unpredictable behavior or take as long to process requests

[marcelomorgado]

B) I see. Yes, listeners seem to fit better with UI codes.
Maybe make more sense to avoid "callback hell" on high level nested calls?

[pcowgill]

Okay, cool. I'll wait to respond here re: callback hell until the discussion over here #369 (comment) is done

[marcelomorgado]

A) Hmm, good point. Our tools and packages combined are really valuable in helping devs to create apps from scratch and reducing the blockchain complexity. But this point deserves more attention, though.

[pcowgill]

A) Hmm, good point. Our tools and packages combined are really valuable in helping devs to create apps from scratch and reducing the blockchain complexity. But this point deserves more attention, though.

Agreed!