Proposal: await for an initalizer if it is async

[koresar]

ES6 is getting more widely used. The async/await syntax is now widespread and is becoming a feature supported by most JS environments. Let's think ahead and await if initializer is async.

const Stamp = compose({ initializers: [
  async function() {
    await someAsyncInitialization();
  }
]});

// or in stampit
const Stamp = stampit({
  async init() {
    await someAsyncInitialization();
  }
});

There is one thing to think about. What if all initializers are synchronous but only one is asynchronous? Should the entire stamp creation become async and return a Promise instead of an object instance?

[koresar]

This will add complexity and confusion. Let's KISS.

[sunwukonga]

If I have a prop that needs to be initialized from the network, what's the idiomatic way of waiting for that to complete without an async init()?

[koresar]

Hm. The question about idiomatic stamp way is the every second question. 😀

I usually answer "there is no idiomatic anything in stamps". But! This time I'll take another approach and will interrogate you a little.

In fact, stampit v2 (or 3?)used to support async initialisers. Unfortunately (or fortunately?) we had to drop this feature. Reasons: almost none used the feature, but the stampit library was insanely complicated because of it.

Good news is, you can make your initialiser async! And then the object instance creation will become async too. 'const o = await MyStamp()' With one caveat though. The async initialiser must be the least one added to the stamp.

May I wonder, what is the nature of the prop? Is it a configuration value?

On Wed., 15 Jan. 2020, 18:27 Paul Desmond Parker, notifications@github.com wrote:

If I have a prop that needs to be initialized from the network, what's the idiomatic way of waiting for that to complete without an async init()?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/stampit-org/stamp-specification/issues/120?email_source=notifications&email_token=AAMMELZ5JQLBJK4A4JHEV7TQ523EVA5CNFSM4FB3CVQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEI7KQ5Q#issuecomment-574531702, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMMEL4LBEOT7KADL3B7XKLQ523EVANCNFSM4FB3CVQQ .

[sunwukonga]

The context is the crypto ledger Stellar. I'm fetching an account (I'm really after a sequence number) and the current fee on the network on initialisation.

I can delay the initialisation of both until a method is called that needs them, and those methods can wait on a private initialisation method that fetches both. I favor this because I prefer not to worry about any future gotchas with stamp combine order.

[koresar]

I think you've picked the right solution. I do the same async init pattern from time to time.

My code is async have typically. And I found that async initialisers brought composition confusion and a number of gotchas.

(Fun fact. We, at FlashFX, have almost integrated with Stellar in addition to Ripple. But then had to pivot away from Stellar.)

[sunwukonga]

Not the place for discussion, but was the pivot necessary to comply with AFSL?

[koresar]

We have all the licenses needed. So, the answer is no. The pivot was more of a survival move.

On Thu., 16 Jan. 2020, 14:01 Paul Desmond Parker, notifications@github.com wrote:

Not the place for discussion, but was the pivot necessary to comply with AFSL?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/stampit-org/stamp-specification/issues/120?email_source=notifications&email_token=AAMMEL4LASDZ5N354CKHG6LQ57EYBA5CNFSM4FB3CVQ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJCS7TA#issuecomment-574959564, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMMELYIP3ZFEUC3PUBJMHLQ57EYBANCNFSM4FB3CVQQ .