#Nesting components - reusability vs performance

20 messages · Page 1 of 1 (latest)

haughty oasis
#

We have many complex "form controls" in the app. Most of them are based on others. As we reuse them inside each other we get a large and deep DOM tree. Is there a better way to approach this?
For example:

  1. Auto complete
  2. Auto complete with drop down
  3. Auto complete with drop down with checkbox
  4. A switch form with drop down controlling what to show - 1 or 2 or 3
    Just to make clear by saying drop down I mean logically too (specific items with specific template and interactions). Each of those components are used multiple times in the app (4 times and more).
    For reusability we use 1 in 2 and 2 in 3 and 1,2,3 in 4. That means that 4 already has 3 nested components inside. The real case is deeper unfortunately. How should one tackle such case? We do see a performance impact from those components - especially when a page render a few of them (say 6 times).

We are using onPush on everything and using reactive forms. The main performance impact is the components creation.

mental chasm
#

sometimes making things reusable makes the app more complex and harder to maintain. Maybe if in the future you want to change 1. all the other component will break. Or maybe all the other components change as well, and this is your intention and saves you 5 minutes.
I am not saying that you should not create reusable components, but you should evaluate pro and contras and then decide.

That said, I find it very suspicious and I am surprised that you can see performance impacts right now. I think there is something else wrong in you app. I guess even if you use NO reusable components you would have the same performance problems. My guess is that the issue is somewhere else.

haughty oasis
#

@mental chasm well I admit the timings are weird... For example aetAttribute takes 5ms which seems kinda slow

#

Angular's aetAttribute of course

mental chasm
#

you should dig into and find the issue, but there is defenitly an issue

south iron
#

Have you run a profiler to understand where the performance issue is coming from?

#

Also, what is Angular's setAttribute?

#

I dont think the above nesting sounds complicated or performance heavy by definition. So I agree there has to be something that's causing that that should be solvable and might not be related to the nesting aspect of it.

haughty oasis
#

@south iron it just seems like angular DOM operations are slow... Creating the HTML is taking like 100ms

south iron
#

The profiler should tell you what part takes that long

haughty oasis
#

@south iron well stuff like:
Element start
Set attribute
And many blank areas

south iron
#

Like what can typically happen is that angular renders to much. Like you can have many events in your app that rerenders too often.

#

Ofcourse the thing that will then slow down the app is rendering it.

#

But instead of trying to speed the rendering, it often helps to limit the rendering.

#

But the profiler has pretty much always told me what component is causing it.

#

I would investigate in that direction.

#

Angular can be very fast, but you can quiet easily tear it down if you do things in a way that re-renders unneccesary.

e.g. If you have a list of 100000 items, and an input field... Without setting things properly, it could be that every character u enter in the input rerenders the 1000000 items, while both are entirly unrelated. So the solution there is to disconnect the two in such a way that typing in the input, doesnt cause any rerenders of the list.

#

But it's not always user-events that cause this behavior, it's just easier to explain, reproduce and fix with user-events like that.

#

Any chance you can move the components into a stackblitz? I would be interested to see what's going on.