I have developed a small lib for the Dynamics CRM REST/ODATA webservice (CrmRestKit). The lib dependes on jQuery and utilizes the promise-pattern, repectivly the promise-like-pattern of jQuery.

Now I like to port this lib to bluebird and remove the jQuery dependency. But I am facing a problem because bluebird does not support the synchronous resolution of promise-objects.

Some context information:

The API of the CrmRestKit excepts an optional parameter that defines if the web-service call should be performed in sync or async mode:

CrmRestKit.Create( 'Account', { Name: foobar }, false ).then( function ( data ) {

   ....

} );

When you pass true or omit the last parameter, will the method created the record in sync. mode.

Sometimes it is necessary to perform a operation in sync-mode, for instance you can write JavaScript code for Dynamics CRM that is involed for the save-event of an form and in this event-handler you need to perform sync-operation for validation (e.g. validate that a certain number of child-records exist, in case the right number of records exist, cancel the save-operation and show an error message).

My problem now is the following: bluebird does not support the resolution in sync-mode. For instance when I do the following, the then handler is invoked in async fashion:

function print( text ){



    console.log( 'print -> %s', text );



    return text;

}



///

/// 'Promise.cast' cast the given value to a trusted promise. 

///

function getSomeTextSimpleCast( opt_text ){



    var text = opt_text || 'Some fancy text-value';



    return Promise.cast( text );

}



getSomeTextSimpleCast('first').then(print);

print('second');

The output is the following:

print -> second

print -> first

I would expect that the second appears after the first because the promise is already resolved with an value. So I would assume that an then-event-handler is immediately invoked when applied on an already resolved promise-object.

When I do the same (use then on an already resolved promise) with jQuery I will have my expected result:

function jQueryResolved( opt_text ){



    var text = opt_text || 'jQuery-Test Value',

    dfd =  new $.Deferred();



    dfd.resolve(text);



        // return an already resolved promise

    return dfd.promise();

}



jQueryResolved('third').then(print);

print('fourth');

This will generate the following output:

print -> third

print -> fourth

Is there a way to make bluebird work in the same fashion?

Update:
The provided code was just to illustrate the problem. The idea of the lib is: Regardless of the execution-mode (sync, async) the caller will always deal with an promise-object.

Regarding ... asking the user... doesn't seems to make any sense: When you provide two methods CreateAsync and CreateSync it is also up to the user to decide how the operation is executed.

Anyway with the current implementation the default behavior (last parameter is optional) is a async execution. So 99% of the code requires a promise-object, the optional parameter is only use for the 1% cases where you simply need a sync execution. Furthermore I developed to lib for myself and I use in 99,9999% of the case the async mode but I thought it is nice to have the option to go the sync-road as you like.

But I thinks I got the point an sync method should simply return the value. For the next release (3.0) I will implement CreateSync and CreateAsync.

Thanks for your input.

Update-2
My intension for the optional parameter was to ensure a consistend behavior AND prevent logic error. Assume your as a consumer of my methode GetCurrentUserRoles that uses lib. So the method will alway return an promise, that means you have to use the then method to execute code that depends on the result. So when some writes code like this, I agree it is totally wrong:

var currentUserRoels = null;



GetCurrentUserRoles().then(function(roles){



    currentUserRoels = roles;

});



if( currentUserRoels.indexOf('foobar') === -1 ){



    // ...

}

I agree that this code will break when the method GetCurrentUserRoles changes from sync to async.

But I understand that this I not a good design, because the consumer should now that he deals with an async method.