How To Make Angular Code More Reusable 

Haha :) I will leave those names for real Masters and Sensei. I am just a regular Angular dev with relatively good experience and some video editing skills ;)

Thank you, Dany :) Glad to hear that from you.

I hope so 😊 thank you.

Thanks for your feedback:)

You are welcome, Gagik! Thank you for your feedback :)

🙌

You are welcome 🤗 there will be more.

You're welcome! There will be more :)

You are welcome:)

Glad you liked it :) Yeah, I also have a feeling that the angular directives are quite underestimated and are used not as often as they could be. One of my theories is that many people come to Angular from other frameworks like React where there is no such concept of Directives and they tend to move the already familiar way based on components. Also, maybe there are luck of educational materials that highlight the strengths of angular directives... but this is something that I could fix ;)

Awesome! That was the goal of the video and the whole channel ;)

Agree! Thanks for feedback, Paulo.

Glad you like it 👍🏻

Hey Alex! Thank you for your as-always detailed feedback and thoughts, I always much much appreciated it :) By "enabling all inputs/outputs" do you mean by default or your idea is to have something like hostDirectives: ['*']? I think it would be an interesting idea and worth a dedicated GitHub issue because indeed it might be sometimes useful. Regarding the 3rd party directives and dynamic directive augmenting. As far as I know, currently, it is possible only at build time :( Yep, mixins are also an option and it is used by Angular Material, however, with mixins you can inherit only class properties/methods but Angular features like @Input(), etc will not be working there and mixins are problematic for template type checking. Also, mixins syntax looks a little bit clumsy and boilerplate-ish but it is a matter of taste :D Regarding the dynamic directive augmenting at runtime, tbh I don't have any information about it but my quick research led me to this comment github.com/angular/angular/issues/11716#issuecomment-373193097 which made me think that it won't be probably implemented but who knows, maybe something will change. Angular evolves so much and fast last time. Glad to hear that my videos help you :) Get back to Angular family soon :D Good luck anyway!

:) Don’t afraid to use Composition API, just keep in mind that moment with extra memory allocation and avoid it when it makes sense. In most cases you should not experience any problems with Composition API 😉

Me too 😄

An alternative approach (without using DI) that first came to my mind is introducing the @Input() disabled; also for the CanPreventDefault directive and exposing it from CanDisable one too. Then the 'disabled' input should be always in sync for both directives in this case and it removes coupling via DI. (here is the code example - github.com/DMezhenskyi/angular-directive-composition-api-demo/blob/alternative-without-di/src/app/directives/can-disable.directive.ts#L9). If by bidirectional dependency you mean "circular dependency" I wouldn't say that it is the one. The circular dependency you would get if CanDisable injects CanPreventDefault and at the same time CanPreventDefault injects CanDisable. The hostDirective doesn't inject declared directives but just instructs that the directives should be applied to the host when the component is initialized and it is pretty much the same as if declaring them explicitly in the template. This pattern (when one directive injects another one) you can see quite often in Angular source code too. For example, the NgModel directive injects the same way ControlValueAccessor directives in Angular Forms :)

Hi! Thank you for your kind words. Regarding your question: You will get circular dependency if the CanDisable directive injects CanPreventDefault one and at the same time CanPreventDefault injects CanDisable. The hostDirective doesn't inject the declared directives but just instructs that the directives should be applied to the host when the component is initialized and it is pretty much the same as if declaring them explicitly in the template.

Hi! Thanks for your feedback. No, directives will be applied only to the component host element

Thank you! I was trying hard to make it happen :D

@@DecodedFrontend Hardwork paid off, you nailed the pose 😎 And the video is amazing as always, can't wait to play around with Directives. Thanks and keep up the quality content 👍

I think it needs some time to understand it because this feature is relatively new. I see it useful if the directive is intentionally designed in a way that can work only with specific directives in tandem as a hostDirective, so removing the selector can guarantee that this directive won't be applied by mistake anywhere else in the application... but also, can't come up so far with an explicit real-life example of it... And this is the reason why I asked to discuss this because I hope to learn something from the community :)

It looks like you are coming from React world and looking for {...props} option :) Unfortunately, it is not possible in Angular yet.

Hi 🙂Try to check my video about Dependency Injection - ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-G8zXugcYd7o.htmlsi=TMcQ_4XF8BlU6dqG

Hi Andriy! Thanks for your question. Unfortunately, it is not possible as far as I know :)

​​@@DecodedFrontend Appriciate an instance response, Дмитро 🇺🇦 :D At least I found another useful feature: We can provide input params from inside the host element, since we can set propreties of an injected directive, not only get them as you showed at 14:00 private canDisableDir = inject(canDisableDirective); this.canDisableDir.disabled = isDisabled;

In general, it depends on the features that the button should have. If the button has its own HTML structure, makes a content projection, etc that it makes sense to have it as a component. If it has only some custom props like 'color' then it could be just a directive. If it is only about styling - your approach can also be a working option. In the video, the button was made as a component just for demo purposes, so please don't take it as an example of the proper component architecture design or production-ready code :) For tutorials, the implementation of some indirectly related building blocks is very often intentionally simplified or artificially adjusted to some concrete demo use cases.

Hey :) Thanks for your comment. As far as I remember I didn’t do anything extra with Console Ninja. I just installed it and just worked.

Technically component is directive with a template. You wouldn't have lifecycle hooks if you didn't mark the base class as a directive.

Yep, as @MichalSmolinsky said, you have to decorate base class with @Directive annotation to inherit Angular features like @Input(), @HostBinding(), etc. it is required since Angular 9 when Ivy renderer became default.

There is only one way I can see to add to directive provider `providers: [{ provide: Preventable, useExisting: CanDisableDirective }]` where Preventable is the base class for directives that compose host-directive. Then reach these directives inside the host-directive by `preventable = inject(Preventable);`.

You can use the "optional" resolution modifier to prevent failing if some directive wasn't found and adjust your logic accordingly but it depends on the concrete use case. The goal was just to show that it is possible to access directives via DI rather than to show a production-ready code snipped. Also, if you don't mind I will copy-paste my answer for a similar question here above :) "An alternative approach (without using DI) that first came to my mind is introducing the @Input() disabled; also for the CanPreventDefault directive and exposing it from CanDisable one too. Then the 'disabled' input should be always in sync for both directives in this case and it removes coupling via DI. (here is the code example - github.com/DMezhenskyi/angular-directive-composition-api-demo/blob/alternative-without-di/src/app/directives/can-disable.directive.ts#L9). If by bidirectional dependency you mean "circular dependency" I wouldn't say that it is the one. The circular dependency you would get if CanDisable injects CanPreventDefault and at the same time CanPreventDefault injects CanDisable. The hostDirective doesn't inject declared directives but just instructs that the directives should be applied to the host when the component is initialized and it is pretty much the same as if declaring them explicitly in the template. This pattern (when one directive injects another one) can see quite often in Angular source code too. For example, the NgModel directive injects the same way ControlValueAccessor directives in Angular Forms :)"

but that's actually the point and that's why they are called hostDirective because are being added to the component host element :) The directives that have to be used in the component view, you have to apply manually to a DOM elements as before.

@@DecodedFrontend :)

Mixins are bad practice, since they can lead to an excessive amount of logic.

Am not sure I understand you correct :) Actually, other way around, the hostDirective allows you to avoid code duplication in the template

Thanks for your comment. I just did it but I don't see anything unexpected. Am I missing something?

@@DecodedFrontend after a few days I installed the extension I realized that it was injecting totally obfuscated javascript code in the middle of my build files for production

It's been about 2 months since this happened to me.

@@GuiSeek Maybe they fixed that because I didn't experience anything like that... and tbh I can hardly imagine how the extension code could be leaked into the application bundle 🤔

@@DecodedFrontend Unfortunately it still is, I just reinstalled and found the injected and obfuscated code here again... run the build configured for production and search for "_console_ninja"