
AngularUI for AngularJS - eranation
http://angular-ui.github.com/
======
heme
Doing research for my first Single Page Application project. Angular seems
extremely popular, but something continues to confuse me.

Can someone explain why this:

    
    
      <input ui-event="{ blur : 'blurCallback()' }">
    

is better than this:

    
    
      <input onblur="blurCallback();" />
    

I thought binding data/events in HTML was a bad thing. Is it just a matter of
preference?

~~~
tristanz
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."

~~~
ajacksified
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.

~~~
enoren
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" >

    
    
      <button ng-click="validate()"/>

</my-form>

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.

~~~
ajacksified
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.

------
Geee
You guys should check out <http://ngmodules.org/> as well for other useful
stuff for AngularJS.

~~~
pkozlowski_os
Yeh, the word about <http://ngmodules.org/> should be spread, hopefully it can
be a repository of links to AngularJS directives.

------
lucidrains
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!

~~~
alexanderh
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.

------
paullth
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!

------
daveoh
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.

~~~
markdown
4s?

~~~
iso-8859-1
The iPhone 4S is a touchscreen-based smartphone developed by Apple Inc. It is
the fifth generation of the iPhone, succeeding the iPhone 4.

------
sgt
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!

------
SchizoDuckie
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.

~~~
jhiemer
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!

------
salimmadjd
Angular got me so excited about coding again in long a time, this now adds
icing.

------
tux1968
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

~~~
Mjoraq
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.

~~~
ajacksified
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.

------
btipling
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.

~~~
nicholasjarnold
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...

~~~
btipling
> First off, I'm a developer, not a designer.

------
kseudo
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.

------
mandeepj
Folks who are complaining about AngularJS calendar can try calendar from
dojotoolkit. It is really good.

<http://demos.dojotoolkit.org/demos/calendar/demo.html>

------
jameswyse
I'm very happy to see they've moved the bootstrap stuff out to a separate
project!

------
seivan
You guys might wanna take a look at Batman.js It does what angular tries to
do. But without all the boilerplate crud.

~~~
pkozlowski_os
@seivan, could you elaborate on what you mean by "all the boilerplate crud"?
It is hard to see what you are getting at here...

------
bluesnowmonkey
> Include the Internet Explorer Shiv

A 'shiv' is a knife. Despite all its faults, IE never stabbed anyone.

~~~
parsnips
I think here IE is the intended victim.

