Why does building an Angular app with INJECTION TOKENS feel so good?! 

this is a dead channel

I thought the same thing. Looks like an AngularJS service.

Oh thank you! I prefer a known approach instead of trying to reinvent the wheel.

Claiming this is "cleaner" seems arbitrary at best. For me it reaches into the internals of Angular which might change in the future. The use of the decorator @Injectable makes it very clear what is going on.

Totally agree !

I disagree because all we need is a team specified convention And JavaScript itself is multi paradigm, so I don't find it weird to mix classes and functions, especially when it will force remove class inheritance

@@e-jarod4110 if you have worked in bigger companies, then you would know that team members tend to change, juniors are being hired every now or then and conventions are not always being followed, especially not when people set bad deadlines with "smelly code" as results. Besides that: You write typescript with angular (which is very opinionated) and new developers will have to adapt to your different ("unconventional") angular pattern, which will end up in higher costs (time/productivity) Your general angular knowledge can be applied to every angular codebase that is following the "intended" code-style (im using the word "intended" very carefully here) and this is a good thing, otherwise you will end up with a messy React.js 2.0, where every single project is a new learning rollercoaster

In isolation, I agree that this service has a higher cognitive load and is more complex, but only marginally. What about in an actual app? In typescript, class members are public by default so encapsulation is an after-thought. As a result, most Angular services I’ve seen expose too much leading to a larger than necessary public API surface and even allowing things outside of the service class to change what’s inside of it. In my experience, such an implementation can have a pretty gnarly cognitive load. That’s why class members in languages like C# and Java are private by default. With the solution in this video, service members are private by default so exposing them requires deliberate action, which would ultimately lead to better encapsulation and a lower cognitive load in the scope of the larger app.

@@kylerjohnson988 fair point but I feel like deliberately making them public isn't enough at least not for myself. My team knows to start out private and only make it public when necessary and we enforce public accessors and accessor order through eslint. It's the same process applied to using const until you know you need let.

Mixing OOP/functions doesn't really both me, imo the biggest reason not to adopt this approach is the inertia/standardness of the existing approach - and as you mention the benefit probably isn't strong enough to justify sweeping changes. So I don't really think anyone "should" use this approach unless its what they want to do, but I do think experimentation with stuff like this is great and ultimately what helps improve and shape the DX of Angular as it and the community evolves over the years.

Experimentation and demonstrating potential capabilities are always beneficial. :)@@JoshuaMorony

Some of the worst code I've worked on in my career was when developers tried to stick to either the functional or the OOP paradigm. The best code bases I've worked in used both paradigms where they made sense. I've always used classes for services (and of course components), but inside of them, I take a more functional approach because it ends up being more declarative/readable. I'm not sure I prefer this functional approach for services yet, but I definitely see some benefits: 1) It prevents inheritance. I come from a C# .NET background and I'm well-versed in inheritance, but in my career building and maintaining enterprise scale Angular apps, I've come across very, very few use cases where base classes were a better solution than another more generic service. I've so often seen unnecessary inheritance cause a lot of unnecessary maintainability problems. This approach prevents inheritance and more often than not, that will be a good thing for maintainability. If this were the default way to write services, I think people would consider more carefully whether inheritance is the right solution because it would mean breaking this convention (which I think is fine when it's warranted). 2) Private members by default are a huge benefit when maintaining enterprise scale applications and I wish that was the default behavior of Typescript classes. The Typescript team wanted to go that route, but the necessity of remaining a superset of Javascript prevents them. Java and C# both take this private-by-default approach in their class implementations, and I think it makes a ton of sense because it forces you to be deliberate about what gets exposed because consumers of the class can't do what they need to do unless they're exposed. So I think that's a massive benefit to this approach. I'm still not sure how I feel about this overall or if I'm going to switch to this approach, but I definitely see these benefits and I think it warrants consideration.

yup exactly

Feel the same. It's not Angular anymore for me with that function approach. It's closer to AngularJS, and I used to hate AngularJS :D

These are good points and I think I should've been more accurate with the phrasing in the video

100%. I shouldn't need to understand the entire NG iceburg to get a reference.

I’m not saying this is the way to go, but you don’t see the advantage in a private-by-default approach that requires deliberate action to expose members? This approach, while more complex, does offer a better default for encapsulation. Typescript class members are public by default and I’ve seen that cause maintainability nightmares in large scale apps. I really wish Typescript class members were private by default like in C# and Java. Again, I’m not saying we should all do this or that this benefit outweighs the drawbacks. I’m just saying that it is a benefit of this approach and it’s worth thinking about.

100%

I probably would too - the point of this video isn't to say everyone needs to start using this approach, which is why I said I would only use this in personal projects that I am working on alone. I like it, but it's probably not worth going against the grain right now. I still think its important to experiment with ideas like this.

@@JoshuaMorony It does seem like angular is moving away from the opinionated approach allowing more and more - for some that may be a good thing. But on the other hand, there is a risk of ending up with a project overly complicated with multiple approaches to solve problems. The clear guidance and structure from angular was always a benefit in my opinion - especially for big project where multiple teams need to collaborate on code base.

You do realize thats the entire point of DI, right?

@@adambickford8720 The point is, I wish more people did. You ask most Angular developers what DI is, and they will only say singleton services.

I haven't actually tried testing with the injection token service approach yet, but I don't think it would cause any issues - at least not with the way I generally test. Testing code outside of the service you can easily mock with DI as usual, testing the service itself I would just be interacting with its public API and testing what happens.

That's an interesting point, I suppose this would need to be profiled but I would be surprised if it made any significant differences on memory - especially in the case of creating services where you're often only going to have one instance of it anyway (even for non-root services we still would typically only have one provided to a specific component). I can't say with confidence since I've never tested this before, but I assume you would need to have a lot of instances of something for this to be a factor to give any weight to.

@@JoshuaMorony yea. I think a function/object would use less memory than a class if its a single instance.

Standards/patterns emerge, go thru general usage, and constantly evolve to add functionality and/or shed unnecessary weight. NgModule was standard, now it is not even included in the starter app generated by angular cli anymore, and I believe hardly anyone miss NgModule, it adds little to code organisation and overcomplicates so many things else. *NgIf, *NgFor were standard common module. Now they are on the way out, being replaced by more performant, built-in control flow @if, @for, etc The pattern this video showcases is being used to build the new NgRx Signal Store. All I'm saying is, keep an open mind and maybe one day you'll find this pattern is useful in some cases, rather than be dogmatic about what are "standards".

Angular has never been fully OOP, but it is mostly OOP. RxJS is functional and has always been a necessary part of Angular 2+. Also, I'd argue that taking a functional approach to class methods makes things more testable and results in a more readable, declarative code base. For example, I've often seen components with methods that handle DOM events (i.e. click handlers) and in that method it references a property (or properties) on the component class outside of its scope. Afterall, that's the OOP pattern most folks are familiar with coming from Java or C#. A better approach is to reference that property in the template and pass it into that method as a parameter. That way the method is only concerned about what's inside of its scope and the developer only has to look in that one place to see what's happening. There are places where the functional paradigm makes things simpler and more declarative. I don't think anyone is doing it because it's "trendy". I think people are doing it because the functional approach solves a specific problem they've run into. While I'm not sure I prefer this approach to services yet, private by default is an important encapsulation concept and a major benefit to this approach. Most OOP languages treat class members as private by default (like Java and C#) and I think that's a superior default compared to the public by default approach Typescript takes with classes. With years of experience maintaining enterprise Angular code bases, I think the benefit here _may_ outweigh the cost of the slight increase in complexity.

Closed mind 😂

Certainly understand not liking the approach - old approaches can be valid though, take the eventual arrival at signals so many years after knockout.js. Imo the biggest aspect of cognitive load/readability here has more to do with the unfamiliarity than the approach actually being more complicated - it's still a valid criticism/concern because there is value in the established familiarity of approaches. I think given the two options without any established approach the function based approach would be appealing. For the most standard approach it becomes a choice between: 1) Create a class that uses an "Injectable" decorator, within that provide a configuration to specify that it should be provided in root, you can then inject the service using the class 2) Supply a function to the createInjectionToken function, it will return a function that you can use to inject the service where you need it

Reminds me of react. I hate it.

This is not different for the sake of being different. This is the most overused criticism I see in the tech world and isn’t helpful for anyone. These things always have trade-offs that you have to evaluate for yourself, your team, and your project requirements. The benefit to this approach is that service members are private by default and exposing them requires deliberate action. This is a better default for encapsulation, which is why languages like C# and Java decided that class members should be private by default. In typescript, however, class members are public by default and that’s not great for encapsulation and I’ve seen it cause a lot of maintainability problems in moderate to large apps. This solution comes at the cost of a break in convention and a bit more complexity, but for some, the benefit of private by default may be worth the drawbacks. Is it for you? I don’t know. That’s for you to decide.

I see this largely as a preference - while I do think there is *some* concrete benefit to this approach (specifically the strictness it introduces to defining the public API) I don't think it is of much consequence. I still don't see it as an over complication, because personally I find the pattern simpler/nicer, but I also wouldn't push it on other people at this point which is why I mentioned that I'd only use it in personal projects at this point.

I disagree. Most OOP languages (like Java and C#) make class members private by default, which forces the developer to be deliberate about what they expose to consumers. Typescript classes are the opposite and I've seen that cause a lot of maintainability problems. In other words, Typescript offers no encapsulation by default. Private by default is objectively a far safer default than public by default. This approach to creating services provides that private-by-default functionality, which is a MAJOR benefit. You don't have to agree with this approach if you feel like the complexity outweighs the benefits. But to say there is no real benefit is flat out wrong. With years of experience maintaining enterprise scale Angular apps, I definitely see the benefit to this approach. I'm not sure that it's my preference yet or that I will take this approach, but the benefit is definitely there.

@@kylerjohnson988 I am not sure if you picked the right comment? But to answer your concern about encapsulation in JavaScript classes (!). Private properties exist and the private pattern in JavaScript is really nothing new and I considered it hacky back when I've seen it the first time

@@kylerjohnson988 if this was an argument, then it can be automated by a linter which would enforce explicit use of "public" else everything else has to be declared "private" (or even better, ts compiler flag in the future) I think it all boils down to the fact that seeing function comes with a set of assumptions like: we call it, 0 to n times, and we get a result (or error) eg ... sum(2,2) -> 4 TodoList(todos) -> HTML Having function TodoList {} which only runs once as it's in fact a factory (for instructions or whatever) and that it is not re-run on every change breaks this assumption Now when I (and many folks) see class, ... There is implicit assumption that this will run ONCE (to create an instance) which then lives (till it's destroyed, and has state and behaviors , ...) As such I still would argue that CLASS expresses the reality of something like Angular (or even Solid.js component) in more precise way! Can it be factory function, obviously, works in solid, but then we have to always think... Is this a "standard" function or "factory" (with lots of implicit hidden consequences) Using both class and function removes this step as its immediately obvious.

@@JoshuaMorony I believe you've become a little bit obsessed by everything being "functional" idea, which has gone too far. Functional approach has reasoning and you shouldn't write everything like that just because it feels fancy. While i see the beauty of functional code, I also respect another beauty of the mvc+oop paradigm, praised by Angular in it's cornerstone, and considering this it feels unnatural and irreverent to write like that without a solid reason.