(feat): Include all classes (not just components) about ngd HOT 6 CLOSED

@brian428 if you check this output, you can see the blue deps which are classes (services).
Is that what you mean?

from ngd.

Well, yes...partly. Though for some reason I have a number of services and other injected classes that aren't showing up as blue dependencies like you're showing above. Does the graph only pick up providers declared on a given class (rather than singleton (global) or inherited providers)?

Beyond that, I think it would be useful to see other types as well (models, composed/aggregated classes and so on). I realize that could make the graph a lot bigger, so maybe it could be an optional flag. But being able to essentially see the relationships for all imported classes (or at least all imported non-framework classes) could be quite useful to identify issues with module decoupling and organization.

What do you think? Am I making sense? :-)

from ngd.

1. Yes, the tool crawls only the providers (hence the dependencies feature).

2. I am open to add this feature. However, I think this has to be behind flags. The developer should be able to choose what she/he wants to generate.

However, my priority for now would be to update the tool so it can handle TS 2.0

from ngd.

Right, that's what I inferred (about providers).

Given that, I'd say two key enhancements might be:

• To have it handle global/singleton providers that are configured in the application bootstrap. (Currently, it only seems to handle providers declared on individual components, right?)
• To use constructor arguments to determine a component's dependencies rather than relying only on the component's providers. What is shown right now, where only dependencies declared explicitly on the component as providers, is certainly useful. But in many cases, you're dealing with providers that are declared further up a component hierarchy (or bootstrapped at the app level), which are "lost" (to some degree) in the current dependency graph.

I'd have no problem with these options being exposed via flags though.

To be clear, I'm not disparaging what you've done...it's already very useful. As I said, I just think that being able to really see all of the dependencies, across the entire app, would also be very useful. In that light, the constructor params might be a more accurate way to determine the dependencies. Or to go even further, using the imports to truly visualize all of the dependencies.

Thanks!

from ngd.

Sure @brian428 I see your point ^^

Do you think you can send a PR so we can discuss more in details on the implementation?

from ngd.

I will see if I can take a stab at doing this, but it may take some time. Partly because I'm obviously not familiar with how you're actually doing this. And partly because I'm on the hook already for some other PRs on other projects (namely, the angular2-seed project). :-)

from ngd.