[You declare](http://devcenter.kinvey.com/html5/guides/concepts#Promises "You declare") to adhere to the [Promise/A+](https://promisesaplus.com/http:// "Promise/A+") implementation.



I would like to talk about:



> 2.2.6. then may be called multiple times on the same promise.

> 2.2.6.1. If/when promise is fulfilled, all respective onFulfilled callbacks must execute in the order of their originating calls to then.

> 2.2.6.2. If/when promise is rejected, all respective onRejected callbacks must execute in the order of their originating calls to then.



In the PayItForward JavaScript example, app.js, line 58 the code reads:



doc.on('click', '.logout', function() {

if(null !== Kinvey.getActiveUser()) {

var button = $(this).addClass('ui-disabled');



// Logout the active user.

Kinvey.User.logout().then(function() {

$.mobile.changePage(splash);// Redirect.

}, function(error) {

doc.trigger('error', error);

}).then(function() {// Restore UI.

button.removeClass('ui-disabled');

});

}

});



1. Kinvey.User.logout() returns a Promise

2. in the first **then** both onFulfilled and onReject callbacks are provided and none of them returns Promise

3. the second **then** defines only onFulfilled callback that.

4. according to 2.2.6.1 the second onFulfilled callback will be executed if the first Promise is fulfilled, that means if the user is successfully logged out the log-out button will be enabled again? That makes no sense.

Morning Daniel,



I'd respectfully disagree. The alternative would be to destroy and recreate the button which takes far more CPU / Memory operations to allocate / deallocate the same thing that's going to be reused. While I agree that the example itself could be more straight forward, generally speaking hiding / reusing frequently used items rather than destroying them is an extremely common modern design paradigm.



I suppose the better way to think of our implementation is something like a try/catch/finally in java.



try to do the code in the success,



catch the error state



and no matter what, re-enable the button so that it will function later.



Please let me know if you have any other questions,

"We need to re-enable the logout button as it's most likely being moved or hidden for later reuse in the DOM. "



If that is true then your promise implementation is correct but your example is not intuitive.



Thanks

Daniel,



To give you a quick idea of what's going on with this.



1. We click the logout button and disable it.

2. We then wait for the promise to give us back the outcome. If it's a success, great, if not, whoops.

3. We need to re-enable the logout button as it's most likely being moved or hidden for later reuse in the DOM. The example isn't really the greatest, but it is a valid implementation of the promise framework.



It's also noteworthy that Kinvey does not implement it's own promise framework, we have taken a very popular one and rolled implemented it exactly as is.



Please let me know if you have any other questions



Thanks,