AngularStrap - Bootstrap directives for AngularJS | Hacker News Reader

AngularStrap - Bootstrap directives for AngularJS

mgcrea.github.com

57 pointsxsace29 comments

looks nice, but one thing I really don't get is how

    <a ng-click="modal.saved=true;dismiss()">...</a>

is any different to

    <a onClick="thisIsAnAntiPattern()">...</a>

I'm all for declarative code but isn't stuffing javascript in html attributes something we learnt not to do about 10 years ago? Why the resurgence?

An interesting discussion about the difference between

  <a ng-click="modal.saved=true;dismiss()">...</a>

and

  <a onClick="thisIsAnAntiPattern()">...</a>

and why context / scope matters could be found here: http://www.bennadel.com/blog/2439-My-Experience-With-Angular...

thanks, that was interesting and it's obvious how it can be useful. but for some reason it still feels dirty.

onClick will be evaluated within the global scope, ng-click is evaluated within the scope of the controller. That's a pretty substantial difference.

Your HTML has to be hooked up to your controller somehow, I personally prefer angular's declarative approach rather than a big messy init method.

I think as one uses Angular more, a person will move most of their code out of `ng-click` style directives into their own components which might include click handlers on them.

That's the case, for me anyway.

This is an example for brevity but certainly misleading if you're not familiar with Angular. You're right that this is typically an anti-pattern, but it's one that Angular tries to eliminate, even though it is using a similar looking mechanism. Angular controllers expose an API for the widget they enclose, but it leaves the wiring up to the designer. Sometimes it makes sense to sprinkle event bindings onto the DOM via code, but there are many cases where it doesn't. My code almost never needs to know exactly what element(s) are bound to a method, so it makes sense to me to just declare that stuff right in the document.

As a side point, you can't evaluate arbitrary JavaScript in Angular attributes. Angular parses the attributes and evaluates them as in a JavaScript-like way, but with some exceptions. See http://docs.angularjs.org/guide/expression

Didn't we learn that static files for serving websites are so uncool many many years ago and stuffed the content into databases and served off them? And what is seeing a great resurgence these days?

More things change, more they remain the same.

PS: I am not saying JS in attributes is a good thing, but just that these things keep happening, for good or worse.

I'm pretty sure the linked site is using code inside ng-click directives for illustrative purposes. It makes documenting and demonstrating the project much easier.

This is a bit tangent to your question, but, I think you can still run with ng-click if you deploy Content Security Policy, whereas onclicks will be banned.

> I'm all for declarative code but isn't stuffing javascript in html attributes something we learnt not to do about 10 years ago?

And why?

Harder to test, of course.

A good thing that AngularJS is test friendly then

It seems to solve a very similar problem to Angular UI's bootstrap project: http://angular-ui.github.com/bootstrap/

Definitely similar problems, but in a somewhat different way. This library looks more featured than Angular UI Bootstrap, though in mostly small ways.

The popovers allowing external templates and custom scopes is one example, and the inclusion of navbars, date and time pickers instead of pagination, accordions and carousels is another.

If it works, I'd say I like it more than Angular UI's version, which is probably simpler to get up and running but something that you'd run into the limits of more quickly.

Yup. I guess the differenece is no dependency on angular-UI and it cuts straight to the bootstrap part.

UI Bootstrap does not depend on AngularUI. It's just a set of Bootstrap directives built by the AngularUI team.

The main difference between the two seems to be how they handle templates. UI Bootstrap has a set of default templates that can be overwritten, whereas AngularStrap doesn't. AngularStrap also includes date/time picker directives.

I don't believe ui.bootstrap actually depends on angular-ui, the project is just rolled into angular-ui's brand/github org. They could probably be more clear about that.

All three of them (angular-ui, ui.bootstrap, angular-strap) have been a pleasure to work with.

You are right, this project has _zero_ dependency on any other external JavaScript code. Those are native AngularJS directives.

ah, thank you for the correction.

Can we please stop posting links to this project? It's a really good example of how not to write Angular code.

The (official) AngularUI project has a much better solution (as has already been linked to in previous comments, but I feel the need to re-iterate): http://angular-ui.github.com/bootstrap/

(never having used angularjs, I am ill-equipped to judge) What makes the official solution much better than the one posted by the parent?

Considering every component provided by AngularBootstrap is tested, I think what you're saying is false.

Can you show us how they're wrong?

Just 4 things for a start:

1) Size and dependencies. Let's say you want to use buttons directive. If you decide to go with angular-ui/bootstrap you will need this https://github.com/angular-ui/bootstrap/blob/master/src/butt... only - 62 LOC. If you decide to go with Strap you will need jQuery + 100 LOC of Bootstrap's JavaScript + 163 LOC of Strap's wrapper (!!!). Please note that the the wrapper itself is _longer_ than the original version. Native version is 1/3 of the size (!).

2) Customization - try to change a template for say, a typeahead. With the strap solution it is hard-coded in Bootstrap's JavaScript, no way to customize. With angular-ui/bootstrap template is here: https://github.com/angular-ui/bootstrap/blob/master/template... and is fully customizable

3) Integration with the AngularJS ecosystem - since anngular-ui/bootstrap directives are native ones they seamlessly work with all the AngularJS goodies like $q promises. This means that you can provide a promise as a source for, say, typeahead or data for modal.

4) wrapping existing jQuery plugins is not always obvious as lifecycles are really different. As the results you need to do hacks - just search Strap's code for setTimeout and $timeout to see what I mean.

At the end of the day just choose a project that works for you but we've started angular-ui effort since we believe that native AngularJS directives offer much lighter and cleaner solution.

Compare the code yourself (should be an easy comparison) bootstrap alert widget

angular UI version https://github.com/angular-ui/bootstrap/blob/master/src/aler...

strap version https://github.com/mgcrea/angular-strap/blob/master/src/dire...

And more examples like this, unfortunately... Compare buttons for another striking example...

Just a wild guess (just looked at the first snippets quickly) but it looks like AngularStrap generate itself the html (for the dropdown for example).

It's not neccessary (bootstrap HTML is pretty straightforward) and it prevent you from doing a lot of things like custom html inside dropdown menus (icons, ni-click, etc).

So IMO, It abstract the things at the wrong level (too high)

AngularJS is very interesting, simple and powerful, but can anyone give some insights of how to properly use it for just a part of the website? I don't want to have JS only webapp, but to serve full server-generated pages. Or maybe it's wrong tool for the job?

It works just fine for that purpose. Just include angular.js and add an ng-app and ng-controller directive to a div you want angular to be concerned about and you're on your way. We are going to transitioning our javascriptMVC app over to an angular.js app piecemeal by following the same strategy.

We have been using it quite successfully for a interactive application. Independent of Angular Bootstrap we have made our own reusable widgets for common and generic components such as modals.

I actually haven't thought of using it for static pages but that poses an interesting experiment to try with my blog. It could bridge the gap often seen with non-interactive pages - mainly caching on S3+CF and yet wanting to pull in a Twitter feed.

Some things to mull on for sure.

Reply on news.ycombinator.com