Show HN: ngProgress - slim, site-wide progressbar for AngularJS, without jQuery | Hacker News Reader

Show HN: ngProgress - slim, site-wide progressbar for AngularJS, without jQuery

victorbjelkholm.github.io

142 pointsdiggan35 comments

This is a Angular provider I've created after seeing NProgress[1] but I didn't want the jQuery dependency and I also wanted it for Angular so here it is.

Please comment if you see I'm doing something superstrange in the code or if you have any suggestions. I'm eager for your feedback!

[1] http://ricostacruz.com/nprogress/

Wow, this is cool. The first thing I thought when I saw http://ricostacruz.com/nprogress/ (submitted earlier) was how much effort to port/implement it to/in AngularJS. And you did it!

Sorry for nitpicking: (1) I think the color is too strong, (2) At one time (I don't know what I did), the progress bar went 50% but centered instead of left-aligned (but still on top), unfortunately I can't reproduce it, and (3) While trying to reproduce the bug, I encounter another bug where it won't stop if I click "Start progressbar" repeatedly.

Thanks for the cooleness mention, always makes me smile! I thought the same thing and started thinking about a port. Then I discovered that is was simpler to just skip the jQuery part and use Javascript only instead.

1, you can use whatever color you want. Either you call progressbar.color() with an HTML valid color or you use the provider like this:

    app.config(function(progressbarProvider){
        // Default color is firebrick
        progressbarProvider.setColor('firebrick');
        // Default height is 2px
        progressbarProvider.setHeight('2px');
    });

2, I will have to look into that

3, and the same with this bug

Thanks a lot for checking it out and telling valuable feedback!

One difference from yesterday's example is that it will get to 100% without 'complete' firing.

Yeah, I'm not sure that the progressbar should disapear just because the width is 100% because the loading still can be unfinished. Therefore you should always call progressbar.complete() after the loading is done.

Please let me know what you think would be best.

I think you missed a subtlety of nprogress, where it never fills the last 10 (or so) pixels unless complete is fired, presumably so that it doesn't make you think loading is finished until it's really, really finished.

Oh, yes, I totally missed that and that seems very reasonable actually. I've now changed (commit 34e3c16 http://git.io/4MeJNg) so the start-method will stop at 95% instead of stopping at 100%.

One technique that I used when building my own progress indicator is using a maths function which approaches 0 as the progress bar approaches 100% and use the result to increase the progress.

That way, the progress bar appears moving slower and slower but never actually hits 100%. I think that's better than having the progress bar completely stalled at 95%. See code here: https://github.com/buunguyen/rainbow.js/blob/master/src/rain....

Would be good to have a real-world example, like a progress for $http, or loading data... I am trying to swap angular-app's spinner with this, but it works with $http.pendingRequests (the less, the more advanced the progress should be).

Hmm, I will work on some realworld examples, for sure. Mainly it's for faking the progress so the user can see something instead of seeing nothing which means you call progressbar.start() before the request and progressbar.complete() when the request is done.

But I will for sure look into using ngProgress with $http and $resource to see if I can make the swapping easier.

Thank your for making a proper AngularJS directive and not just some shim-wrapper for an existing JQuery component. I wish this was more the standard than the exception with AngularJS components. Let's move foward!

Except it's not a directive but a provider! But thanks and I absolutely agree, more ports to native Javascript instead of using jQuery in Angular!

Wow....what are the odds of this! I literally just came on here to find the site wide progess bar submitted earlier so I could implement it in angular and this shows up! Thanks a lot!

Haha, not so small since this place is filled with smart people!

Thank you for checking it out!

I had a ton of trouble a few months ago to create a reliable global loading indicator for all requests in Angular, this doesn't seem to implement that, correct? One would have to explicitly call p.start() as the installation says, I wonder if that global intercept is more doable nowadays?

There does exist a suggestion somewhere in the google groups (that later became a gist/drop in directive) but with the new versions Ng IIRC it broke and threw me off during my tests.

Has anyone figure out how to use this when switching between views?

If you take a look at this video: http://www.youtube.com/watch?v=P6KITGRQujQ and associated tutorial, it will give you an example of binding to the RouteChange events for exactly this use case.

Can you show how you are using the views? Are they directly in the body?

Similiar to the foodme example app (https://github.com/IgorMinar/foodme/blob/master/app/js/app.j...).

Did anyone said awesome? Well, I will: Awesome.

Indeed! I saw this project yesterday and started wondering how I could get it into an Angular app. Thanks for saving me the trouble!

Hehe, I was in the same situation and dedicated my night to replicate it into a Angular provider.

Upvote usually means it, so lots of people did already! ;-)

Haha, you're so right and that makes me happy as hell!

Well, that means a lot to me so, thank you so much!

Dang! I was about to release something for AngularJS as per my comment yesterday on NProgress.. You beat me to it! Great job!

Yeah, I'm eager to start using it in our application as soon as possible so figured I needed to develop it as soon as possible!

Thanks!

This would be easy to recreate without the need of Angular or jQuery...

Yes! Absolutely! Just take the part in the this.$get on line 20 and move it into it's own object and then you won't need Angular anymore.

Why it's a provider for Angular is simply because we're using Angular for work and my primary goal is to use this for our application while doing synchronizations and fetching external resources.

In case you're interested, I built one that doesn't use Angular or jQuery: http://buunguyen.github.io/rainbow.js/

The most interesting thing for me about the frameworks is how they all use different methods of rendering the bar itself.

So far I've seen straight css, canvas, and css transitions.

Oh my God. I don't have the vocabulary to tell you how much this sickens me. You don't have to do something just because Google does it. Focus on speed instead of shitty non-features that lambda users will find misleading.

No, thank god I don't copy everything Google does. Of course you should focus on speed when doing some external resources, you sometime don't have the means to control how fast something is.

But I agree that you should focus on speed first instead of just placing a progressbar because something is slow.

Sickens?

I think it's kinda cool... Not sure if I'd like to see it on every page from now on, though.

Agree that it shouldn't be used on every website. I think the use case would be when you are doing heavy processing or waiting for external resources. Not like Medium is using it, when loading a new article with only text.

Reply on news.ycombinator.com