I want to highlight that the previous solutions cannot be implemented in situations where we lack control over async calls and cannot use callbacks, promises, or events to solve the problem. The async call might be a library function like setTimeout, making it impossible to apply the previous solutions to fix the flow.

Here is my unique solution:

Wrap the execution of doSomething(); in a setTimeout with an interval of 0 milliseconds.

$rootScope.$broadcast("postData");
setTimeout(function(){ 
    doSomething();}
, 0);

It's as straightforward as that!

By using setTimeout, doSomething() also becomes asynchronous, ensuring that both asynchronous operations occur one after the other. How does this work? Let me explain, but first, please note that doSomething() is inside a setTimeout set to an interval of 0 milliseconds. Some might assume that doSomething() would be executed immediately (after 0 milliseconds, although the default minimum time interval in JavaScript is actually 4 milliseconds) before the postData event is broadcasted and serviced.

The answer is no!

setTimeout does not guarantee that the callback function passed inside it will definitely be executed after the specified interval. The specified interval is just the minimum time needed for the callback to be executed. setTimeout is an asynchronous call, meaning that if there are any other asynchronous operations already awaiting execution in the pipeline, JavaScript will prioritize them.

To understand how all of this happens, you need to grasp the concept of the event loop in JavaScript.

JavaScript runtime is single-threaded, meaning it runs code sequentially as written. But how does it handle asynchronous tasks?

Here is what happens behind the scenes when the JavaScript runtime encounters an async operation (like an API call, HTTP request, setTimeout, or event broadcast). Please note that these functions are not provided by the native JavaScript runtime engine (e.g., Chrome's V8 engine) but by the browser itself (known as web APIs), which are essentially threads where you can make calls to initiate independent paths of execution separate from the JavaScript runtime flow.

A question arises: if the JavaScript runtime is still single-threaded, how do these web APIs interrupt runtime flow and provide their results upon completion? They cannot prompt the JavaScript runtime at any time with their output; there must be a mechanism.

JavaScript simply makes the call to these web APIs and does not wait for the call's output. It continues executing the code that follows the call while the dosomething() function in the problem gets executed before listening and serving the postData event.

In the meantime, the forked thread processes the HTTP request, setTimeout, or handles events depending on the type of async call made. When it finishes, the callback is pushed into an event queue (task queue) (Note that multiple callbacks can be pushed to this queue.). However, they are not immediately run.

The JavaScript runtime waits for the call stack to empty first. Only when there is nothing else for the JavaScript runtime to execute will the callbacks from the task queue be popped out one by one and executed.

In essence, if we make dosomething() asynchronous, it will be executed after the first async operation completes. That's exactly what I did: pushing the settimeout callback onto the event queue/task queue. The JavaScript call stack empties, the callback for the postData event broadcast is served, and finally, dosomething() gets its turn to execute.

It seems that the 'postData' broadcast signifies the completion of a function.

If you utilize the $q angular service, it becomes simple to achieve this by creating asynchronous functions.

function postData() {
  var deferred = $q.defer();

  //Perform your asynchronous tasks here for posting data

  //Once the asynchronous tasks are finished, you can either resolve the defer or
  //return data with resolve. Include the desired data as a parameter of resolve()
  deferred.resolve();

  //Return
  return deferred.promise;
}

Now, when you invoke postData, you can use the then method to execute doSomething() after postData() is completed.

 postData().then(function(data) {
    doSomething();
  }, function (err){
     //If your asynchronous function returns defer.reject() instead of defer.resolve(), you can handle the error here
  };

Here's the $q documentation in AngularJS

To illustrate a simple example, check out this plunk

Events don't work like that; you can't simply wait for events to finish.

Instead, consider triggering the 'postData' event and allowing the recipients to handle it in their own way. Then, wait for another event to occur before executing 'doSomething'.

This approach allows the consumer of the 'postData' event to complete its processing before firing another event. When you receive this subsequent event, you can consume it and perform your desired 'doSomething' action.