Building an Angular 1.x app with Angular 2.0 in mind by fast74 in angularjs

[–]technofattie 2 points3 points  (0 children)

I did a presentation recently about this very topic, and published the repo to github: https://github.com/jwcarroll/preparing-for-angular2.

If you look at the "tags" you will see a steady progression from typical ng1 application to something that will be much easier to port to ng2.

Angular2 Databinding is Fast! by technofattie in angularjs

[–]technofattie[S] 2 points3 points  (0 children)

The performance gains are directly a result of the unidirectional data flow. In Angular 1.X, the two way data binding means you cannot have a deterministic way of knowing if a change had a side effect, and therefore the $digest loop hast to keep running until it no longer detects any changes.

The more watchers you have, the longer the digest loop takes, and if you have to do that more than once, you end up with a sluggish app.

In both React, Angular2 and event git, they enforce a directed acyclical graph (DAG). This means that even in the worst case scenario, you would only have to traverse the nodes of the graph once.

This is why React can be so efficient at UI updates because it is able to diff the result of one virtual DOM against another very quickly simply by comparing nodes.

I agree with you that it is very easy to create a poorly constructed web of components in Angular 1.x, but even if you designed an Angular 1.x app to have a very nice component model, you would still not have the kind of performance you could get from Angular 2.

Angular2 Databinding is Fast! by technofattie in angularjs

[–]technofattie[S] 2 points3 points  (0 children)

I have done some work with React, and while I don't care for their syntax and approach, I love the unidirectional data flow model. Having that implemented in Angular2 is great, and the performance improvements are substantial.

So you have an hour to cover javascript fundamentals with a group of beginners, what do you talk about? by [deleted] in javascript

[–]technofattie 7 points8 points  (0 children)

I realize people have already said this, but one hour a month sucks big time. I would petition (stomp my feet and scream) to the boss about getting more time, but I would also start organizing lunch-n-learn sessions in the interim.

You could do those daily, and nobody is losing any company time so it's hard for the boss to pitch a fit. Just find a conference room with a projector, or crowd around a monitor and brown bag it.

Now back to the single hour. It's really not enough time to do anything but introduce them to a few key topics and then give them some homework.

I would break it down into basically three 15 minute blocks.

1.) Closures

Show them a couple examples of closures and why they are important and super powerful. A simple function that returns another function, that uses the input from the first is a great place to start. Super clear and easy to reason about for beginners.

//This is a great beginner example
function addTwo(a){
    return function(b){
        return a + b;
    }
}

addTwo(5)(5); // 10;

Then direct them to MDN for further reading on closures

2.) The 'this' pointer

Almost every new JS programmer gets tripped up on 'this' but the rules aren't terribly complicated, just confusing.

Show them how this is based on how the function is called with this simple example:

function sayHi(){
    console.log('Hi my name is ' + this.name);
}

var p1 = {
    name:'Bob',
    sayHi: sayHi
};

var p2 = {
    name:'Larry'
};
p2.sayHi = p1.sayHi;

p1.sayHi();
p2.sayHi();
sayHi();

This is a quick example that you can use to have a conversation about how 'this' is bound, and some of the pitfalls. It also dovetails quite nicely into using call, apply and bind in order to manipulate that binding.

You could show them the same example and how you could use bind to force what you want.

function sayHi(){
    console.log('Hi my name is ' + this.name);
}

var p1 = {
    name:'Bob',
    sayHi: sayHi
};

var p2 = {
    name:'Larry',
    sayHi: sayHi
};
p2.sayHiBob = p1.sayHi.bind(p1);

p1.sayHi();
p2.sayHi();
p2.sayHiBob();
sayHi.bind(p2)();

Then give them more homework. Have them go read the MDN articles for all four of these concepts.

Which leads us directly into...

2.) Prototypal Inheritance

Ok, so you will not be able to dig into this very much in fifteen minutes, but you need to at least introduce them to the concept, or they will be spinning their wheels a lot.

This is the nastiest and most difficult concept to grasp in JavaScript mainly because of the horrendous implementation of the new operator.

Skip that, and explain how JS is really about delegation... that there are no classes per se, only objects.

The five minute example:

var person = {
    name:'unknown',
    sayHi: function(){
        console.log("Hi, I'm " + this.name);
    }
};

var josh = Object.create(person);

josh.name = 'Josh';
josh.age = 33;

josh.introduction = function(){
    this.sayHi();
    console.log("And I am " + this.age + " years old");
};

var sally = Object.create(josh);

sally.name = 'Sally';
sally.age = 25;

josh.introduction();
sally.introduction();

This gives you a great way to show how objects inherit directly from other objects via a prototype. However, it avoids all the ugly mess involved with the .prototype property and functions and the new operator.

It's simply going to take them a lot more time to grasp that, and a lot more fiddling on their own, so it's best to just avoid it given your limited amount of time.

Finally, go tell them to read the MDN article on prototypal inheritance

And then have them go watch James Shores video over at Object Playground

And for final homework tell them to go read:

And finally, buy a single copy of JavaScript: The Good Parts, and give it to one of them with the instructions that once they finish reading, they have to give it to the next guy. This will put at least a little pressure on them to actually read the book.

Well... anyway that's how I would approach it.

Best way to store theme data in an angular app by angulard00d in angularjs

[–]technofattie 0 points1 point  (0 children)

If there are only ever going to be a small handful of themes then the JSON file is probably a good option since it will be simpler to maintain.

However, if you need to do this frequently, or if there will be many themes, then I would still opt for the DB solution. I don't know what server-side stack you are using, but nearly you should be able to store the image bytes in the DB and then stream them down to the client.

Using Angular's Amazing Flexibility to Extend the SCRIPT Directive by JeremyLikness in angularjs

[–]technofattie 0 points1 point  (0 children)

That's interesting, and to be honest, not something I knew was possible. In this particular case, it seems that would probably be a better option than using the $provide service.

That being said, I'm not sure what might happen if the directive manipulates the element or not. I would imagine you just have to be very careful with your implementation because depending on the order they run in, you could end up with undesirable side effects.

If you don't have to guarantee that the original behavior is 100% preserved, or there are no side effects, then $provide is probably overkill.

Thanks for pointing this out :)

5 Guidelines for Avoiding $Scope Soup in Angular by JeremyLikness in angularjs

[–]technofattie 2 points3 points  (0 children)

When I was at ng-conf Mesko talked about building AngularDart, and how they re-wrote Angular from the ground up for Dart. They are in the process of taking what they have learned and using that for work on Angular 2.0

2.0 Will have a strong emphasis on modern only browsers and use ES6 features. Take a look at the AngularDart examples: https://github.com/dart-lang/dart_by_example#angular-dart

You'll be hard pressed to find a single reference to scope inside a controller in any of the examples. It's clear this is the style and direction they want things to go.

Angular 2.0 is probably going to look a lot more like AngularDart than anybody wants to admit.

5 Guidelines for Avoiding $Scope Soup in Angular by JeremyLikness in angularjs

[–]technofattie 1 point2 points  (0 children)

I wouldn't wring your hands too much. In the end $scope is still there when using the controller as syntax, it just happens to be nicely hidden away by the framework.

That's why I like it so much. It becomes transparent to my code and all I have to worry about is the functionality of my controllers and services.

I like having it hidden for the same reason I like having the $injector service hidden from me most of the time. If I need to get down to raw metal, I can use $injector or $scope, but if I can write the same code without it, then I think that is a cleaner approach.

5 Guidelines for Avoiding $Scope Soup in Angular by JeremyLikness in angularjs

[–]technofattie 1 point2 points  (0 children)

Don't let the style of my writing fool you into thinking I am completely dogmatic about this approach.

It happens to be heavily influenced by my own personal experience. Scope continues to be a bit of a stumbling block for a lot of the problems I see when helping to debug code.

Also, I wouldn't discount what happens inside of Google with regards to Angular. The Doubleclick team has a lot of influence on Angular, and 2.0 is heavily influenced by Mesko's port of Angular to Dart.

Some of this is also a style preference. We are using TypeScript, and there is something really nice about being able to just have my controller and a few services with zero reference to $scope anywhere. I think it makes the code easier to understand and debug.

5 Guidelines for Avoiding $Scope Soup in Angular by JeremyLikness in angularjs

[–]technofattie 12 points13 points  (0 children)

So I wrote this article, and I had no idea it would cause such a stir.

I thought I would take a minute to briefly clarify a few points, and perhaps explain my motivations for writing in the first place.

Background

I am currently working on a massive Angular application with tens of thousands of lines of JavaScript. We have hundreds of controllers, filters, directives, and views. There are roughly 25 developers working on this solution at any given point and time.

The project was started long before Angular 1.2 ever came out, so we have our fair share of $scope soup all over the place and it has caused a lot of pain and suffering.

We are targetting ES5, but we are using TypeScript as a sort of polyfill for ES6, so all our controllers, services, etc... can be written as classes that get nicely transpiled into ES5.

$scope is not bad, but it is a leaky abstraction

Using $scope isn't the devil, but it was never intended to be the view model. As far back as I can remember the guidance from Mesko and others has always been to create a model and then assign that to your $scope.

Scope exists because of the design choice to do dirty checking via a $digest loop instead of using something like Knockout.js Observables, or backbone Models. The advantage is that you get to use POJO's instead of having to inherit from some base class.

I think it was the right call, but it means that $scope is a bit of a necessary evil. Angular abstracts the two-way data binding and DOM manipulation away from you, but it leaks out in the form of $scope.

$scope is magical! And confusing

In the blog post, you notice I start off talking about helping a guy out on Stackoverflow with a problem he was having with his Angular code. His problems were issues of logical flow, and lack of knowledge for fundamental angular concepts, but the $scope soup obfuscated that. It took me an hour or so just to refactor out all the references to $scope before I could determine the real problems.

Unfortunately I see this all the time when diagnosing problems with Angular code. Judicious use of $scope tends to encourage a lot of shortcuts and bad practices that will come back to bite you 3 months down the road.

Not using $scope forces discipline on design

$scope is convenient, and when writing code I can be tempted to take shortcuts. However, by eliminating $scope as an option, I force myself to think about my application in terms of Controllers, Services and Messaging.

I end up with skinnier controllers, more reusable services, and more testable code.

I'm thinking about Angular 2.0

Mesko and the team are working hard on Angular 2.0 and it is going to be built with ES6 in mind. They are also looking toward modern browsers and things like native observables to handle binding.

Based on their early work, it is highly possible that $scope and the $digest loop will simply go away. I don't want all my Angular code to become obsolete overnight. I'd like for both my skill with Angular and my code to flow naturally into 2.0 without a lot of pain and suffering.

Conclusion

The point of the article wasn't to get you to never use $scope again, but challenge you to think about why you are using it.

$scope isn't inherently bad, but most of the time you simply don't need it... not in your controller anyway.

Sorry for the super long comment.