Optimizing the Rendering of ListView Control Items

Windows Store applications written in JavaScript

For many Windows Store applications written in JavaScript that use collections, appropriate cooperation with the WinJS ListView control is essential to optimize performance. This is not surprising: when you need to manage and display thousands of potential elements, all the optimizations you make on these elements make the difference. What matters most is how each element is rendered, ie how (and when) each element of the ListView control is built in the DOM and appears in the application. Indeed,

The rendering of elements in a ListView control occurs via a declarative template defined in HTML or via a custom JavaScript rendering function that is called for each item in the list. Even if the use of a declarative model is the simplest method, it does not give a very large latitude to precisely control the process. A rendering function, on the other hand, allows you to customize the rendering element by element and implement various optimizations that are illustrated in the example of optimization of HTML ListView control performance . These optimizations are as follows:

  • Allow asynchronous distribution of element data and a rendered element. This is supported by the elementary rendering functions.
  • Separate the creation of the shape of an element, which is necessary for the overall layout of the ListView control, from its internal elements. This is supported via a placeholder converter.
  • Reuse a previously created item (and its children) by replacing its data, which avoids most of the steps involved in creating an item. This is possible via a recycling space converter.
  • Post intensive visual operations, such as loading images and animations, until an item is visible and the ListView control is not moved quickly. This is done via a multi-phase converter.
  • Batch processing identical visual operations to limit the repetition of DOM renderings with a multi-phase batch converter.

In this post, we will examine all of these steps and see how they cooperate with the rendering process of the ListView control elements. As you can imagine, the optimizations surrounding the moment the elements are rendered result in a large number of asynchronous operations and therefore convey many promises. During the process, we will also gain a deeper knowledge of the promises, relying on the previous post All about the promises of this blog.

Generally for all converters, it is important to always minimize the rendering time of the main elements (without counting the operations carried over). Because the final performance of the ListView control depends heavily on the correct alignment of its updates on screen refresh intervals, additional milliseconds in an element converter may cause the global rendering time of the ListView control to exceed The next refresh interval, resulting in the deletion of images and visual irregularities. In other words, it is actually very important to optimize your JavaScript code in item converters.

Elementary converters

Commençons par passer rapidement en revue la fonction de rendu des éléments (que je vais simplement appeler convertisseur. Un convertisseur est une fonction que vous attribuez à la propriété itemTemplate du contrôle ListView à la place d’un nom de modèle. Cette fonction est appelée, lorsque cela est nécessaire, pour les éléments que le contrôle ListView souhaite inclure dans le DOM. (Vous trouverez une documentation élémentaire sur les convertisseurs à la page itemTemplate, mais l’exemple illustre mieux les optimisations.)

Vous pouvez penser qu’une fonction de rendu des éléments reçoit simplement un élément de la source de données du contrôle ListView. Qu’elle crée ensuite les composants HTML nécessaires à cet élément en particulier et renvoie le composant racine que le contrôle ListView peut ajouter au DOM. C’est essentiellement ce qui se passe, mais vous devez prendre en considération deux points complémentaires. D’abord, comme les données de l’élément même peuvent être chargées de manière asynchrone, il est logique de lier la création des composants à la disponibilité de ces données. Ensuite, le processus de rendu de l’élément même peut entraîner d’autres tâches asynchrones, telles que le chargement d’images à partir d’URI à distance ou la lecture de données dans d’autres fichiers identifiés dans les données de l’élément. Les différents niveaux d’optimisation que nous allons voir, en fait, peuvent donner lieu à un nombre arbitraire de tâches asynchrones entre la demande des composants de l’élément et la distribution effective de ces composants.

Here again, you can expect to see promises! First, the ListView control does not simply communicate the data of the element to the converter directly; It provides a promise regarding these data. And the function does not directly return the root component of the element; It returns a promise regarding this component. This allows the ListView control to associate several element rendering promises and wait (asynchronously) for an entire page of items to be rendered. In fact, it does this to intelligently manage the development of different pages, by first creating the page of visible elements, then two pages off-screen before and after (the two pages that users are most likely to consult later ). In addition,

Related posts

Leave a Comment