Use promises

[niemyjski]

I really like your library but I don't think it should be triggered by http requests (and as a result can't use it). It should use promises as then it's generic and can be used for many other things.

[grbsk]

Well, I wrote this specifically to use $http because that's what I needed. I am interested in other ways to hook ng-busy into various applications, but the first and foremost design imperative of ng-busy was to be declarative and unobtrusive.

I'm interested in hearing a more detailed proposal, as "use promises" as a general statement is kind of vague. My first thought is that you want a) an option to turn off the $http interceptor and b) to be able to use some sort of service so you can programmatically control busy state (since out of the box, there is no interceptor or similar approach for promises that I'm aware of where I could do this automatically). That's all fine and well, but if we're just doing all of this stuff programmatically, the value of ng-busy is somewhat diminished.

Either way, let me know more about what you were thinking and we'll see what we can do.

[niemyjski]

Here is a link to javascript promises: http://www.html5rocks.com/en/tutorials/es6/promises/ All angular http requests should return promises. You can then use this very generically as you can continue one http request with a second and chain them.. I ended up implementing something like this because I couldn't wait.

[iltera]

For that purpose there a very good project called AnyLoader. For your buttons, you can set different states with different contents in the promise success and error functions. You can change even the class of your buttons according to the loading, success and error states. In my opinion anyloader will satisfy your needs in that matter.

As for changing the logic of that project... I am very happy to find ngBusy and be able to use it in my projects. Intercepting $http requests make the button states reliable and realistic and in button loading indicator projects (for angular) that is the only project which use that logic AFAIK. @hackedbychinese should keep the project as is for the ones in the need of an $http interceptor and improve that project anyway possible without touching that specific feature 👍

[niemyjski]

Thanks for getting back to me. I'd rather use this library as it could support both scenarios with ease by just using promises (every thing is moving to a promise and while the promise is running things are busy). Secondly, I did a lot of looking and never came across that lib. Even so, I wouldn't use it because of all the extra configuration that's required per button.

[iltera]

I found AnyLoader recently, showed up in a google search for angular button loading indicators. As for the configuration, most of the settings are optional. You only need to define the classes and messages for your button states. When you create a global config and replace just the messages for the specific button, it really isn't that much of a config.

About your idea... I didn't try that, but can't you manually broadcast a busy state with the $broadcast sevice inside the success and error states? Hmm... But that would result in a change in the button state finishing the $http request and entering success function and change the button state again... (Writing out loud here)...

May be using ngBusy with promises is not a bad idea after all :) If we could manually disable the "busy.end" broadcast using a global config and disable the button's loading indicator in the promise success and error functions, that could work IMO. With a feature like that, ngBusy could be the best button loading indicator which covers most of the scenarios for angular.