AngularUI for AngularJS(angular-ui.github.com)
angular-ui.github.com
AngularUI for AngularJS
http://angular-ui.github.com/
40 comments
In the top example blurCallback references the current $scope object, which is a powerful feature of AngularJS that helps keep things modular. In the second you are referencing a global blurCallback function, which is definitely a bad idea.
If you're talking about the general idea of binding events in HTML, they are the same, but combined with Angular's design the choice has a lot of advantages. From the docs (http://docs.angularjs.org/guide/concepts):
"The separation of the controller and the view is important because:
1. The controller is written in JavaScript. JavaScript is imperative. Imperative is a good fit for specifying application behavior. The controller should not contain any rendering information (DOM references or HTML fragments).
2. The view template is written in HTML. HTML is declarative. Declarative is a good fit for specifying UI. The View should not contain any behavior.
3. Since the controller is unaware of the view, there could be many views for the same controller. This is important for re-skinning, device specific views (i.e. mobile vs desktop), and testability."
If you're talking about the general idea of binding events in HTML, they are the same, but combined with Angular's design the choice has a lot of advantages. From the docs (http://docs.angularjs.org/guide/concepts):
"The separation of the controller and the view is important because:
1. The controller is written in JavaScript. JavaScript is imperative. Imperative is a good fit for specifying application behavior. The controller should not contain any rendering information (DOM references or HTML fragments).
2. The view template is written in HTML. HTML is declarative. Declarative is a good fit for specifying UI. The View should not contain any behavior.
3. Since the controller is unaware of the view, there could be many views for the same controller. This is important for re-skinning, device specific views (i.e. mobile vs desktop), and testability."
I'm not so sure; I have to agree with heme. "ui-keypress="{13:'keypressCallback($event)'}" seems a whole lot like the UI is specifying behavior (on key 13, call a function called keypressCallback). This is no different than [pseudocode] "onkeydown='if(e.key==13){ keypressCallback(e) }" with a slightly cleaner syntax, except that you're calling it on an arbitrary this instead of the window. It's just as dirty. The event bindings belong in the js, not the html.
In my brief experience with Angular the difference is that while you can do "ui-keypress="{13:'keypressCallback($event)'}" that is more of the lazy way of doing things. The benefit of using the View and the way it should be used is in a declarative form such that someone looking at the View can know immediately that some element has some interactive behavior attached to it, but the proper way is to abstract it via a directive so that you don't pollute your view with the imperative details.
So, instead of using
<input "ui-keypress="{13:'keypressCallback($event)'}">
where keypressCallback does a form submit or something, you would write a directive that is just "form-submitter" and you would have your DOM be
<input form-submitter >
So that way you can easily scan your view to see what elements have what behaviors, but not how.
And Angular also allows you to bind events within javascript and really that is what the "form-submitter" directive in this example would be doing as well, but it should not be happening in general within the view/dom.
Although many times it is too heavy weight to make a directive for everything, but that is where the scope concepts of Angular comes in as well as the controllers so that at least the functions that are being triggered are still more expressive as they are localized to the containing scope. So, for instance you could have a directive "my-form" which is just an enhancement of the standard html form. In my directive I can then define a "validate()" method which validates the inputs. So, instead of having a "form-validator" directive I can instead do:
<my-form> <input type="text" >
Because of the scoping rules of Angular it is generally easier to infer the behavior of the method that is being called as it is scoped to my-form and as long as you are playing by the best practices there is not any real concern for functionality within that method to leak outside of "my-form" thus maintaining the ability to look at the DOM and have a pretty good idea of what the application is doing without digging through javascript as well.
So, instead of using
<input "ui-keypress="{13:'keypressCallback($event)'}">
where keypressCallback does a form submit or something, you would write a directive that is just "form-submitter" and you would have your DOM be
<input form-submitter >
So that way you can easily scan your view to see what elements have what behaviors, but not how.
And Angular also allows you to bind events within javascript and really that is what the "form-submitter" directive in this example would be doing as well, but it should not be happening in general within the view/dom.
Although many times it is too heavy weight to make a directive for everything, but that is where the scope concepts of Angular comes in as well as the controllers so that at least the functions that are being triggered are still more expressive as they are localized to the containing scope. So, for instance you could have a directive "my-form" which is just an enhancement of the standard html form. In my directive I can then define a "validate()" method which validates the inputs. So, instead of having a "form-validator" directive I can instead do:
<my-form> <input type="text" >
<button ng-click="validate()"/>Because of the scoping rules of Angular it is generally easier to infer the behavior of the method that is being called as it is scoped to my-form and as long as you are playing by the best practices there is not any real concern for functionality within that method to leak outside of "my-form" thus maintaining the ability to look at the DOM and have a pretty good idea of what the application is doing without digging through javascript as well.
That makes more sense. I disagree with the general principle of defining javascript actions by using properties like "form-submitter" or "validate()". I think that there is more than enough room in html5 to define an entire application without writing attributes specifically for binding, but that's the point of Angular- being able to easily bind to a view, which you can't do easily otherwise.
Thanks for the explanation! That helped shed some light.
Thanks for the explanation! That helped shed some light.
It's not better. But Angular tries not to step on your toes by starting to interpret onblur attributes differently from how they are defined by standards (as other's have said, blurCallback resolves to different things in your examples).
As I understand, Angular is its team's vision on how browsers will natively support client-side apps in the future, in which case there will probably be a more streamlined syntax for such things.
As I understand, Angular is its team's vision on how browsers will natively support client-side apps in the future, in which case there will probably be a more streamlined syntax for such things.
[deleted]
You guys should check out http://ngmodules.org/ as well for other useful stuff for AngularJS.
Yeh, the word about http://ngmodules.org/ should be spread, hopefully it can be a repository of links to AngularJS directives.
Angularjs is amazing. If you are confused about transclusions, give egghead.io a try. The videos are short and digestable. PS. Thanks John for making the videos!
I agree. Lots of people seem skeptical about Angular. And it can be hard to wrap your head around.
It prescribes a lot of things in terms of how your application is structured. Some people come just looking to use one specific feature of angular and get overwhelmed by it all.
But I stuck it out, and got some apps working with it, and it truly is amazing. You do have to go "All-in" with angular, but once you do, its amazing. The way it glues your app together really does make you a better/faster web app designer.
It prescribes a lot of things in terms of how your application is structured. Some people come just looking to use one specific feature of angular and get overwhelmed by it all.
But I stuck it out, and got some apps working with it, and it truly is amazing. You do have to go "All-in" with angular, but once you do, its amazing. The way it glues your app together really does make you a better/faster web app designer.
+1 a great series of videos that goes through the basics without getting bogged down in verbose explanations (each video is less than 10m long)
+1 for egghead.io every video tutorial should be this way
Agree, thanks a lot for this. These videos are great!
This is the best-timed monday morning coding surprise Ive had for ages. I was just about to start looking for an angular calendar. Many thanks!
Wow. This page is amazingly slow on my 4s. Scrolling and zooming in take a few hundred milliseconds before they respond. I'm not sure if it's down to number of examples on the site but they may want to look into mobile performance.
It's a page full of JS UI widgets including the codemirror editor, google maps, a calendar, select2 and more all in one page. It's a demo page for devs to checkout on their desktop really, I don't think Angular is to blame here, with so many widgets on a single page it would be slow on mobile even with vanilla JS.
Funnily enough, my own angularjs project is slow - and often crashes the browser - on my android device...
I've never been able to work out why.
I've never been able to work out why.
4s?
The iPhone 4S is a touchscreen-based smartphone developed by Apple Inc. It is the fifth generation of the iPhone, succeeding the iPhone 4.
Not necessary to enjoy AngularJS - but I'll look into maybe using AngularUI for my next project. Right now I am using plain vanilla AngularJS along with jQuery and Bootstrap, and I've never been happier with web development!
I'm absolutely in love with the calendar component. Whoah.
There's a large (but a bit messy) example here: http://plnkr.co/edit/7FhBFN?p=preview
I love big examples like this for making choices about what the next big framework should be. It gives a real feel for how the framework behaves in real life. I must say, even with the custom tags and ng-parameters, this still looks very very readable and organized.
There's a large (but a bit messy) example here: http://plnkr.co/edit/7FhBFN?p=preview
I love big examples like this for making choices about what the next big framework should be. It gives a real feel for how the framework behaves in real life. I must say, even with the custom tags and ng-parameters, this still looks very very readable and organized.
Hi SchizoDuckie,
thanks for your comment! Because we did not have to much time the last couple of weeks, we put the calendar to github and would love to have some people to participate.
https://github.com/jhiemer/angularjs-calendar
Feel free to contribute!
https://github.com/jhiemer/angularjs-calendar
Feel free to contribute!
Angular got me so excited about coding again in long a time, this now adds icing.
What ever happened to progressive enhancement?
None of these elements work with Javascript disabled. Would sure be great to support simple clients and use Javascript features only to enhance the experience.
So many sites are becoming unusable without Javascript for seemingly very little benefit
None of these elements work with Javascript disabled. Would sure be great to support simple clients and use Javascript features only to enhance the experience.
So many sites are becoming unusable without Javascript for seemingly very little benefit
Any website using AngularJS already won't work with JS disabled. These are web "apps", not web sites. Therefore there is no need for progressive enhancement in the plugins used if that is what you meant. If you meant AngularJS altogether, it depends on your user base.
To expand on this point - you can build a site that both uses Angular and has a fallback to plain http methods. Forms can do full posts, links can actually link to things, etc. Angular doesn't preclude you from a progressively enhanced site - its's up to the developers using Angular (or any client-side framework) to build for plain server communication as a priority.
However, "Therefore there is no need for progressive enhancement" is also wrong - there is. That's why they use "title" for tooltips, a textarea for code boxes, etc.
However, "Therefore there is no need for progressive enhancement" is also wrong - there is. That's why they use "title" for tooltips, a textarea for code boxes, etc.
I don't mean to be too critical as this is pretty cool stuff, but that large calendar is not very good UX. The gradient behind the month, week day tabs interferes with the readability of those words and those giant red x buttons on the events are hideous and not even padded evenly. All I see are those x buttons, and the events aren't padded evenly also bold everywhere.
The tiny calendar then doesn't look anything like the big one, it uses an entirely different gradient and radius for the rounded corners and looks more like jQuery UI.
Like I said it's cool and I appreciate work like this, but a good UI should probably involve good UI fundamentals.
The tiny calendar then doesn't look anything like the big one, it uses an entirely different gradient and radius for the rounded corners and looks more like jQuery UI.
Like I said it's cool and I appreciate work like this, but a good UI should probably involve good UI fundamentals.
Funny you mention the calendar. First off, I'm a developer, not a designer. When I scrolled to the calendar demo and clicked around in it my initial reaction was 'wow, nice'. Honestly, I see the issues you mention on second glance after reading your criticism. However, I feel sometimes that the drive for pixel perfection is akin to a developer doing too much premature optimization...
> First off, I'm a developer, not a designer.
"but a good UI should probably involve good UI fundamentals."
That calendar is easy to fix with a little CSS, I have used it. Lack of pixel perfect polish in an example's styling = lack of UI fundamentals, really?
That calendar is easy to fix with a little CSS, I have used it. Lack of pixel perfect polish in an example's styling = lack of UI fundamentals, really?
Any decent designer who knows CSS could fix that calendar in a couple hours. Those minor UX details are easily fixable, the bigger picture is you're getting a usable calendar for free.
This looks awesome. Could anybody tell me how to render a angularjs-ui calendar using the jade rendering engine? I am a noob with node but I would like to know how I can use these components in a basic node app.
Folks who are complaining about AngularJS calendar can try calendar from dojotoolkit. It is really good.
http://demos.dojotoolkit.org/demos/calendar/demo.html
http://demos.dojotoolkit.org/demos/calendar/demo.html
I'm very happy to see they've moved the bootstrap stuff out to a separate project!
You guys might wanna take a look at Batman.js
It does what angular tries to do. But without all the boilerplate crud.
@seivan, could you elaborate on what you mean by "all the boilerplate crud"? It is hard to see what you are getting at here...
Angular has very little boilerplate crud - and when it does, there's usually a very good reason for it. Angular is meant for scaling up to very large web applications.
> Include the Internet Explorer Shiv
A 'shiv' is a knife. Despite all its faults, IE never stabbed anyone.
A 'shiv' is a knife. Despite all its faults, IE never stabbed anyone.
I think here IE is the intended victim.
Can someone explain why this:
is better than this:
I thought binding data/events in HTML was a bad thing. Is it just a matter of preference?