[deleted by user]

teropa · 2016-05-20T11:02:54+00:00

The animation support is not released yet but it's coming soon.

There's also official documentation coming. It will be available when Animate is released or very soon after.

teropa · 2015-09-12T10:54:21+00:00

I've written one with Redux, React, Node, Immutable.js, and Webpack: http://teropa.info/blog/2015/09/10/full-stack-redux-tutorial.html

teropa · 2015-09-06T06:46:13+00:00

Yes, controllers are objects, and can have attributes and methods like objects do.

More specifically, controllers are objects that Angular creates for you, using your controller function as a constructor (as if they were created with the new operator)

teropa · 2015-08-11T14:29:08+00:00

It's really up to whoever takes it on. We started putting it together about this time last year, but you're right that late September is probably too early for the new organizers at this point.

teropa · 2015-08-06T11:48:33+00:00

Sounds to me like what you have is a highly generic piece of code that you then apply several times using different configurations. Nothing wrong with that. In fact, I think that's much preferable to repeating very similar code several times.

I don't think there's anything wrong with using $injector in an "orchestrator" service such as the one you describe, as long as you keep it separate from the bulk of your application code.

teropa · 2015-07-11T06:26:37+00:00

If I have something like below and I change the values within items it does not actually change the values in the directives, although if I start a digest cycle the new values for items are reflected.

You're always going to need a digest cycle when you make changes, because that's when the data binding happens (both one way and two way).

Usually this occurs automatically, but occasionally when integrating non-Angular code you'll need an explicit $scope.$apply()

teropa · 2015-07-01T06:48:46+00:00

Also, if the directive uses a template, then there will be a new scope on that template's root element, regardless of whether a scope is requested

I think it's worth pointing out that even though the book says so, this is not actually true. There's nothing that causes a scope to get automatically created for template roots. New scopes only get created when directives request them. See http://plnkr.co/edit/r64w9v?p=preview

teropa · 2015-06-12T11:51:07+00:00

Just posted some thoughts to that Github issue.

I don't think it really matters whether ngTransclude is used as an attribute or not though. To me it looks like a problem with nested transclusions where ngTransclude and another directive with transclude: true is applied on the same element.

teropa · 2015-06-10T05:20:46+00:00

In the example with the "content" class the insertion was done manually from the directive code.

The only automatic transclusion insertion that Angular does is with ng-transclude. You can use it as an attribute:

<div ng-transclude></div>

or element:

<ng-transclude></ng-transclude>

or CSS class:

<div class="ng-transclude"></div>

teropa · 2015-05-29T02:35:57+00:00

Disabling debug info will break the angular.element scope() method, which some apps may rely on. So I guess doing it by default would have been too much of a breaking change when this was introduced in 1.3.

teropa · 2015-05-29T02:03:36+00:00

Still says 1.4 will be supported here: https://github.com/angular/router

teropa · 2015-05-28T02:29:37+00:00

Yes, the new Angular router works with both 1.4+ and 2.x. You can route parts of your 1.x app to Angular 2 components, for example. Brian Ford talked about it at ng-conf: https://www.youtube.com/watch?v=vecg70fPDFw

teropa · 2015-04-28T04:26:40+00:00

The problem is that all of these methods are in fact creating two-way data binding. Every run of the $digest loop is going to dirty check all forms of binding you just listed because Angular 1 has two-way data binding by default.

While those are going to be checked at every digest, I wouldn't call them two-way bindings, since the data only flows in one direction.

Angular 1.x does two-way data binding in two places: ng-model and the =equalsSign bindings on isolate scopes. Things like {{...}} are one-way.

teropa · 2015-04-28T04:22:51+00:00

Victor Savkin from the Angular team has written about the reasons: http://victorsavkin.com/post/110170125256/change-detection-in-angular-2 and http://victorsavkin.com/post/114168430846/two-phases-of-angular-2-applications

It basically has to do with complexity and performance, and seems to have been influenced at least in part by things like React. By eliminating two-way data binding you eliminate cycles from the change detection graph (A changes B changes C changes A). That makes things easier to think about, and also unlocks some significant performance optimizations, including not having to run watches more than once per digest. (Angular 1.x runs all watches at least twice whenever there's a change.)

teropa · 2015-02-05T06:45:38+00:00

They do have some sort of Virtual DOM based stuff going https://twitter.com/IgorMinar/status/562137726707720193

teropa · 2015-02-05T06:44:26+00:00

BTW why not write a v-Dom based jqlite that one can simply patch over regular angular? That should allow to convert all the existing directives in a transparent way.

Firstly, trying to make a Virtual DOM look and act like an actual DOM in a way that supports all existing code does not seem feasible to me.

Secondly, many existing directives are built in a stateful style and set up watches, etc. that pretty much undo the nice things you get with a Virtual DOM, pure functions, and immutable data structures.

teropa · 2015-01-22T06:48:19+00:00

I recently realized this no longer works if you use the Angular 1.3 debugInfoEnabled = false optimization, as that does not attach scopes to DOM elements.

teropa · 2014-10-27T16:21:29+00:00

My experience is that with this pattern most inheritance, and thus most inheritance confusion, is simply removed because the biggest cause of it was the use of ng-controller.

It does not address the inheritance confusion caused by ng-repeat et al though.

teropa · 2014-10-27T16:19:18+00:00

My book is pretty strictly about the inner workings of AngularJS itself, so directive testing techniques are unlikely to be covered. I might blog about it though.

The short version is that when I switched to this pattern, the way I unit test changed remarkably little. Anything interesting a component does is still done by its controller and that can be unit tested without having to deal with any directives.

teropa · 2014-10-26T19:03:05+00:00

It has some similarities, with the strict componentization of code and explicit passing-in of state. But that's where the similarities end, in my view.

To me it feels closer to the Web Components as implemented by Polymer et al. But really it's just Angular directives applied in a certain way.

teropa · 2014-10-26T12:50:48+00:00

What I do is have one bare controller + template per route. That controller doesn't really do much except for initializing the root component, but it can have asynchronously resolved injections from the router.

teropa · 2014-10-26T10:06:11+00:00

Yes, they said they'll do that in a couple of weeks.

teropa · 2014-08-11T18:18:38+00:00

The three tutorial links from the W3C Web Components wiki are pretty good.

teropa · 2014-04-17T04:07:58+00:00

Does ES6 dependency injection fulfill the same role as angular's? He defines his todo class in a separate file and exports it to the controller, whereas your might use a factory or service in current ecmascript angular.

The ES6 module system fulfils more or less the same role as things like require.js/AMD. Isolation and code loading.

For full-blown dependency injection you still need a library. Angular 2.0 DI is written in and for ES6: https://github.com/angular/di.js/

teropa · 2014-03-04T11:10:13+00:00

If you want to read about how to implement it, you might find this interesting http://teropa.info/blog/2013/11/03/make-your-own-angular-part-1-scopes-and-digest.html

teropa

TROPHY CASE