Live data from Hacker News

Angular 2.0

blog.angularjs.org

121–130 of 169 posts

Re: Angular 2.0

#121
post #47

Earlier quoted context omitted.

My interpertation of the AngularJS DI implementation is that it exists primarily to make it easy to swap items out for testing purposes. I believe it solves that problem very well. What alternatives do you recommend to DI?

Nothing, for swapping things out. :) In my test initialization, I'd probably just replace the value of "ns.someService" worldwide with a mock.

> just replace the value of "ns.someService" worldwide with a mock.

Having a window-wide namespace might make sense in the test, but it is pretty risky/limiting if you are writing a component that should be reused in contexts you don't fully control. There are other ways around that besides DI, but they will probably have similar trade-offs in safety EOU, etc.

Re: Angular 2.0

#122
post #51

I have multiple friends who are very excited about Angular and one who is very excited about Knockout, so I am convinced that they are getting something right. I am personally much more attracted to the reactive style of Meteor's Blaze or ReactJS. It seems much easier for me to reason about, but maybe this has something to do with my background in video games which means that a render-loop seems really natural to me.…

I've worked on one large project with Angular, and a couple of medium sized ones in Meteor (using the original UI system) and am working on a POC project with ReactJS at the moment. I think Angular is better for "slightly more traditional" webapps such as dashboards. Its directives are nice for building small custom widgets, and the thin model wrappers $http and $resource can be useful (though I'm looking forward to…

Big +1 to Facebook breaking down React into smaller parts that are reusable. Makes it hard to point out where there are weaknesses in the library with the "all or nothing" system of dependencies.

Re: Angular 2.0

#124
post #86
post #60

Earlier quoted context omitted.

Agree 100% with your post - some of these complaints are misrepresenting the aspects that are not as desired in Angular. I've used Angular quite extensively for the past 1 1/2 years, and most of the complaints I have with it are more nuanced, such as having to dynamically inject some custom directives via $compile in a service method provided to a controller due to the complexity of being able to alter the attributes…

I agree with you that since your elements appear to not be a part of the HTML5 spec they must be custom and are directives, wouldn't it be a good idea to mark them as such in some way? Maybe prepend them with "an-" or something? The reason being, considering that HTML5 is an ever evolving spec that it might be possible for a new element to be introduced that could be using the same name as one of your examples. That…

Good point. I, too, enjoyed using custom tags like or such, but I'm going to think twice in future.

Interestingly, out of the box Angular provides directives as a, input, or form—meaning that when you write you are, in fact, invoking a directive that provides extra features along with native tag's functionality. While using Angular, you may as well consider every HTML element a directive.

Nevertheless, Angular uses ng- prefix with their built-in directives that don't replicate some existing tag's functionality closely.

Re: Angular 2.0

#125

> Dependency Injection is still a key differentiator between Angular and other client side frameworks Why not just take Require.JS and use it as a dependency injector, like any other client-side frameworks allow you to do? IMO Angular is trying too hard to be everything, while it is now de facto a template system with an excellent support of custom directives and two-way data-binding. For example, Angular could be a…

Require.JS is a service locator. It's not an inversion of control dependency injector. You can swap in a different service locator for your tests, but it's messier than just directly passing in different dependencies for your tests.

Well yes, Require.JS is not strictly speaking a dependency injector (however you can use it as one), but underlying AMD pattern is a very good example of IoC. And this allows all kinds of interesting stuff to do with your codebase - for example, use Require.JS for development, simplified module loader for production and, if Require.js configs become messy in your specific project, you can just load a module for your tests purposes directly, passing all of it's dependencies manually. I don't see what exactly Angular's dependency management adds to this.

Re: Angular 2.0

#126
post #86
post #60

Earlier quoted context omitted.

Agree 100% with your post - some of these complaints are misrepresenting the aspects that are not as desired in Angular. I've used Angular quite extensively for the past 1 1/2 years, and most of the complaints I have with it are more nuanced, such as having to dynamically inject some custom directives via $compile in a service method provided to a controller due to the complexity of being able to alter the attributes…

I agree with you that since your elements appear to not be a part of the HTML5 spec they must be custom and are directives, wouldn't it be a good idea to mark them as such in some way? Maybe prepend them with "an-" or something? The reason being, considering that HTML5 is an ever evolving spec that it might be possible for a new element to be introduced that could be using the same name as one of your examples. That…

You can make your custom directives HTML5 compliant, see [1], you can use the HTML5 data- prefix. For instance:

  
can instead be coded as:

  
or something similar.

[1] -- http://docs.angularjs.org/guide/directive

Re: Angular 2.0

#129
post #86

Earlier quoted context omitted.

I agree with you that since your elements appear to not be a part of the HTML5 spec they must be custom and are directives, wouldn't it be a good idea to mark them as such in some way? Maybe prepend them with "an-" or something? The reason being, considering that HTML5 is an ever evolving spec that it might be possible for a new element to be introduced that could be using the same name as one of your examples. That…

You can make your custom directives HTML5 compliant, see [1], you can use the HTML5 data- prefix. For instance: can instead be coded as: or something similar. [1] -- http://docs.angularjs.org/guide/directive

That's my usual way, or the class-based way for older IE.
Post reply on HN