We Keep Coding

Using a fetch promise synchronously

I need a synchronous function (it can be blocking).
I need to use Fetch, and when the promise is ready, I want to return it on the synchronous function.
Everywhere I look I can't find the answer.

I need a synchronous function
Unlikely.
(it can be blocking).
That is what synchronous means.
Long running blocking functions (including network operations) cause serious usability problems and should be avoided.
I need to use Fetch, and when the promise is ready, I want to return it on the synchronous function.
That is not possible.
XMLHttpRequest has a synchronous mode, although it is deprecated and should not be used.
You can activate it by passing false as the third parameter to open.
xhr.open("METHOD as string", "URL as strong", false);
fetch learned lessons from XMLHttpRequest and did not implement anything similar.
Learn how to deal with asynchronous code instead. The async and await keywords will let you write in in a synchronous style.

You can't block the main thread like this, the browser won't allow you(or nodejs, since I don't know which). There's no synchronous way to fetch like that. You can instead use async/await to have your code avoid callbacks. It's probably highly unadvised to do what you want to and there's a better solution, but I can't tell you much more because of lacking context.

Why is synchronous module loading in javascript that bad

I know that the synchronous ajax calls on the main thread are deprecated, but I still wonder why.
How do you archive this in asynchronous module loading: get('moduleDependency').foo(); ?
I would like to use this kind of synchronous calls at least in development to speed up the overall development circle. The modules are in production already concatenated into one file and will never touch the synchronous loading function at all.
My synchronous module loader (~80 loc) solves dependencies and more. I rewrote it to asynchronous loading, and it's working fine... but I'll have to give up using code like: get('moduleDependencie').foo();
And that's really a mess!
How do you get this kind of calls working with asynchronous loading? Or do I simply have to use asynchronous loading in cooperation with a while(true) function on the main thread in the future - until they ban while loops on the main thread also?

As long as the synchronous call isn't finished or a timeout isn't reached, there is no possibility for user to interact with the page. So it can hang up and in worst case the user has to restart his browser. Asynchronous programming and scripting is based on callbacks. You just have to bind a method to the success handler of the AJAX-Request. You can use
success:function(result){
//do something
}
or
success: myfunction
[...]
function myfunction(result){
//do something
}
Once the asynchronous code has finished, this method will be called. So put everything that works with the data from the AJAX request into this method.

How {async:false} works in jQuery AJAX request?

I know why and how to use {async:false} in jQuery AJAX request.
But what I need is how this works synchronously? What is the magic behind this?

Because the native XMLHTTPRequest object provides the possibility to make synchronous requests:
async
An optional boolean parameter, defaulting to true, indicating whether or not to perform the operation asynchronously.
You can assume that it does that by pausing the thread in which JS runs.

My best guess, is that when async is false, then it will wait until the readyState is set to DONE, which as defined by the W3, is:
The data transfer has been completed or something went wrong during the transfer (e.g. infinite redirects).
So basically when the request is completed, it will continue on.

Encapsulating Asynchronous Requests

I'm trying to create a small javascript framework that can make it easier when dealing with a third party library. This library is primarily asynchronous, so for example to establish a connection you would use the code:
var com = establishConnection("api-key");
com.onsuccess = function(c) {
c.submit("something");
};
What I want is to be able to use my wrapper framework to be able to simply do
var com = establishConnection("api-key");
com.submit("something");
Obviously though I need a way to handle the asynch nature of the original library, so it will wait until the connection is established before carrying out the commands. I know I can do something like set a flag to say whether or not the connection is established and then use some kind of looping delay, ie
function submit(msg) {
while (!connectionEstablished) {}
// do submit stuff
}
but it seems like such an ugly hack, does anyone have any advice for nicer ways to do this?

That would be the only way to convert an asynchronous request to a synchronous request.
Yes, it looks horrible, and ugly; because it is.
I know I don't know the full in's and out's of your library, but I would suggest you (and your users) should embrace asynchronous requests rather than trying to mask them. HTTP requests are asynchronous in JavaScript for a reason; they don't lock up the browser. Synchronous requests completely lock up the browser for the duration of the request. If you're not careful, if the HTTP request is too long, your users will get an alert on most browsers saying to them that the script has stopped executing; and offer them the option to disable the script.

When is it appropriate to use synchronous ajax?

I was just reading another question about jQuery's synchronous ajax call, and I got to wondering:
What circumstances make a synchronous version of an ajax call beneficial/necessary?
Ideally I'd like an example, and why synchronous is better than standard ajax.

The only reasonable example I can think of (that can't be worked around another way) is making a call in window.onbeforeunload, where you need it to be synchronous, or the page will move on and the request will never complete.
In this specific case using standard/asynchronous behavior, you're all but assured the request will die too early to have any impact, or ever contact the server.
I'm not saying I'm in favor of doing this, quite the opposite (as it negatively impacts the user's browsing speed). But...there's not much option here.

In sum, please do not use synchronous requests as #Brandon says: they are a cheap/easy/quick way to avoid making a callback. In addition, modern browsers show warnings if synchronous requests are made and we do not like that. Make your world asynchronous.

synchronous ajax is often used to retrieve a valued from the server which is required to further continue processing of client side code. in such case, the ajax call will block until the call returns with the desired value. example:
a javascript function needs to compute salary for an employee:
step1 : get the employee id from the form
step2 : make a sync server call passing the emp.id to get his salary/hour
step3 : multiply salary rate by number of working hours
as you can see, total salary cannot be computed unless the server call is finished so this should be a sync function, although if using jquery, one could handle onSuccess to compute the salary asynchronously but processing will continue in this if you have a message box to display the salary, it will appear empty...

I would venture a guess that it'd be good in a scenario where you want to perform some ajax calls but you have one call that relies on the results of another call. If you perform them synchronously you can wait for the independent to finish before the dependent call fires.