Should this be a directive instead of provider ? about ngprogress HOT 2 CLOSED

No, this should clearly be a provider and not a directive since we need to provide an API for the developer to use. If we were to use directives, we would need some sort of provider anyways.

Question and response from another place on the internet:

Generally it's not a good idea to manipulate the DOM from a controller, even via a service. In angular the idea is to set up the scope and let a directive do that work.

|
|

Yes, I know that very well. I got the idea after first seeing the Nprogress project[1] yesterday night and I figured I wanted it for Angular. I was unsure though on how I should implement it. A directive? Well, that would require the developer to do more to be able to change the progress-width/percentage. A provider manipulating a inserted directive? That would require more code.
This morning, I watched Misko talking about best practices regarding AngularJS[2] and he starts talking about that services often shouldn't contain dom manipulation but sometimes it's necessary. In this case, I thought it would be necessary. I think I made a good choice to make it as simple as possible.
[1] http://ricostacruz.com/nprogress/
[2] http://youtu.be/ZhfUv0spHCY?t=26m40s

from ngprogress.

I think this should be a provider plus a directive.

The provider will allow the user to configure the service and interact with the API and the directive will listen to events and showing the progress bar or whatever other behavior it has.

// config block
// interact with ngProgressProvider API
// add an http interceptor or something

// controller
// ngProgress.start
// or if hooked up to the interceptors just do your regular http calls

// html
<ng-progress-bar />

from ngprogress.