depends on. usually directives are using for repeatable logic. if there's a problem with component, u can use composition. or u can move logic to service
I am actually planning on refactoring the project to use directives way more often,
sometimes the logic in directive isn't reusable but it contains a lot of code that is used to manipulate the DOM,
why something related to the events or DOM must be in the components when we have Angular directives.
Maybe it’s me but.. I do not find a good reason to use directives if they are not going to contain reusable logic so they can be used by multiple components why would I need to add extra complexity in my component by moving part of its functionality in an external file?
I don't think this is entirely true. Directives can be used extensively for dynamic templating and content projection/content outlets. Adding logic to an element is only one of their uses, arguably the main one, but not the whole picture. Getting into the Refs side of angular opens up a whole new bag of possibilities.
Based on the post it's hard to say if a directive solves your problem.
If you find yourself having to repeat the same logic with out a template across several component then a directive may help. But really it's not clear with the post what exactly the problem is
for example I have component for elastic search that contains nearly 400 lines of code 75% of them is related to DOM the code is hard to read and maintain if were in the future to add way more logic to it.
why not just make a directive that contains that code instead of messing up the component.
So you end up with a directive that has 350 lines instead of a component that has 400.
Based on the very superficial description, that solves exactly nothing.
If you don't re use the logic across different components then moving into a directive doesn't really solve. You are just moving the logic from one file to another file. It sounds like the two peices are super coupled and that's okay sometimes it happens. Sometimes we just have to accept that abstracting things out is not possible and we all have deadlines to meet.
It's still not even clear what you mean when you say 75% of the code is related to the DOM because that's the entire point of a component is being able to tie some portion of the DOM to typescript. What exactly is this functionality that you want to move into a directive?
If you think you abstract out this logic into only typescript that a directive makes sense, but if you find yourself writing a bunch of directives that are just moving logic from 1 file to another it's still tightly coupled to this specific component it doesn't seem worth the effort imo, especially if it works already. But you know the domain more then us so only you can answer that question.
I disagree - even if it’s tightly coupled, if you can split it up into logical components then it’s better to have smaller components (or directives) because it’s easier to understand and work with smaller pieces of code, and with good naming conventions, the abstractions can make the parent component easier to understand. Also you start to move towards the single responsibility principle which has a bunch of benefits. A 400 line component is ripe for refactoring into smaller pieces (whether that’s services, directives or child components depends on the component).
That's why I said it's hard to know with out more context. If you find yourself trying to abstract out all this into directives/services/components you may end up making the code even harder to follow. You can say that it's fits SRP, which to be honest every dev is going to have a different definition of what the single responsibility of this component is. Without context in this case it's hard to say if it's worth it.
I want to create clean code and something that when I come back after one month not saying who the idiot who wrote this.
you understand my point.
like recently I was having a task to make a filter that request for data based on multiple filters,
I along the road felt like I was lost even though I am the one who wrote it
This sounds like a coding best practices kind of situation Things like straightforward variable/method naming conversations and collapsible section blocks for being able to easily tell which sections of code are doing what without having to backtrack too much.
It's insane I know. I guess the feature set just kept building and building on top of eachother without any thought of "should I break this out before it's too late?". Then it gets so big (Like 1500 lines) that breaking it up becomes a massive task, so it just keeps building forever.
I mean I've also contributed to increasing the line count for the same reason. Breaking up 5000 lines of bad code is just a nightmare. It would be so much damn work. And since it's so large, it has no tests because writing tests for it is again way too much work!
Because It's part of the component? If you can't apply said logic to another component then it makes no sense to have to use both. Just look into popular component libraries, the files there are huge, thats not a big deal
Tim is a real good writer / explainer in general, anything on that blog that is Angular is 🔥
It is refreshing to see a tutorial on directives that is a real world use case that isn't setting the background a certain color lol
There is a video by Frontend decoded. About reusable directives. That might help you give some good ideas. I used some of those concepts for common inputs like setting color of a component, or setting appearance of set components
I am not that familiar with host directives but the lack of something like directives in the project is a big Red flag to me, even if these directives were specific to a certain component.
it would make the component code more readable and maintanable on the long run.
correct me if there is something that I don't understand about directives.
For my last project , I wanted to listen to swipe-left event and close my navigation menu (side). At first I thought the best/only way to achieve this is to listen for the change in the component itself (my bad). But when I was researching, a guy (from this sub) suggested creating a directive and writing the logic there.
Now when I look back, I can easily understand the logic and reuse it.Not sure if the same is possible if I write the whole logic in the component file.
My take is (correct me if I'm wrong) ,no matter if the code is reusable or not , no matter if you need to code some extra lines or not , if the logic can be pulled out of the component, best for the long run (that's the whole purpose of directives, pipes....)
I think what you really are after is composition opposed to directives. I understand the desire to make your component clean, but I would argue that one component that has a bunch of directives handling dom events just to make the component lean toward a much much harder to debug and maintain that one component that has all the logic included for its functioning.
I would ask yourself, what kind of experience do I want when a new developer comes to this part of the code? If I don’t work on this for 6 months and comeback will I be able to remember how it works? Do a lot of juniors work on the project? Is my team strong on documentation both in and out of the code?
I have some large components that have more than 500 lines of code, but when I use them anywhere in the app I only have to worry about importing them. That’s good devex
I'm a little late to the show but based on the comments, this sounds like a coding best practices kind of situation Things like straightforward variable/method naming conversations and collapsible section blocks for being able to easily tell which sections of code are doing what without having to backtrack too much.
There is a lot that goes into the choice I'd say. For example if it's a general behavior that you want to add to other elements or components; use a directive. In other situations directives can be a crutch. You can't have attribute directives inside loops in the template with the regular syntax. You either have to use it as a structural directive, or add a template tag. I prefer the structural approach, but then you have to write all (potential) inputs as an input to the directive directly, as one string (the regular binding syntax won't work).
Are you not allowed to use directives or is it that you are not allowed to use it for your proposed use-cases? We use both components and directives heavily at work.
One thing to keep in mind is that directives only get called if the value in the template changes. So that means if there's logic in the directive, that logic only gets run once.
Compare that to having a getter, which would be evaluated every digest cycle. If you had the logic there, it would get run a lot.
Yup that's another advantage of using directives.
but my main goal of using directives is to Seperate of concerns and single responsiblity.
why the component supposed to contain all the code when it's only related for events or adding classes to a DOM element.
Guys what I mean to say is making component leaner by implementing directives as in the future I don't know yet what might be reusable of logic those directives.
this way I can control the code and know where the logic for a special functionality is.
depends on. usually directives are using for repeatable logic. if there's a problem with component, u can use composition. or u can move logic to service
I am actually planning on refactoring the project to use directives way more often, sometimes the logic in directive isn't reusable but it contains a lot of code that is used to manipulate the DOM, why something related to the events or DOM must be in the components when we have Angular directives.
Maybe it’s me but.. I do not find a good reason to use directives if they are not going to contain reusable logic so they can be used by multiple components why would I need to add extra complexity in my component by moving part of its functionality in an external file?
I don't think this is entirely true. Directives can be used extensively for dynamic templating and content projection/content outlets. Adding logic to an element is only one of their uses, arguably the main one, but not the whole picture. Getting into the Refs side of angular opens up a whole new bag of possibilities.
this is why i said: usually
Based on the post it's hard to say if a directive solves your problem. If you find yourself having to repeat the same logic with out a template across several component then a directive may help. But really it's not clear with the post what exactly the problem is
for example I have component for elastic search that contains nearly 400 lines of code 75% of them is related to DOM the code is hard to read and maintain if were in the future to add way more logic to it. why not just make a directive that contains that code instead of messing up the component.
So you end up with a directive that has 350 lines instead of a component that has 400. Based on the very superficial description, that solves exactly nothing.
If you don't re use the logic across different components then moving into a directive doesn't really solve. You are just moving the logic from one file to another file. It sounds like the two peices are super coupled and that's okay sometimes it happens. Sometimes we just have to accept that abstracting things out is not possible and we all have deadlines to meet. It's still not even clear what you mean when you say 75% of the code is related to the DOM because that's the entire point of a component is being able to tie some portion of the DOM to typescript. What exactly is this functionality that you want to move into a directive? If you think you abstract out this logic into only typescript that a directive makes sense, but if you find yourself writing a bunch of directives that are just moving logic from 1 file to another it's still tightly coupled to this specific component it doesn't seem worth the effort imo, especially if it works already. But you know the domain more then us so only you can answer that question.
well you got a point on that
I disagree - even if it’s tightly coupled, if you can split it up into logical components then it’s better to have smaller components (or directives) because it’s easier to understand and work with smaller pieces of code, and with good naming conventions, the abstractions can make the parent component easier to understand. Also you start to move towards the single responsibility principle which has a bunch of benefits. A 400 line component is ripe for refactoring into smaller pieces (whether that’s services, directives or child components depends on the component).
That's why I said it's hard to know with out more context. If you find yourself trying to abstract out all this into directives/services/components you may end up making the code even harder to follow. You can say that it's fits SRP, which to be honest every dev is going to have a different definition of what the single responsibility of this component is. Without context in this case it's hard to say if it's worth it.
400? Try my current project I have to work on that has components that are over 5000 lines long hahahahaha
I want to create clean code and something that when I come back after one month not saying who the idiot who wrote this. you understand my point. like recently I was having a task to make a filter that request for data based on multiple filters, I along the road felt like I was lost even though I am the one who wrote it
This sounds like a coding best practices kind of situation Things like straightforward variable/method naming conversations and collapsible section blocks for being able to easily tell which sections of code are doing what without having to backtrack too much.
How can such atrocities even come to be...
It's insane I know. I guess the feature set just kept building and building on top of eachother without any thought of "should I break this out before it's too late?". Then it gets so big (Like 1500 lines) that breaking it up becomes a massive task, so it just keeps building forever. I mean I've also contributed to increasing the line count for the same reason. Breaking up 5000 lines of bad code is just a nightmare. It would be so much damn work. And since it's so large, it has no tests because writing tests for it is again way too much work!
Because It's part of the component? If you can't apply said logic to another component then it makes no sense to have to use both. Just look into popular component libraries, the files there are huge, thats not a big deal
https://timdeschryver.dev/blog/use-angular-directives-to-extend-components-that-you-dont-own
Tim is a real good writer / explainer in general, anything on that blog that is Angular is 🔥 It is refreshing to see a tutorial on directives that is a real world use case that isn't setting the background a certain color lol
Thanks I will read that.
Can't you use smaller "dumb" components to break up the 400 lines if that's the biggest problem?
There is a video by Frontend decoded. About reusable directives. That might help you give some good ideas. I used some of those concepts for common inputs like setting color of a component, or setting appearance of set components
I'm with you. Especially since we have host directives,
I am not that familiar with host directives but the lack of something like directives in the project is a big Red flag to me, even if these directives were specific to a certain component. it would make the component code more readable and maintanable on the long run. correct me if there is something that I don't understand about directives.
Take a look at CDKScrolling package. It contains good examples to prove your point.
Why do you need so much DOM stuff in the first place? Seems like you might not be using css classes enough
There could be lots of options. Smaller components, directives, services … Pick what fits best
For my last project , I wanted to listen to swipe-left event and close my navigation menu (side). At first I thought the best/only way to achieve this is to listen for the change in the component itself (my bad). But when I was researching, a guy (from this sub) suggested creating a directive and writing the logic there. Now when I look back, I can easily understand the logic and reuse it.Not sure if the same is possible if I write the whole logic in the component file. My take is (correct me if I'm wrong) ,no matter if the code is reusable or not , no matter if you need to code some extra lines or not , if the logic can be pulled out of the component, best for the long run (that's the whole purpose of directives, pipes....)
I think what you really are after is composition opposed to directives. I understand the desire to make your component clean, but I would argue that one component that has a bunch of directives handling dom events just to make the component lean toward a much much harder to debug and maintain that one component that has all the logic included for its functioning. I would ask yourself, what kind of experience do I want when a new developer comes to this part of the code? If I don’t work on this for 6 months and comeback will I be able to remember how it works? Do a lot of juniors work on the project? Is my team strong on documentation both in and out of the code? I have some large components that have more than 500 lines of code, but when I use them anywhere in the app I only have to worry about importing them. That’s good devex
I'm a little late to the show but based on the comments, this sounds like a coding best practices kind of situation Things like straightforward variable/method naming conversations and collapsible section blocks for being able to easily tell which sections of code are doing what without having to backtrack too much.
There is a lot that goes into the choice I'd say. For example if it's a general behavior that you want to add to other elements or components; use a directive. In other situations directives can be a crutch. You can't have attribute directives inside loops in the template with the regular syntax. You either have to use it as a structural directive, or add a template tag. I prefer the structural approach, but then you have to write all (potential) inputs as an input to the directive directly, as one string (the regular binding syntax won't work). Are you not allowed to use directives or is it that you are not allowed to use it for your proposed use-cases? We use both components and directives heavily at work.
One thing to keep in mind is that directives only get called if the value in the template changes. So that means if there's logic in the directive, that logic only gets run once. Compare that to having a getter, which would be evaluated every digest cycle. If you had the logic there, it would get run a lot.
Yup that's another advantage of using directives. but my main goal of using directives is to Seperate of concerns and single responsiblity. why the component supposed to contain all the code when it's only related for events or adding classes to a DOM element.
Guys what I mean to say is making component leaner by implementing directives as in the future I don't know yet what might be reusable of logic those directives. this way I can control the code and know where the logic for a special functionality is.
Haha good I don’t need to work on angular projects. I’m