Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Making angular-loading-bar be aware of 3rd party libraries using XHR requests by listening for events. #49

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

yagoferrer
Copy link

Added feature: Be able to fire start / end request events from non-angular 3d party libraries that also do XHR requests so that the loading bar it's also aware of these requests.

In case that you are using Angular in combination with non-angular 3d party libraries, you can now fire custom 'cfpLoadingBar:start' and 'cfpLoadingBar:done' request events.

Yago Ferrer added 3 commits March 1, 2014 06:50
@yagoferrer
Copy link
Author

This is useful to work with angular.js + oboe.js. It can also be achieved by adding start/done methods. I personally prefer events.

@rbutera
Copy link

rbutera commented Jul 22, 2014

this would be really useful for use with the Parse.com javascript SDK!

@matias-sandell
Copy link

Yes please!

@jturmel
Copy link

jturmel commented Aug 28, 2014

This seems like a great addition, actually needing it right now.

@ajhodges
Copy link

+1

@cspeer
Copy link

cspeer commented Mar 27, 2015

Let me give this a little bump +1
Is there any integration that works with parse.com js sdk? I would love to see that :)

@mattbrunetti
Copy link

@chieffancypants Are you interested in supporting this feature, if I resolve the merge conflicts?

@faceleg
Copy link
Collaborator

faceleg commented Feb 16, 2017

I don't use a 3rd party lib that does HTTP requests, I don't think @chieffancypants does either (so the motivation to merge and support this is going to be very low)

Also there are no tests in this PR proving that either the new feature does not break current functionality or that the new feature works as expected

@mattbrunetti
Copy link

@faceleg No tests here, true. I can write the tests for the new feature. The existing tests would prove that the new feature doesn't break current functionality, wouldn't they?

I think it's a pretty simple change, so it wouldn't be much extra to support, and it would add a lot of flexibility to this already excellent package. You would be able to use it when the user is waiting for, not just HTTP requests by 3rd party libs, but Web Workers, or requests over WebSockets. I'm sure there are other possibilities too. But it's up to you guys. If you're not interested I can figure something else out.

@faceleg @chieffancypants If I resolve the merge conflicts and add some tests, are you interested in this feature enough that you would review and consider merging?

@faceleg
Copy link
Collaborator

faceleg commented Feb 19, 2017

@mattbrunetti I'm interested yes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

9 participants