5 ms·

AngularUI for AngularJS

• salimmadjd 14y ago
  Angular got me so excited about coding again in long a time, this now adds icing.
• paullth 14y ago
  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!
• lucidrains 14y ago
  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!
  • tanepiper 14y ago
    +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)
  • nicholasjarnold 14y ago
    Agree, thanks a lot for this. These videos are great!
  • salimmadjd 14y ago
    +1 for egghead.io every video tutorial should be this way
  • alexanderh 14y ago
    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.
• seivan 14y ago
  You guys might wanna take a look at Batman.js It does what angular tries to do. But without all the boilerplate crud.
  • sgt 14y ago
    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.
  • pkozlowski_os 14y ago
    @seivan, could you elaborate on what you mean by "all the boilerplate crud"? It is hard to see what you are getting at here...
• sgt 14y ago
  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!
• daveoh 14y ago
  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.
  • zwischenzug 14y ago
    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.
  • markdown 14y ago
    4s?
    • iso-8859-1 14y ago
      The iPhone 4S is a touchscreen-based smartphone developed by Apple Inc. It is the fifth generation of the iPhone, succeeding the iPhone 4.
  • patrickaljord 14y ago
    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.
• Geee 14y ago
  You guys should check out http://ngmodules.org/ http://ngmodules.org/ as well for other useful stuff for AngularJS.
  • pkozlowski_os 14y ago
    Yeh, the word about http://ngmodules.org/ http://ngmodules.org/ should be spread, hopefully it can be a repository of links to AngularJS directives.
• SchizoDuckie 14y ago
  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 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 14y ago
    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 https://github.com/jhiemer/angularjs-calendar Feel free to contribute!
• jameswyse 14y ago
  I'm very happy to see they've moved the bootstrap stuff out to a separate project!
• kseudo 14y ago
  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.
• btipling 14y ago
  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 14y ago
    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 14y ago
      > First off, I'm a developer, not a designer.
  • voidlogic 14y ago
    "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?
  • nwienert 14y ago
    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.
• heme 14y ago
  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 14y ago
    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 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 14y ago
      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 14y ago
        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.
• bluesnowmonkey 14y ago
  > Include the Internet Explorer Shiv A 'shiv' is a knife. Despite all its faults, IE never stabbed anyone.
  • parsnips 14y ago
    I think here IE is the intended victim.
• mandeepj 14y ago
  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
• tux1968 14y ago
  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 14y ago
    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 14y ago
      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.