Comments (4)
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.
from ngrev.
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;
- Injectables;
- Components;
Modules - something similar as we have now with dependencies;
Injectables - show graph which represents relations between. Usually injectables don't have many relations between themselves, but it could be useful in case of huge app.
Components - I think it's something that you mentioned about template. Would be nice to see the structure of components. Perhaps from component as a route and all components which are used in template and so on..It's gonna be something like a tree of components.
Module's details - something like we have it now.
Injectables details - that's what I described above in the issue.
Component's details - additionally nice to see where it's declared and where it's used. Also if it's injected or used as View Child() would be great to show it.
Also I'm thinking about the view with analysed info:
- show Injectables list which could have more than one instance;
- show components, which are declarated more than in one place;
- highlight components which use Default strategy;
- show modules, which have more than one declarations (It could be not critical, but as a notice would be great).
It would nice to have possibility to switch between graph view and list/ table view.
from ngrev.
Injectables details - that's what I described above in the issue.
Component's details - additionally nice to see where it's declared and where it's used. Also if it's injected or used as View Child() would be great to show it.
Looks like these are the two new views that are currently missing:
Also if it's injected or used as View Child() would be great to show it.
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?
additionally nice to see where it's declared and where it's used
I can see how this could be very useful. It's not trivial from UX perspective though. We can:
- Show in which components the given component is used in
- In which modules the component is imported
- In which modules the component is declared
Components - I think it's something that you mentioned about template. Would be nice to see the structure of components. Perhaps from component as a route and all components which are used in template and so on..It's gonna be something like a tree of components.
This is not available as well, but I'll be looking at it next.
show Injectables list which could have more than one instance;
show components, which are declarated more than in one place;
highlight components which use Default strategy;
I like this a lot.
show modules, which have more than one declarations (It could be not critical, but as a notice would be great).
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?
from ngrev.
Sure, I'm gonna create separated feature requests
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.
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
Ivy's compiler is not responsible for instantiating providers.
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...
from ngrev.
Related Issues (20)
- Broken build HOT 6
- Duplicated application root module HOT 4
- basic question angularJS and JSP
- can't parse nx app HOT 1
- Support - I cannot understand how it's working.
- Cannot drag vertically
- error parsing dependencies if a service has an inherited constructor.
- Error while parsing project for Angular 12 App HOT 3
- Macos version
- Error parsing project HOT 8
- Error parsing with lazy loading modules HOT 1
- useFactory with Lambda fails HOT 1
- feature: component's detail view
- feature: component's view
- feature: additional view with analysed info
- bug: show libs option doesn't work in module view
- feature: change colour of libs modules
- feature(module view): show modules where the selected module is imported
- Add support for template visualization
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ngrev.