The request from the service works fine, I get my filtered items.
But how can I pass these filtered list to another page? Maybe I only want to to integrate my searchbar in a modal window and want press the results button to see these filtered results in the dashboard page.
The primary reason I generally prefer doing this in a service is that I find it more extensible. When some other part of the app wants for some reason to know about these filtered list results (maybe we want to phone home with common search results for some sort of analytics; maybe we want to save the last X searches in device storage for performance or offline mode), all we have to do is inject the service and pay attention. If the EventEmitter is down in a component, it’s harder to get at from outside the host component. I guess that could be considered a feature in some cases, as it preserves some semblance of encapsulation, but I can think of a handful of times I’ve gone from an @Output property to a mutually injected service, and none the other direction. Of course, that may also just be me.
It really is an architectural choice, because I code in react and vue, emitting an event from a component is the the preferred method and recommended approach… now you could then have the parent component take the results of the modal and store it into some service or state manager but like I said it is a commonly used pattern in vue and react and the example I found in angular was from the angular documentation.
Obviously, that’s a slight exaggeration, but I do mean slight. Anywhere you can possibly give something a proper type, whether it be a controller property, a method argument, or a method return value, do so. It may seem tempting to just say “let’s just shut the compiler up for now” or “I’ll get around to it later”, but it even makes a huge difference when somebody else is reading your code for the first time, such as when you post questions here.
Naming conventions are also important, though less so. There are two problems with searchInter as an interface name: it needs to start with a capital letter, because classes and interfaces should be PascalCase - this way they don’t collide with variables and method names in camelCase. Also, Inter (or the Ixxx I often see from folks steeped in C#) isn’t useful. Since all the names of things I see here are so generic (search, item, result), I don’t know what you’re actually searching for. I’m going to pretend it’s books for now.
untilDestroyed comes from this project and is needed here to prevent leaking subscriptions. There are obviously other ways of doing this, such as keeping a Subscription property in the class or using the AsyncPipe, but untilDestroyed is my favorite.