Optimize list rendering with repeat’s view recycling feature
One of the most ubiquitous array operations is iteration. The repeat directive in @microsoft/fast-element makes the process of iterating and rendering lists a seamless experience. If you are unfamiliar with this, take a quick read here: Using Directives | FAST.
While the repeat directive already provides robust out-of-the-box performance optimizations, you can take this further by understanding how and when to use the repeat options parameter. In this article, we are going to take a look at the recycle property.
What does recycle do?
By default, recycle is set to true. This setting means that the repeat directive will reuse views instead of creating new ones from the template whenever possible.
Here’s a basic example of using repeat in a template:
Let’s say this is our initial friends list: [“London", “Austin", “Chris"] .
Running the above code will iterate through the friends list and list each friend by name. Under the hood, a new view will be created for each item. Simple enough.
Now, I’ve decided I want some new friends, so I replace the friends list with: [“Fernando", “Satoshi", “Mi"].
You can see that structurally, nothing much has changed: the template stays the same, and the friends list is still an Array with three items.
The only thing that changed here is the data, which is where the beauty of recycling views comes in. repeat will find the existing view from the template and replace only the data: "London" will be replaced with "Fernando", and so on.
Benchmark results between {recycle: true} and {recycle: false}
Let’s run some benchmarks to compare what happens when recycle is turned off. For context, the following benchmarks are run with fast-benchmarks with a sample size of 30.
.reverse()
- 1000 items in array [itemCount]
- .reverse() is run 100 times for each run [loopCount]
In basic templates like the example above, it is more performant to recycle views — different variations of itemCount and loopCount report similar results.
Well, that’s convenient! Why would you ever want to turn off the recycle option? That leads us to the next topic.
When to turn off the recycle option?
When your data starts becoming more complex, there is a threshold of when recycling views becomes more cumbersome than creating new views from scratch.
Here is an example of a template that uses some nested repeat directives:
Benchmark results between {recycle: true} and {recycle: false} with a nested template
Things start to get interesting when comparing results between {recycle:true} and {recycle: false}.
.splice()
- 50 items in array [itemCount]
- .splice(i, deleteCount = 10, …generateData(addCount=10)) is run 5 times for each run [loopCount]
Wait, the version with recycle turned on no longer shows that it is faster than recycle turned off. Take a look at the following screenshot:
The memory consumption is more performant when recycle is turned off in a nested template. This outcome makes sense logically. If you think about it, it will probably take more memory to locate a nested item and switch out the data than simply creating a new one. This situation is where the value of turning off the recycle property comes into play.
How to turn off the recycle option?
Turning off the recycle property is as easy as setting the options at the end of your repeat block.
Let us reiterate our findings from the benchmarks we ran; when we have a template with nested repeat directives, it is more performant to set the recycle option to false.
Here’s an example of how you can set that on the template with nested repeat directives:
Make sure you define {recycle: false} within the repeat block, right after you define your template.
Here’s the same example with the template extracted from the repeat block:
Understanding how to use the features of the repeat options will help you think in a data-driven way and give you significant performance gains.
Learn more about repeat and other directives in our documentation on Using Directives | FAST.
