-
Notifications
You must be signed in to change notification settings - Fork 107
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Injectables visualisation #81
Comments
Currently, we have a subset of this - we show an injectable and its dependencies. To preview the dependent classes the user has to navigate to them. Do you think this makes sense to be part of the global app view? Currently, there we only show all the modules, their dependencies, and declarations. I was thinking that adding providers could be also useful. My only concern is to not have too complicated graph with many overlapping connections. |
I agree with you, it doesn't make any sense to render everything in one view (Only if you wanna make a tweet about how huge your app is). Nice to have more views:
Modules - something similar as we have now with dependencies; Module's details - something like we have it now. Also I'm thinking about the view with analysed info:
It would nice to have possibility to switch between graph view and list/ table view. |
Looks like these are the two new views that are currently missing:
This part will be tricky, so I suggest holding this off. I also don't see a tremendous value here. Maybe open a feature request to keep track of it?
I can see how this could be very useful. It's not trivial from UX perspective though. We can:
This is not available as well, but I'll be looking at it next.
I like this a lot.
I'd suggest holding this off for now because there's no official recommendation to have a single declaration per component. I'd even discourage such practice. We need to think what are the best ways to visualize the injectable visualization. Also keep in mind that not everything is possible because Ivy's compiler is not responsible for instantiating providers. As a good next step, I'd suggest opening feature request for the issues we agree will be a good fit. Would you want to take this? |
Sure, I'm gonna create separated feature requests
For some cases I agree with you. F.ex. If you use some date picker component, which has some internal views or so.. But I met examples, when one module declares 20+ components, which are not related with each other.. Then when you want to use one of them you need to import all of them... I don't suggest to show all modules with multiple declarations...but at least it would be great to think about that, maybe just highlight if there are lots of different declarations
I guessed so, but I thought we can do some prediction at least...f.ex. if Injectable is provided in root module, in lazy-loaded module and in some component.. We could notify about that. I faced the issue when SomeModule.forRoot() was imported around 20 times through the project... |
It would be great to show all relations for selected Injectable.
Many huge projects have a services folder, which may contains 100+ shared services...
To refactor that nice to have next features:
The text was updated successfully, but these errors were encountered: