I'm new to Angular, and I find that I'm drawn to using a small service to communicate between components rather than the @Input/@Output method you described. Can you explain why I/O is preferable?
I find using input output for view only components to be simpler. If I have a parent component whos child component is a button. The input could be the button text and the output would be emitting the click event. Then I can use that button everywhere and customize it.
If I made a service to keep track of button clicks it would require a new file and for that component etc...
I do think passing data thats more complex than that should be handled in a service.
UI Consultant, Maker & Technical Writer.
I write about JS, TS, Rx, Angular & all things Front End
🇮🇹🇬🇧
Follow me on Twitter: https://twitter.com/gc_psk
Founder of https://makerkit.dev
haha I had dumb component written but changed it to view only component. I felt as if dumb may be offensive. Im not sure why components don't have feelings =)
UI Consultant, Maker & Technical Writer.
I write about JS, TS, Rx, Angular & all things Front End
🇮🇹🇬🇧
Follow me on Twitter: https://twitter.com/gc_psk
Founder of https://makerkit.dev
I think it depends a lot on what data you're passing. First of all, if your component is dumb, then it shouldn't require a service. That's where it's ideal to use inputs and outputs for communication. Watch our for this kind of situations.
If your container requires some state from a service, then by all means that's exactly how it should be done.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for such a great article!
I'm new to Angular, and I find that I'm drawn to using a small service to communicate between components rather than the @Input/@Output method you described. Can you explain why I/O is preferable?
I find using input output for view only components to be simpler. If I have a parent component whos child component is a button. The input could be the button text and the output would be emitting the click event. Then I can use that button everywhere and customize it.
If I made a service to keep track of button clicks it would require a new file and for that component etc...
I do think passing data thats more complex than that should be handled in a service.
I agree, your comment is on point!
I would stress that ideally a dumb component should never access a service for state.
Of course I am quite sure there are situations where a service could be needed
haha I had dumb component written but changed it to view only component. I felt as if dumb may be offensive. Im not sure why components don't have feelings =)
Thanks to you both. The considerations for I/O vs a service make much more sense to me now. Like most thing in programming (and life), it depends!
Hi Andrew!
I think it depends a lot on what data you're passing. First of all, if your component is dumb, then it shouldn't require a service. That's where it's ideal to use inputs and outputs for communication. Watch our for this kind of situations.
If your container requires some state from a service, then by all means that's exactly how it should be done.