Comment by tipiirai
2 years ago
True. When the array changed, the view is indeed re-rendered. Nue is probably not a good pick ATM for UI's with hundreds of rows and when list re-rendering performance is critical. I'll add the key- support if this becomes a frequent issue.
It's not just about performance, although that is of course a big part. What if I have child components with state that I don't want re-rendered? Suddenly I have to track the state in the parent to keep it from disappearing on every array change.
This has big architectural implications, and it worries me a bit that you only see it as relevant for benchmarks.
> if this becomes a frequent issue
This becomes a frequent issue in any app at scale.
If your app is at a small enough scale that it doesn't run into this issue, I would not recommend using a framework: just use vanillajs &/or some modular utility components.
If you're working on a small app & want to do it in a framework because you anticipate scale, use one with key support.
Hardly a frequent issue. I use zero apps in real life with more than 30 items on a single view, let alone 100 or 1000 — that all needs to be completely changed in one operation without re-rendering.
It's a common theme in benchmarking apps though, which will ultimately be the main reason for adding the key support.
> I use zero apps in real life with more than 30 items on a single view, let alone 100 or 1000
I do.
You've now disqualified this entire framework over a single issue, number of items in a list.
10 replies →
This comment section on HN has more than 100 items in a single view.