3 min to read
Angular coding!
Hi friends! I leave you my opinion and some solutions to face some real cases while we code, I hope it helps!
As we code and add apps/projects to a repo, we see the app start to grow and our components get consumed and reused more and more, quickly, with little or no tweaking.
Now, not everything is pink and sometimes we find components that we need to reuse, maybe without visual changes but we do need them to consume the data that we want to render.
That’s where I want us to focus, when we think, where do we take that data from?? where? Axl comes with his wise answer
Well, usually the component exists because it’s already being rendered, so it’s already consuming data. We find that the component generally consumes data from a service and we even find that there is data that…
Many times we will have content that is fixed and does not come from any service, but this does not mean that we should put all the sentences and paragraphs directly in the template, because now when we need to reuse the component we must make more adjustments than necessary to be able to use the component accordingly.
The correct thing would be that we have objects and/or constants in our TS, and the template simply consumes and renders.
two) From where do we consume the data??? I came across cases where the component was already connected to a service and the data was logically rendered based on that. Now, we want to reuse that component but we come from another component and from other services.
There are several alternatives, perhaps the first one is, well, that the component has N services injected and consumes data from them dynamically.
That’s an option, but since we don’t know how much bigger the component is going to grow and how much it’s going to be reused N times by N components, we better not inject N services.
For a parent-child case, let’s use @Inputs! 
In this way, the component will render data from the main service that it has injected, and in case it is being reused, it will render based on an @input model.
Thus, we have our component that will always display data based on the service (as it was initially implemented before we need to reuse it) or from an @input that we will pass to it from N components.
If it’s not a parent-child case, welcome to… hell?
Well, if that’s the case, we could make a “shared” service, as simple and generic as possible, where it only has properties and methods that we need for this component.
So our component is ready for us, and it would use data from the main service or the shared service.
Let’s remember to implement it in the most abstract way possible so that when they reuse the component again, we can continue using this service and not add N properties and N methods to it every time it is needed.
