Comment by serve_yay | Hacker News Reader

Comment by serve_yay | Hacker News Reader

Actually, I think an opportunity was missed in the section about dependency injection. The problem of minifying is easy enough to avoid - you just don't use that form. (I do agree that the tutorials shouldn't be teaching the dangerous form, and the dangerous form shouldn't even be a thing.)

No, what I hate about Angular's DI is that it tries to make inferences about the name you give it, instead of the name being an unambiguous identifier. It does this for "convenience" but it just ends up causing problems and making incorrect guesses.

I'm talking about how, for example, if you have a class called WobbleController, you don't inject 'WobbleController', you inject 'Wobble' and Angular just "figures out" the 'Controller' part. Pretty sweet when it works! Wow, you don't have to type 10 characters! (Good luck grepping for it later, though.)

But when it makes a wrong guess it seems impossible to fix. The other thing that sucks about this is that you have to reload your app to see if Angular will actually be able to find the thing you're injecting. This whole thing is supposed to save time, and it just doesn't. It sucks.

> The problem of minifying is easy enough to avoid

Yes - use a minifier that doesn't break Angular code. Asking me to insert repetitive verbiage isn't an acceptable solution.

Sure, whatever, I just don't think it's the real issue with DI in Angular.

I am torn about how minification affects metaprogramming. I don't believe that reducing the delivery footprint should ever effect how the code is interpreted.

On the other hand, if you think of access to argument names as part of the Javascript language, then a "minifier" that threw out that information would by definition not be a Javascript minifier - it would be a minifier of a subset of the language.

lol. i have to laugh at this. it is not normal to write a framework that requires exact argument names in userland code. it is completely strange and unusual for something to break just because an argument name was renamed; this data is theoretically private to the function. The only reason this is not the case in Angular is because of the insane hack of stringifying functions. This is a violation of how things are designed and assumed to work in JavaScript. You don’t run functions by toStringing them and eval-ing them; you just call them... anything else is an experiment, not a supported use.

Do you find yourself injecting controller names often? I've never needed or wanted to do that...

Controller was just an example. I remember at one point I wanted to inject a value, and its name was "Foo", but the DI loader (whatever it's called) kept wanting to turn that into "FooProvider". There was no way to say -- no, the name is just Foo! It's not a shorthand for some other thing!

And like I say, no way to check that you've fixed the problem except reloading your whole app and waiting for it to show you an error, or not.

That's actually a case of a bad error message. It just means it can't find 'Foo'.

The DI looks for 'Foo', can't find it so it looks for 'FooProvider', can't find it, and throws an error saying it can't find 'FooProvider'.

I just think that's a bad way for it to work. It should look for the thing by the name you give it and then find that thing, or not.

edit: This portion of a down thread comment captures my complaint well:

"In a sane framework, errors are meant to direct you to the cause, not simply to announce that something somewhere is written in a way that the framework doesn't like because of complex reason foo."

Providers are really the only place where this is likely to happen. A FooProvider is an object that provides Foo to the dependency injector. So you tell Angular to provide Foo, and Angular creates the corresponding FooProvider for you. And what sets providers apart from services and factories, is that you can configure your FooProvider before the Foo gets injected, which is very useful, but you are suddenly talking to an object that you never created; Angular did.

By the way, Ruby on Rails does tons of this sort of thing, and goes a lot further. It automatically matches your Person class with the People table in your DB.

Reply on news.ycombinator.com