Fermer

octobre 7, 2020

Données "selon vos besoins" avec l'interface utilisateur Telerik pour Blazor DataGrid


Vous pouvez utiliser DataGrid dans Telerik UI pour Blazor avec n'importe quelle source de données en exploitant simplement l'événement OnRead.

Par défaut, le DataGrid dans Telerik UI for Blazor ] Est conçu pour fonctionner avec une collection qui commence par contenir tous les objets à afficher. Cependant, en tirant parti de l'événement OnRead de DataGrid, vous pouvez récupérer des données sur une base «selon vos besoins», en récupérant les objets uniquement lorsque les pages utilisateur avancent dans la grille.

Il existe au moins trois scénarios lorsque vous ne Je ne veux pas récupérer toutes vos données dès le départ:

  1. Lorsqu'il y a tellement de données que tout récupérer entraînerait des temps de démarrage inacceptables
  2. Lorsque les utilisateurs trouvent généralement ce qu'ils recherchent dans le premier quelques pages que la grille affiche (ces deux premiers scénarios se chevauchent)
  3. Lorsqu'il est essentiel de réduire l'impact sur la mémoire du client, vous pouvez atteindre tous ces objectifs en utilisant la méthode OnRead de l'interface utilisateur Telerik pour Blazor DataGrid.

Pour cette étude de cas, je vais supposer l'existence d'une méthode qui me permet de récupérer plus de données à partir de ma source de données (j'ai appelé cette méthode GetMoreData). Cette méthode doit avoir un point de départ que la source de données utilisera pour récupérer le «prochain» ensemble de données. Dans cette étude de cas, je vais transmettre le nombre d'éléments déjà récupérés. Dans la vraie vie, vous devrez peut-être passer autre chose (par exemple, la clé du dernier élément récupéré de la source de données). Ma méthode GetMoreData doit également recevoir le nombre d’objets à récupérer.

En outre, lorsque je récupère les données de la source de données, je vais ajouter ces données à une collection conservée chez le client. J'ai deux raisons à cela, la première étant que, comme vous le verrez, cela simplifie mon code. Cependant, conserver les données récupérées permet également une application plus efficace et une application plus réactive, car je n'ai pas à récupérer les données lorsque les pages de l'utilisateur reviennent.

Cela signifie que, lorsque l'utilisateur recule, il regarde des données obsolètes – la récupération des données donnerait à l'utilisateur la dernière version des données de la source de données. Cependant, je ne vois pas clairement si cela offrirait une meilleure expérience utilisateur: l'utilisateur pourrait trouver que le fait de modifier les données au fur et à mesure qu'il recule est plus déconcertant qu'utile (surtout si des données ont été ajoutées ou supprimées à la source de données, car cela faire passer les données d'une page à une autre dans la grille).

Configuration de la grille

La première étape de la configuration de la grille pour une récupération «selon vos besoins» est de lier le à un champ déclaré comme un Liste, liée au type d'objet que vous affichez (dans mon cas, je vais afficher des objets Employee). Dans le code suivant, j'ai appelé cette collection pageData. Je vais également avoir besoin d'accéder à la grille elle-même, donc j'ai défini son attribut @ref sur un autre champ que je vais configurer (ce champ doit être déclaré comme TelerikGrid, lié au type d'objet que la grille affiche) . J'ai également lié la propriété PageSize de la grille à un champ int (que j'ai appelé PageSize). Pour récupérer les données au fur et à mesure que les pages utilisateur avancent, vous devez affecter l'événement OnRead de la grille à une méthode (j'ai appelé ma méthode fetchingRows) et la propriété TotalCount de la grille à un autre champ int (que j'ai appelé totalCount).

Cela fait ressembler ma déclaration TelerikGrid à ceci:


Dans mon code, ces champs obligatoires ressemblent à ceci:

 List  pageData = new List  ();
TelerikGrid  theGrid;
int pageSize = 10;
int totalCount = 0;

J'ai également besoin de trois autres champs. Tout d'abord, j'ai besoin d'une collection pour contenir toutes les données que j'ai déjà récupérées (j'appelle cette collection empData). Je dois également spécifier le nombre d'éléments que je vais récupérer (je le garde dans un champ appelé fetchSize). Enfin, je dois garder une trace du moment où j'ai extrait toutes les données de la source de données. J'ai donc également configuré un champ booléen appelé EOF.

Voici ces déclarations:

 List  empData = new List  ();
int fetchSize = 20;
booléen EOF = faux;

Il existe une relation entre fetchSize et pageSize: fetchSize doit être un multiple de pageSize (y compris être juste égal à pageSize).

Récupération de données: obtention des données

Vous êtes maintenant prêt à commencer à récupérer des données " selon vos besoins »en ajoutant du code à votre méthode OnRead. La méthode OnRead est appelée lorsque la grille est affichée pour la première fois, chaque fois que les pages utilisateur en avant ou en arrière et chaque fois que la grille est mise à jour.

La première étape de la méthode OnRead consiste à déterminer le nombre d’éléments que vous devez ignorer. obtenez le premier élément sur la nouvelle page. Normalement, vous pouvez simplement lire la propriété Page de la grille pour déterminer la page actuelle, mais la grille n’est pas disponible la première fois que la méthode OnRead est appelée. Ainsi, pour la première page, le nombre d'éléments à ignorer est zéro, mais pour toute autre page, il s'agit du nombre de pages multiplié par la taille de la page:

 void fetchingRows (GridReadEventArgs args)
{
   int skip;
   if (theGrid == null)
   {
      sauter = 0;
   }
   autre
   {
      skip = (theGrid.Page - 1) * pageSize;
   }

Avec ce numéro en main, je peux vérifier s'il y a suffisamment de données dans ma collection "déjà récupérée" pour prendre en charge l'affichage de la page (je vérifie également mon champ EOF pour voir si j'ai atteint la fin de la source de données – plus à ce sujet plus tard). Si j'ai besoin de plus de données, je les récupère dans une collection appelée fetchedData et je les ajoute à la fin de ma collection «déjà récupérée»:

 IList  fetchedData;
if (empData.Count () <= (skip + pageSize) &&! EOF)
{
   fetchedData = GetMoreData (empData.Count (), fetchSize + 1);
   empData.AddRange (fetchedData.Take (fetchSize));

Si vous regardez attentivement, vous pouvez voir que je récupère en fait un élément de plus que ce dont j'ai besoin en passant fetchSize + 1 comme deuxième paramètre à GetMoreData. Je fais cela pour déterminer si j'ai atteint la fin de ma source de données. Je vérifie s'il existe au moins un élément supplémentaire pour permettre à l'utilisateur de paginer à nouveau. Si vous disposez d'un autre moyen de déterminer si vous êtes "à court de données" (si, par exemple, la source de données renvoie un marqueur EOF ou si vous connaissez le nombre total d'éléments disponibles), vous n'aurez pas besoin de le récupérer

Récupération de données: support de pagination

En fait, il y a beaucoup à dire pour connaître, à l'avance, le nombre d'éléments disponibles à partir de la source de données. Lorsque la grille pense avoir affiché tous les éléments disponibles, elle désactive automatiquement ses boutons de page suivante. La grille prend cette décision en comparant le nombre d’éléments de la collection qu’elle affiche à la valeur de sa propriété TotalCount. Si vous pouvez récupérer le nombre total d'éléments dans la source de données, vous pouvez simplement définir la propriété totalCount sur cette valeur et tout fonctionnera correctement.

Je vais supposer, car j'essaye d'accélérer mon affichage du temps, que je ne veux pas faire un appel «supplémentaire» pour déterminer le nombre total d'articles. Au lieu de cela, la plupart du temps, je mentirai simplement à la grille sur le nombre d'éléments à afficher en définissant la propriété TotalCount sur un de plus que le nombre d'éléments que j'ai récupérés. Pour ce faire, je viens de définir le champ TotalCount que j'ai lié à la propriété TotalCount de la grille à un de plus que le nombre d'éléments de ma collection «déjà récupérée».

Cependant, une fois que j'ai déterminé que j'ai épuisé mon source de données, je renoncerai à la prétention et définirai la propriété TotalCount sur le nombre de ma collection «déjà récupérée». Dans ce cas, je définirai également mon champ EOF pour éviter de revenir à la source de données une fois que j'ai récupéré toutes les données. Voici la partie suivante de ma méthode fetchingRows avec ce code:

 if (fetchedData.Count () <fetchSize + 1)
{
   EOF = vrai;
   totalCount = empData.Count ();
}
autre
{
   totalCount = empData.Count () + 1;
}

Comme je l'ai dit, conserver cette collection «déjà récupérée» offre non seulement une meilleure expérience utilisateur, mais simplifie également mon code. Sans cette collection, je devrais gérer moi-même le champ totalCount comme étant le nombre maximum d'éléments que j'ai récupérés plus un.

La dernière étape de la méthode OnRead consiste à mettre à jour la collection à laquelle la grille est liée (pageData , dans mon cas) avec une sélection de la collection «déjà récupérée». Ce code est très simple:

 pageData = empData.Skip (skip) .Take (pageSize) .ToList ();

Et vous avez terminé… à condition que vous ne souhaitiez pas prendre en charge l'ajout, la suppression et la mise à jour de lignes dans la grille. Une fois que vous prenez le contrôle de l'événement OnRead, vous devez également fournir des méthodes pour une combinaison des événements OnDelete, OnCreate et OnUpdate ainsi qu'une méthode pour prendre en charge l'ajout d'une nouvelle ligne vide. Ce n'est pas beaucoup de code et je l'ai couvert ailleurs donc je ne vais pas vous y faire glisser à nouveau.

Mais même en ignorant les mises à jour, vous avez maintenant la possibilité de fournir à votre utilisateur avec une grille plus rapide et une meilleure UX que si vous récupériez toutes vos données à l'avance. Et plus vite c'est toujours mieux.





Source link