/*
we can uninvert the inversion of control (i.e. take back control) by, instead of passing callbacks to our functions,
we have our functions return an event capability we will refer to as evt that receives callbacks
*/

function foo(x){
    //start doing something could take a while
    //make a `listener` event notification
    //capability to retunr

    return listener;
}

var evt = foo(42);

//let `bar(..)` listen to  `foo(..)`'s completion
bar(evt);

//also let `baz(..)` listen to  `foo(..)`'s completion
baz(evt);

/*
foo(..) expressly creates an event subscription capability to return back,
and the calling code receives and registers the two event handlers against it
One important benefit is that multiple seperate parts of the code can be given
the event listening capability, and they can all independently be notified of when
foo(..) completes to perform subsequent steps after its completion

Uninversion of control enables a nice seperation of concerns -
bar(..) and baz(..) don't need to be involved in how foo(..)
is called. Similarly foo(..) doesn't need to know or care that bar(..)
and baz(..) exist or are waiting to be notified when foo(..) completes

essentially, the evt object is a neutral third-party mediator
between the separate concerns

The evt object is an analogy for a Promise

In a promise-based approach, the previous snipped would have foo(..)
creating and returning a Promise instance and that promise would then be
passed to bar(..) and baz(..)
*/

function foo(x){
    //start doing something that could take a while

    //construct and return a promise

    //called the revealing contructor
    return new Promsie(function(resolve, reject){
        //eventually, call `resolve(..)` or `reject(..)`,
        //which are the resolution callbacks for the promise
    });
}

var p = foo(42);

// with this approach, bar() si callred regardless of whether foo(..)
//succeeds or fails, and it handles its own fallback logic if it's notified
//that foo(..) failed
bar(p);

baz(p);

// we pass the promise to bar(..)
function bar(fooPromise){
    //listen for `foo(..)` to complete
    fooPromise.then(
        function(){
            // `foo(..)` has now finished, so
            // do `bar(..)`'s task
        },
        function(){
            //oops, something went wrong in `foo(..)`
        }
    );
}

// ditto for `baz(..)`

//We can do this another way:

function bar(){
    //`foo(..)` has definitely finished so do `bar(..)` next
}

function oopsBar(){
    //oops, something went wrong in `foo(..)`, so `bar(..)` didnt run
}

//ditto for `baz()` and `oopsBaz()`

var p = foo(42);

//bar is only called if p succeeds, else oopsBar is called
p.then(bar, oopsBar);

p.then(baz, oopsBaz);

/*
Above, instead of passing the p promise to bar(..) and baz(..),
we use the promise to control when bar(..) and baz(..) will get executed, if ever
The primary difference is in the error handling

With this approach, bar(..) only gets called if foo(..) succeeds,
and otherwise, oopsBar(..) gets called.
*/