blog/angular-inject-and-injection-functions

[yjaaidi]

Let's talk about https://marmicode.io/blog/angular-inject-and-injection-functions

[riccardoperra]

Nice article!

What do you think about using this feature with lower version of Angular?. I saw that, since the v9, there is an ɵɵdirectiveInject in @angular/core which seems working exactly like inject, allowing us injecting dependencies without the constructor 🤔

I don't think the implementation has changed, you could do something like this

import {ɵɵdirectiveInject} from '@angular/core';
export const inject = ɵɵdirectiveInject;

[yjaaidi]

Hi @riccardoperra! Thx for your feedback 🙏

You're right, ɵɵdirectiveInject is the internal implementation of inject 😊.
But, not only, I wouldn't recommend using internals except for experimental reasons but also, this will not work as before 14.0.0-rc.1 the function only works in the factory context and not in the constructor context.

TL;DR: it won't work

[riccardoperra]

Just for purpose I've made a small stackblitz with Angular 13 yesterday, maybe I'm missing something, but it seems to work fine 🤨

https://stackblitz.com/edit/angular-ivy-1ink97?file=src/app/app.component.ts

[yjaaidi]

Interesting! Thanks @riccardoperra !

[UserGalileo]

Hi @yjaaidi ! Thanks for the article :) Good that we have this space to discuss!

So, this feature clearly has advantages and drawbacks. I'm a consultant so I'm very used to imagine what devs will do with a feature like this (or better, how they could misuse or abuse it). These are my thoughts.

Naming conventions

First of all: I'm not a fan of naming conventions :) I already know that won't be consistent across devs and teams and I expect I'll find different conventions and different names, I'll just have to deal with that. For example: prefixing the functions with "inject" (eg. injectAction, injectSelection...), it could help, but it is really feasible? That's a powerful function and devs will take advantage of it no matter what if that makes something easier: I've seen use-cases for it where the inject prefix simply doesn't fit, it makes the resulting code difficult to read. Like: of course it does use inject internally, but from the outside that's now all that function does. A couple of examples:

state = injectState(1);

How is this function injecting a state? Where is it provided? It'd be easier to say that this is creating a state, and injecting RxStateConfig (or the ChangeDetectorRef) is just a side-effect of that to make it work. For sure: that's not injecting my state (1), it doesn't even make sense :P I expect this will not be easy to reason about.

hold = injectHolder();

ngOnInit() {
  this.hold(interval(1000), value => console.log(value));
}

Same thing! I wouldn't know what this thing does without looking at the source, and then I'd say "well that's a strange name"! It'd be easier to reason about if it wasn't called that way.

So, not a fan of prefixing with "inject" every function that uses inject internally :)

The name itself

This is kind of an off-topic but I'll put this here anyway: as you know we have discussed on Twitter about the name inject itself (with Marc) and how that could be misleading (maybe better locate, request, ask?) but I also think it'd be hard to change. I don't think that's particularly misleading in general, but if someone finds that the name kinda messes up with their reasoning I'll be happy to hear that and report it to my students and clients.

I thought about it for a while and imho the only place I (personally) find it a bit problematic is: inside useFactory's and providers in general (IIRC, that's where it was originally used, interestingly). I see how that could mess up one's expectations a bit: in a component, I have no doubts that calling inject will retrieve what I want. I'm at the consumer level, that's all that comes to mind, it's straightforward. Inside a useFactory I see how one could think that that function may actually "substitute" something with a different implementation, because that's a place where I can actually return a new instance. Of course it doesn't make sense since the function accepts one injection token and returns something, it'd only be problematic the first time that someone sees that in that environment.

The Type Inference Use Case

Agree, if I'm using InjectionToken's in a constructor with @Inject I have to import the instance's model and I won't even be sure that that's accurate: this fixes that.

The Abstract Base Class Use Case

Agree, and I agree with you on the "inheritance should be avoided but can come in handy" reasoning.

Anti-patterns

This is just an advice in regards to the form of your article: when I first read it, I expected that the "anti-patterns" you'd talk about would be the ones caused by the inject function, instead it's the opposite :P They're "use-cases" where inject can simplify. Maybe I would put it a bit differently? Dunno.

Either way, the Anti-Pattern #3 doesn't even contain a "before" version (without the inject function). That confuses me: are you saying that what you showed is an anti-pattern, then? (btw not a fan of hiding the subscription that way so I'd say I'd consider it an anti-pattern :P)

Recommendations

I agree with most of the recommendations! Especially the one regarding React's Hooks. I've seen plenty of examples on Twitter where people think about it that way (useSomething), please please please let's not do that.

The one recommendation I disagree with is in fact the one about the naming convention: I don't think that's actually useful, as I said. I don't see particular problems with the "constructor time" caveat, what's the worse that can happen if the dev doesn't know about it? The function will break inevitably, that's it. Right? Or am I missing something? Making it clear on the docs is mandatory imho, but other than that, I see no problems.

Summary

For the moment, I'll keep on suggesting to use constructor-based DI for most of the things. I'm not a fan of the "less code is better" argument that's usually made in these cases by some people, I never felt that was Angular's main philosophy and I still don't think it is. I value transparent code more than anything and I see how this inject function could be a real pain in some cases, but indeed it helps solving some issues and for that I'm grateful. I just hope we won't abuse it (like, could a library export only functions instead of services? yikes)

[yjaaidi]

👋 Hi @UserGalileo!

Concerning naming conventions, as I mentioned before Injection Functions should be focused on injecting (or locating/retrieving injectables).
injectState and injectHolder are considered as anti-patterns as they are too hacky. In fact, they both need to grab lifecycle hooks which can't be done properly right now so they don't even have to be named 😅.

It's not that easy to change the name of the function for multiple reasons.
It's not only about code but it's also about existing resources around. There might be blog posts, guides, video courses with useFactory() { inject() } examples already there. Changing the name of the functions would break lots of resources.
On the other hand, it became across frameworks a common pattern to call inject() the function that returns an injectable given a token. I don't think that there are lots of frameworks with a global inject() meaning something else. It's not breaking an already established habit. Yes! inject() is a service locator but it's a "tomahto vs tomayto" issue IMO.

You're totally alright about the Anti-Patterns. That's the reason why I am planning to update my blog post to make this more explicit.
The real story behind this is that the initial blog post was just showing the possibilities as dirty as they were... and sharing some recommendations at the end... then all the twitter momentum happened and I started seeing people going wild hacking the thing... that's when I realized that I had to be more explicit about the anti-patterns... but I was invited at some friends place 😅 so I had to rush the thing... but the update is coming 😊

For the moment, I'll keep on suggesting to use constructor-based DI for most of the things.
💯

[UserGalileo]

@yjaaidi Great! Cannot wait to read it :)

Concerning naming conventions, as I mentioned before Injection Functions should be focused on injecting (or locating/retrieving injectables).

Yeah sure, the fact is that if the problem was just "I need to inject something", the name could fit nicely:

http = injectHttp();

// instead of
http = inject(HttpClient);

This name makes total sense, because you're returning the injected "thing". But in reality I think the main pattern will be like: inject something, call a method on it, and return the result.

So things like this:

export class MyComponent {

  user = this.store.select(selectUser);

  constructor(private store: Store) {}
}

Will become like this:

export class MyComponent {

  user = injectSelection(selectUser);
  fetchUser = injectAction(fetchUser);
}

Note
Btw, I would totally suggest against this. The benefit is very very very minimal compared to all the drawbacks. Hey, github notes are cool!

At this point the name doesn't make sense. Form the user perspective, you're not "injecting a selection" or "injecting an action"... You're injecting the Store! But you can't say "injectStore" because:

1. It wouldn't make sense
2. You'd need to call both of them the same way

So at the end... I think the naming convention wouldn't be so useful after all, it could even be more "dangerous"!

It's not that easy to change the name of the function for multiple reasons.

Yeah sure, that's not a problem imho, I don't expect it to change. Maybe a missed opportunity, but not a problem :)

I say that because if it was clear that this is more like a Service Locator pattern, we could have had a very easy and elegant way to explain the drawbacks. In fact, they're pretty much the same! But at the end we can still explain them.