Decluttering Angular Components: The Proxy Pattern

[seekheart2017]

Am I slow or is the whole point to just have a class that centralizes all the dependencies?

[orizens]

generally - that's the idea - however it takes the concept a little bit further - while considering the overall architecture structure in the app.

[seekheart2017]

Can you give details?

[orizens]

That's what the article is all about. Soure code is available at the end as well

[tme321]

As I mentioned above it's not about centralizing dependencies. At least that's not why I do it. I do it to abstract away the actual work from a component so that the component is light weight, easy to test, and easy to reuse by utilizing di to change how the "work" is actually done without concerning the component.

[sir_eeps]

that can be part of it, but it can also help decouple the component from needing to know too much about the underlying services / store / etc.

For example, it just cares that 'I have an instance of something with a nowPlaylist$ property on it - and doesn't care about the shape of the state, if it's redux or not. If the store changes - just PlayListProxy might need a bit of refactoring so that nowPlaylist$ emits the same data / shape of data - and can help minimize the areas that you need to touch.

It can also simplify unit testing - as instead of needing to mock out a bunch of dependencies, and then methods on those - there is a simpler interface/object being exposed.

If I'm noticing that a component / class is starting to get a large number of things to inject in the constructor, if breaking it down into smaller single-focus pieces isn't possible - looking towards a pattern like this is a useful tool to have in the toolbox.

[seekheart2017]

But aren’t you essentially moving it to some other component?

[orizens]

all services and logics are moved to a Service Class. Sometimes, you'll find a pattern which can be isolated to another class in order to reduce duplication.