0

I made a lot of big angular apps using different state libraries and same approach: divided big components by 'common sense', like 'pages' for router and which have some children like grid on left and edit form on right. And each component like this had zero @inputs and use subscriptions directly from store.

But now i starting another app and took a pause to think about it - maybe i make too much components, maybe it has effect on performance?

For example i have level one - router lazy loads module, that module has top level 'holder' component, which has toolbar on top with sub-page links and should have user name and avatar on right corner - with menu for actions like logout.

So what is 'right' way in terms of performance:

  • My default way - i make 'user-menu' component and use state selectors right inside it to get name and image.
  • Or Make that component 'dumb' and read state in parent component and pass via @Input, but then will be right to pass in from top level, will be tone of inputs...

But maybe it will be faster... At same time this component will be used in only one place - no need to have it at all, but then top level will look bad...

Maybe somebody can advice some docs or articles or maybe link to some open-source angular apps, that have real-world scale, not todo lists like on youtube videos where people typing imports manually in VSCode.

itspers
  • 797
  • 1
  • 4
  • 13
  • 1
    What makes you think that performance would be the deciding factor? Unless you go waaaay overboard, performance should not be materially affected either way. – meriton Aug 13 '20 at 00:06
  • I would focus on architecture rather than try to stick to a one-size-fits-all principle. Think about components as logic vs. presentation. Think about data flows. Don't try to optimize prematurely. – Brian Schantz Aug 13 '20 at 06:48
  • @meriton because app grows incrementally, i will not notice performance impact while making one component, but then it suddenly become slow after few weeks. I make crazy internal apps with dozens of grids, tabs and forms with 40 fields - they are heavy by nature and i need to get as much performance as possible, even if it will be 'bad architecture'. – itspers Aug 13 '20 at 18:40
  • @BrianSchantz its too abstract, question is exactly about architecture - how to make it right in terms of speed. For me, as developer its of course simpler to put selector inside component that need some data and just write async in temlate, rather than writing tone of Input and Output and pass them throw few levels of parents. And same is simpler to divide each page into smaller pieces like 'grid on left side' and 'edit form on right side'. Just logically. But in reality this components will be never reused and it has no sense for browser to have this extra 2 classes instead of one big... – itspers Aug 13 '20 at 18:48

0 Answers0