Angular 2 migration questions - angularjs

I'd like to prepare our codebase for Angular 2 migration as much as possible. I understand that there isn't a solid migration strategy yet but still, there are two issues that I'm concerned about:
Not using watches anymore.
Not using two-way bindings anymore.
Let's say I have a directive that I want to keep updated according to model changes. How can I implement it without watches?
What if this directive is an interactive element and I want the model to reflect its changes? How can I do that without two-way bindings?
(If you have any other such problematic scenarios on mind please let's raise them and let's try to find solutions.)

Since there isn't any pre-alpha version released yet we can only guess on how migrating could work. I found this article which helped me to understand the new concept a little better.

Related

What are the new features in Angular2 which are not in previous versions?

I have seen many articles regarding the changes in Angular2 . But I can't find much advantage in using Angular2. Can some one point out some new things that can be done using Angular2 which can't be done using the previous versions.
I know there are changes like $scope changed to this. I'm not asking for changes. I'm asking for new features that is in Angular2.
The TL;DR Version
Because ES6 is important to pick up, so no need for a custom dependency management system anymore. ES6 and Angular 1 together get ugly fast, as they together introduce a bajillion coding styles :(
Although the library is overall heavier, the architecture it uses (all component based) is a lot faster, lighter, and modular for a scalable application. See http://info.meteor.com/blog/comparing-performance-of-blaze-react-angular-meteor-and-angular-2-with-meteor
You receive (upcoming) Server Side Rendering, which enables fast initial load time and Search Engine Optimization (Yay!) See: https://github.com/angular/universal
You receive WebWorker friendliness, which makes your application able to "multi-task". See: https://github.com/angular/angular/blob/master/modules/angular2/docs/web_workers/web_workers.md
Shadow DOM is not fully inherited by Angular 2 yet, but I'm sure it will be. It has some support right now.
The whole concept of $scope is gone. You receive two way data binding with anything you put in your ES6/TypeScript class, but anything more you need to create a Observable or promise. Unfortunately, you can't just shove anything into the scope, digest, and WALAH! anymore.
And of course, all the cool stuff they mention on their website: https://angular.io/features.html
Hope that helps!
Support for different languages TypeScript, Dart, ES5, ES6.
Change detection is much more effective
Support for isomorphic applications where the same code can run on the server, the browser and a WebWorker in the browser
Moves more work to build time to reduce the time for the initial page load.
Simplified binding syntax
Improved DI
There are also lots of mostly smaller and tiny features that Angular2 doesn't (yet?) support which Angular 1.x does.

When should I use angular.component instead of angular.directive?

Angular1.5 provides us the new concept - Component, like an improvement for old element-directive one.
It would be nice to have clear distinction between them: when to use what.
There is explanation on official site for cases when we should use directive. But all could be covered by attribute-directive. Is there still place left for element-directive in new applications?
Differences between .component() and .directive()
Angular's Team release the last version for helping developers to migrate to Angular 2.
One of the implementation that helps is the .component() method. In fact in Angular 2 we talk much more about Components instead Directives.
Think about components like a small reusable thing that you can declare one time and share in all your applications.
The new .component() method is really similar the old .directive() but introduce some little differences that helps to adopt best practice. For example the link function is missing and you need to use a controller instead.
In this very helpful article by Aviv Ben-Yosef you can read more about the differences between .component() and .directive().
http://www.codelord.net/2015/12/17/angulars-component-what-is-it-good-for/
When To Use
If you want to migrate to Angular 2, use the .component(). So you can learn a very similar syntax to the new version and migrate very easily.
In short, use directives only when you need to manipulate the DOM elements and in other cases use components.
Yes you can use directive as element if your requirement requires it.

Why would you use lodash in AngularJS?

Simple enough question I think. I see people raving about it but I haven't seen anything on the "why" use it. It doesn't seem to me (from my naïve outside perspective) ng-repeat, if not in that nested layer do ng-repeat inside another. I looks like that it doesn't add functionality that angular doesn't already have—I'm sure I'm wrong—
I see the term "lazy loading" being used with it and it doesn't seem like it's that much easier after seeing there docs. What are some things lodash makes significantly easier in AngularJS specifically that I would make it work adding another lib to my project? And what can you do with it that you cannot with angular out of the box?
They're just not the same, and exist for distinct reasons. I think you already know what AngularJS works for, so about your questions:
What can you do with it that you cannot with angular out of the box?
Well, if you need to deal with several data in structures like arrays, objects or mixed/nested shapes, lodash will save you a lot of time and effort.
Maybe there's a lot of items in collections which should be presented to your client application in some particular way, you would have to write a lot of JS code in Angular controllers or services with out the aid of lodash.
If there's a lot of logic tied to your data structures and/or complex algorithms and coding workflow, go for lodash.
Lodash is a great tool, you can get some intro here and of course, just check out the API reference. You can use it at everywhere, either Angular or any other framework, and of course, also at Node too!

Specific suggestions on how to prepare for AngularJS 2.0?

I have an AngularJS 1.3 application that will I suppose eventually move to AngularJS 2.0. I've watched the videos from ng-europe and I understand there are many changes. As I expect development to continue with our AngularJS 1.3 code for the next 12 I would like to hear if anyone has any specific suggestions on preparing for 2.0.
My application is simple in that it creates no directives. In particular I would like to hear any tips on how I should go about creating controllers to get ready for them being very different in 2.0. Should I eliminate all references to scope in my controllers. Should I move everything to services?
I hope for some useful suggestions but of course specific ones so this question does not get closed.
Thanks
I think that so little has specifically been announced yet, and there's so much potential for it to change that it's a hard question to answer, e.g. check out this issue for an example of something quite fundamental that's likely to change since the ng-europe announcement.
Within my team we're trying to take the following approach:
Try not to use $scope (controller-as syntax).
Keep your controllers as light as possible by using directives to encapsulate UI functionality and services to deal with data models / API calls.
Use the new syntax for one-way binding where you don't need two-way binding. One-way binding will be the default for Angular 2.0.
Write some unit tests! It'll be much easier to do some significant refactoring if you have some confidence that your code will still work :).
Not only should that help with the move to 2.0 if / when that happens, but it should help your 1.3 apps too!

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

Resources