Can I combine Twitter Flight with AngularJS? - angularjs

A couple of hours ago Twitter released Flight, a component-based framework for JavaScript. Its components are plain DOM elements and communicate through plain DOM events, which its really nice.
I just wonder... can I combine this with AngularJS? If I understand both frameworks correctly I can create "new" elements with AngularJS which could be use by and contain Flight components. And these components can be populated with data by AngularJS.
To put it another way: I could AngularJS like I normally would, but the directives are "decorated" Flight components. (Use Flight to create views and use AngularJS for everything else.)
Would that make sense? If not... I don't get the purpose of Flight :(

I understand you want to do the following: Decorate AngularJS directives with Flight components and Flight views.
You could probably create these Flight components within a directive and gain an advantage from the data-binding Angular offers. However, judging from the following:
"Flight enforces strict separation of concerns.
When you create a component you don't get a handle to it. "
It seems like Flight does not promote that you speak to these components via data-binding.
Furthermore, directives can be seen as components themselves already. And as for creating views, in AngularJS the DOM is already the view, what reason specifically would you have to use Flight views on top?
Also since the AngularJS is not subscribed to the events that Flight uses it has no way of knowing when the DOM has been modified (I am not sure of this please someone more knowledgeable correct me if I am wrong).
As for making sense. It does not look like Flight is meant to solve the same problems as Angular. I think AngularJS directives solve the same problem as Flight components, but offer a lot more.

Related

Using directives in real life angular app, are directives with controllers a right approach?

I know that this topic was discussed many times but I'm still not quite sure if I'm doing things right..
Many on-line resources embrace directives as a building blocks of the angular applications, in the same time many resources emphasize re-usability of the components. Anyway from my experience when I build typical app, there is not much things to re-use, usually each component has single role and it is used in the single place. As I understand angular, one of the main concepts is to provide semantic DOM, and in order to achieve that we can use directives. So when I build an angular app usually I create a set of directives and combine them in the views.
In my apps in the most cases all the DOM manipulation can be done using the build in directives. Most of my directives has a template and a controller, I do not need to use link function. In most of the resources in the internet I can read that I should use link function when creating directives. But this seems to be far more complicated code... . What is the benefit of the link function if I don't need any fancy DOM manipulations that are beyond build-in directives ?
tldr; I build my apps using directives with controllers and put them into views, is this a right approach ?
I've been developing in Angular over a year now on an enterprise level application and my team has gone by a standard of creating directives if you are using that same element more than once. It saves time, saves the DOM trouble, and makes it easy to create separate, testable pieces of code.
We've created directives for many listing items that use ng-repeat. Pretty much every ng-repeat we have is iterating over a directive to create true isolate scope in our elements' functionality. It's one of the most powerful features in AngularJS when done right and conforms to the standards of Object Oriented Programming where you can really make your applications use abstraction to the finest degree. Here's a wiki link on abstraction.

In mvc frameworks like angular is the html and CSS the "view"?

I'm a little confused about mvc frameworks for the web...take angular for example. Are the "views" in angular the (tweaked out) html and CSS and the "models" just javascript/json-like objects that contain data like regular Ajax data? It seems to me that this is how it is (maybe not in full detail, but roughly it seems like this is it). Does angular even use CSS? And I don't really understand the controller.
I know javascript to a degree where I am not a total beginner but these frameworks make no sense to me, it's like everyone is speaking Greek or something when I look up tutorials. It would help to know I'm sort of on the right track or whether my thinking is wrong, in a ballpark sense.
Help is highly appreciated. Thank you.
It sounds like you're on the right track. In Angular specifically, yes, the views are written declaratively in HTML and special tags and attributes called directives. Models can be anything; often you'll see examples in Angular that use plain JavaScript objects as the models, but in a more complex app you might have special objects that have methods specific to the application. Controllers are just there to tie the two together—they take the models and make them available to the view via the scope, and events (like ng-click) call methods on the controllers which make changes to the models.
AngularJS implements Model-View-Controller paradigm by connecting your HTML (views) to your JavaScript objects (models) via two-way data binding.
It extends HTML by providing directives that add functionality to your markup and allow you to create powerful dynamic templates. You can also create your own directives, crafting reusable components that fill your needs and abstracting away all the DOM manipulation logic. Like most JavaScript MVC frameworks, it lets you work with any server-side technology as long as it can serve your app through a RESTful web API.
You can find more info here:
http://www.angularjstutorial.com/
http://stephanebegaudeau.tumblr.com/post/48776908163/everything-you-need-to-understand-to-start-with
http://mrbool.com/mvc-in-angularjs/28962

Pros and cons of using AngularJS + jQuery Mobile in one project

We're about to start a project using mentioned libraries. We have already used jQM in another project, but coupled with Backbone. Now we're thinking about using AngularJS with jQM. Do you think it's a good idea? And if not, why?
To elaborate, the question is whether it is advisable/recommended/easy/beneficial to use these libraries together, or maybe there is something that should prevent us from using them both in one project. We don't want to spend half of project's time on making them work together just on principle.
AngularJS and JQM do different things. AngularJS is MVC + Lot More. JQM on the other hand is for direct UI manipulation (lower level than Angular). The good news is AngularJS is flexible and will let you work with any other Javascript framework including JQM. The recommended way of using them together is use the adapter as mentioned above or create your own reusable directives that will add "JQM nature" to your views. For e.g. you can create a directive that will convert a standard UL to a fancier JQM list. The good thing about doing this in directives and not within your view is that your UI code is separated in separate modules and not intermingled with business logic.

AngularJS: Is ng-click "a good practice"? Why is there no ng-{event} in AngularJS?

I just started to learn AngularJS and struggle with some concepts of AngularJS. It would be great if somebody could explain me some points...
I understand that ng-click is technically not the same as onclick (see here), but both are placed in the markup. I thought that would be a "bad practice"? Why is this one of the core concepts of AngularJS, if most people say this is "bad"? I thought it would be better to select the DOM element from JavaScript and not to place logic in the markup.
If ng-click is the right way to react to click events in AngularJS what should I do with other DOM events? I see that there are several other directives like ng-mouseover, but not all DOM events have a AngularJS equivalent. How would I handle a 'drop' event in AngularJS (hence in the AngularJS way - not the normal way)? To be clear: I want to drag a file into my webapp.
Thank you very much,
Pipo
Why is this one of the core concepts of AngularJS, if most people say this is "bad"?
Well, people who really like Unobtrusive JavaScript might say it is bad. Angularians (and those with a flex background) see value in the more declarative approach.
"Angular is built around the belief that declarative code is better than imperative when it comes to building UIs and wiring software components together... By declaratively describing how the UI should change as your application state changes, you are freed from low level DOM manipulation tasks. -- Overview doc
See also Don't the data attribute options used in Bootstrap, Angular.js, and Ember.js conflict with Unobtrusive Javascript principles?
what should I do with other DOM events?
Write your own directives to listen for them (or find one that someone else has already written). Angular gives you the power to extend what the browser can do -- by writing your own directives.
Update: in the comments below, Tim Stewart mentions AngularUI's ui-event, which lets you bind a callback to any event not natively supported by Angular.
By nature, Angular requires elements in the markup in order to function properly. Further, those elements must be "compiled" each time they change, for the most part. So, it's already somewhat "obtrusive" irrespective of the JavaScript. You can't simply replace the markup, and have everything auto-bound for you like you can with something like jQuery.
Strictly speaking, unobtrusive JavaScript:
1. separates structure and behavior, in order to make your code cleaner and script maintenance easier
2. preempts browser incompatibilities
3. works with a clean, semantic HTML layer
(Wikipedia)
That's not Angular, for sure. In order to achieve the two-way binding on everything, they chose to make custom binding points in the DOM, as opposed to using a class name or ID the way that jQuery would do. (A somewhat non-standard approach, but it obviously works.)
But the real way to think of it is this: Basically each controlled section of your markup is not really straight HTML anymore anyway. It's really more of a template now, and as such requires interaction with the engine that is preparing it for rendering. As such, the traditional rules of unobtrusiveness don't really apply... (FWIW, I'm a huge fan/user of the jQuery.on() function to bind elements to events automatically when the element is added to the page. Very clean and flexible, IMHO, and I do wish there was a similar mechanism in Angular. I like adding a class to items in multiple locations on the page that invoke the same event handler automatically. Having a single place to go change code is a good thing. but I digress...)
For me, the bigger issue is that of progressive design. Does the web page work without JavaScript enabled at all? Does anyone really care about that? Hmmm...

Backbone.js modular setup

I am new to backbone, and I'm here to ask for a little bit of help understanding how I would go about building my current webapp project. I'm developing a modular administration panel for servers. Every single "page" of the panel should be a packaged "module" including controllers, models and views.
The panel will consist of a main layout view being loaded initially, with a basic navigation. When a user clicks on a link on the navigation, a page gets loaded via AJAX into the layout.
(And if this sounds stupid / there is a reason not to do so please tell me :) )
Since others will develop these pages too, and since they are modular, I won't know what models, views and controllers I will be presented with inside the page i load via AJAX.
How would I best go about doing this with backbone?
I'm especially wondering about how I would extend Backbone models etc. dynamically, and how I would manage (for example) the user leaving the page and / or revisiting it later.
Does Backbone provide something I can work with, will I need to hack myself something together, is there a better way of doing things I am missing?
Your thinking around the problems sounds very correct. Make your UI components self contained as possible. Watch this 10 min video to get some more information on UI component best practices.
If you are interested about other important concerns of JavaScript application development, look at BoilerplateJS reference architecture which I published to share my experiences. That contains a similar sample application as you described (menu with component activation).
my recommendations for your UI component activation, deactivation are:
Do not remove/create DOM components. Reuse with hide/show, as your elements will recide in memory even after removing from DOM
Minimize keeping 'state' information on client side. When an user revisit the component, refresh it with a server call and then make it visible (use server as the single truth of state information).
See BoilerplateJS sample component implementations for more details. I know few who use it with BackboneJS (currently it ships with knockoutJS). We will ship a example of it using BackboneJS in v0.2 which is due in a week.
A common modular script loading framework that is used in conjunction with Backbone would be require.js. It might be what you're looking for. Require.js is all about AMD modules, asynchronous modules. Usually each model, collection, view is it's own module that defines the dependencies that particular module needs then loads those modules as needed. It's particularly well suited for large projects where you have lots of individual pieces that need to be mish-mashed together at different points of your application.
You could of course combine multiple backbone elements in a single module (usually I reserve this for Views and specific subviews that would only be used with the parent view) but it's really up to you.
With Backbone, usually the intent is to create single page applications - meaning all the page scaffolding is usually wrapped up as a single file and completely loaded onto the client-side at the get go. The data for each page is then called via ajax and populated as the user navigates and loads different aspects of the application. Is this what you intended in your description?
If you're looking to load different pages that are each individually grabbed form the server, then I'm not sure Backbone is the answer. There are other server-side MVC frameworks that help to accomplish that.
That generally touches on how Backbone is used for this sort of thing.
As for how to extend Backbone models and such, Backbone uses Underscore as a dependency and underscore provides a nice _.extend() function that can easily extend all your objects in pretty much any way you desire. Overriding default functionality, throwing in mixins, it's all pretty painless as far as Backbone goes. As a framework, Backbone is very agreeable when it comes to altering, modifying and customizing every little bit and piece.
As for handling users visiting and revisiting pages, Backbone.router allows you to create URLs that not only point to specific "pages" in your app but also to execute arbitrary code that needs to be executed to get there. Something like a logged in user visiting "mysite/#account" would trigger the router to load certain scripts that bring up that particular view as well as perhaps fetch() necessary data to get that view up and running for the user.
I'm not sure if there are resources out there that give you some kind of basic structure to start with. Most experiences I know of tend to go through the basic tutorials like "Todo List" and work their way up from there. I'm not sure what your experience level is with javascript or programming in general but I started with Backbone AND require when I knew really pretty much nothing. Only a vague notion of what JSON was and a low level understanding of HTTP as in, "it's that thing that gets web pages." That said, I think Backbone was really easy to get for me to start with and it's deepened my knowledge a lot about the whole client-side RESTful type app structure.
There is a really good list out there of the "Todo List" app in many different flavors such as Backbone and Knockout and some others. When deciding on a framework, I basically went through that code comparing all the different frameworks available and selected Backbone because it just seemed to make the most sense to me. I don't regret it. It's a lot of fun and I think the best way to get into it is to just try some demo tutorials.
Take a look at Marionette or Chaplin. Both are build on top of Backbone and provide a structured way to build larger application with Backbone.
Here is tutorial to organize your application as modules using backbonejs
http://backbonetutorials.com/organizing-backbone-using-modules/

Resources