5 raisons de ne pas écrire votre propre grille de données JavaScript

Les grilles de données (parfois appelées tables de données) sont une partie essentielle de nombreuses applications métier, et la tâche de les créer peut être monumentale. Renseignez-vous sur les écueils liés au roulage de votre propre grille, comme l'ont noté nos équipes d'ingénieurs et les nombreux que nous avons rencontrés sur le terrain.

Parmi les nombreuses choses géniales que les développeurs JavaScript (React, Angular, Vue …) peuvent créer dans leur applications, la plupart sont vraiment agréables, certaines vous donneront un peu de mal à la tête mais aussi de la satisfaction à la fin, et une poignée devrait être étiquetée, "Voici les dragons." Je dirais que le composant de grille de données (également appelé «table») appartient à cette dernière catégorie.

Une implémentation de grille de données JavaScript avec de multiples fonctionnalités: pagination, filtrage, regroupement, localisation, colonnes collantes (figées) et exportation au format PDF et Excel.

Sur la base de cinq années passionnantes d'expérience dans l'espace des composants de l'interface utilisateur, j'ai une demande urgente: ne vous lancez pas dans la rédaction de votre propre grille de données JavaScript ! Je sais que cela ressemble à un projet amusant et stimulant qui serait idéal pour votre CV, mais à moins que ce tableau ne soit juste une liste d'éléments avec une seule fonctionnalité (par exemple, le filtrage), vous vous lancez dans des eaux inexplorées. Les choses peuvent devenir difficiles plus vite que vous ne pouvez l'imaginer.

Je sais qu'écrire une grille peut être l'un de vos objectifs en tant que développeur. Mais avant de le faire, prenez quelques minutes pour analyser ces cinq vérités dures que j'ai apprises des équipes d'ingénierie de Kendo UI (personnes qui ont écrit des grilles de données pour divers frameworks afin de satisfaire les exigences des clients) et de nos utilisateurs (développeurs qui ont rencontré ces icebergs sur le terrain).

1. C’est un trou noir!

À moins que vous ne travailliez avec le client / gestionnaire le plus discipliné, ce qui a commencé comme une exigence pour implémenter une grille simple avec des fonctionnalités de base de pagination et de filtrage va rarement s’arrêter là. Sur une note très simple, vous devrez ajouter des boutons et éventuellement une liste déroulante juste pour activer la pagination.

Et avec chaque fonctionnalité supplémentaire demandée, la complexité de votre composant de grille de données augmente de façon exponentielle. Ah, le tri et l'édition rendraient la grille beaucoup plus pratique, cependant. Et maintenant que nous avons autant de données, le regroupement est tout simplement indispensable. Avons-nous mentionné que l'application dans son ensemble doit être réactive car la moitié de nos utilisateurs naviguent sur des appareils mobiles?

Gérer soudainement les fonctionnalités en expansion de votre réseau et mélanger et assortir les bibliothèques externes que vous avez intégrées en cours de route pour gagner du temps devient une énigme enveloppé dans une énigme. Et cela sans même tenir compte de la maintenance pour le moment – à laquelle nous consacrerons une section distincte.

«Nous avons essayé de déployer notre propre réseau et, à mesure que la portée diminuait, les coûts de mise en œuvre et de maintenance ont grimpé en flèche. Le client était loin d'être satisfait de l'ensemble de fonctionnalités initialement demandé. » – C'est un sentiment qui fait écho dans de nombreuses conversations que nous avons avec les développeurs.

En résumé, avant de commencer à créer une grille de données JavaScript à partir de zéro, posez-vous cette question hypothétique, mais bien trop réelle: «Souhaitez-vous abandonner toutes vos autres responsabilités de créer et de maintenir un seul composant? "

2. La grille est une façade pour plusieurs composants et fonctionnalités d'interface utilisateur

Ce que vos utilisateurs finaux considèrent comme un modeste tableau, d'un autre côté, peut vraiment être une longue liste de différents composants et fonctionnalités. Une longue liste avec des dents. Au début, ajouter un bouton ici ou une zone de texte normale là-bas n’est pas si grave. Cela peut même être amusant! Mais attendez, l'utilisateur vient de demander à pouvoir modifier une date. Avez-vous déjà essayé d'implémenter votre propre composant datepicker? Cette demande à elle seule peut vous coûter quelques semaines. Idem avec une fonctionnalité telle que la possibilité de mettre à jour les cellules en direct ou la possibilité d'exporter le contenu d'une grille vers une feuille de calcul Excel, ce que je sais – par expérience – que les utilisateurs demandent tout le temps. Pour avoir une idée de ce qu'implique une telle fonctionnalité, consultez cette implémentation de chargement de données en temps réel dans un exemple d'application créé avec Kendo UI for Angular Data Grid .

De plus, intégrer des boutons, des listes déroulantes, des menus contextuels et divers éléments d'entrée dans votre grille peut donner l'impression d'essayer d'insérer une cheville carrée dans un trou rond si vous utilisez différentes bibliothèques pour chacun Composants. La compatibilité entre vos différents morceaux de code / packages n'est pas la seule préoccupation ici – si votre grille a une entrée de date, vous devrez peut-être ajouter l'internationalisation et la localisation lorsque les utilisateurs sont répartis géographiquement. Cela doit être appliqué à tous les éléments constitutifs de votre grille, ce qui peut être très difficile lorsqu'il est appliqué après coup.

La conformité en matière d'accessibilité est un tout autre jeu de balle, car le respect des directives d'accessibilité nécessitera une première lecture des différentes spécifications, les interpréter pour votre cas d'utilisation spécifique et ensuite les implémenter dans un composant complexe tel que votre grille de type Excel. Ce que nous avons noté à propos de i18n ci-dessus s'applique également ici: si vous ne pensiez pas à l'accessibilité depuis le début, vous pourriez vous retrouver à réécrire d'énormes portions de votre code juste pour essayer d'être conforme.

3. Mais attendez, il y a plus: assistance et maintenance

Rappelez-vous comment, à l’école, nous avons appris pour la première fois les lois de la physique telles qu’elles s’appliquent à un environnement idéal: «Rien ne peut voyager plus vite que la vitesse de la lumière dans le vide.» Il en va de même pour le développement. Si vous travailliez dans le vide, vous pourriez en finir une fois pour toutes avec votre grille et continuer votre vie.

En réalité, vous pourriez être responsable de la plupart ou de toutes ces tâches d'accompagnement: correction de bogues et réponse aux utilisateurs comparer constamment votre grille à ce qu'ils connaissent le mieux: Excel; rédiger de la documentation pour que d'autres puissent également travailler avec; prise en charge du navigateur; problèmes avec les bibliothèques tierces que vous avez mises en œuvre; et la gestion des changements provenant d'une nouvelle version du framework, pour n'en nommer que quelques-uns.

4. Les performances de la grille sont difficiles à optimiser

Au fur et à mesure que vous ajoutez à la liste des fonctionnalités de votre grille de données, vous commencerez à entendre des plaintes selon lesquelles la grille se charge trop lentement. Sur les appareils mobiles, vous devez réfléchir à la manière de gérer en douceur les actions tactiles au lieu de la saisie par la souris et le clavier.

De nombreuses implémentations de grille échouent en raison des frustrations des utilisateurs quant aux performances. Au fur et à mesure que vous commencez à rechercher comment accélérer le chargement de votre grille et gérer les données plus efficacement, la plupart des réponses indiquent des optimisations que vous deviez faire avant même de commencer.

Par exemple, avec la KendoReact Data Grid nous a pris la décision dès le départ de découpler les opérations de données (pagination, tri, filtrage, regroupement, etc.) qui peuvent ralentir le composant des éléments internes de la grille. Dans le cadre de cet effort, nous avons créé une bibliothèque de requêtes de données dédiée qui simplifie le traitement des opérations de données dans la grille. Avec la logique autour des données gérées par les bibliothèques ou le serveur plutôt que par un composant d'interface utilisateur, la grille devient ultra rapide tout en permettant aux utilisateurs de découper et de découper les données à leur guise. C’est déjà fait – et bien fait!

«Ne réinventez pas la roue» est un mantra couramment répété par les développeurs. J'y suis allé, j'ai fait ça, je l'ai imprimé sur un t-shirt. Nous entendons cette phrase si souvent qu'elle ne s'enregistre même plus rarement. Abordons-le avec un esprit débutant pendant une minute.

La plus ancienne roue découverte remonte à environ 5 500 ans en Mésopotamie. Du point de vue actuel, 5500 ans, c'est beaucoup de temps pour les gens d'essayer de créer une meilleure roue, un nouveau type de roue, une roue qui s'appelle la vôtre. En effet, beaucoup ont essayé. Regardez autour de vous, cependant. Nous utilisons toujours la Wheel of Mesopotamia ™, cette forme ronde parfaite qu'un de nos prédécesseurs a inventée plus d'un million d'années après l'apparition des premiers humains.

Maintenant, y a-t-il une meilleure métaphore à utiliser pour un composant d'interface utilisateur qui est au carré 99% du temps? Probablement, mais vous comprenez. Le travail acharné a été fait. Si vous pouvez utiliser la grille de quelqu'un d'autre et que cela sert bien votre objectif, pourquoi passer d'innombrables heures à la recréer au lieu de vous concentrer sur la construction de fusées sur la lune, ou tout ce qui vous plaît.

J'ai mentionné plus tôt que mon équipe a construit plusieurs grilles de données . Nous nous sommes heurtés aux mêmes écueils décrits jusqu'à présent. Cependant, en tant qu'entreprise, nous construisons des grilles de données pour le Web depuis plus de 18 ans, nous savons donc à quoi nous attendre lorsque nous nous engageons à rédiger un tableau à partir de zéro et que nous pouvons planifier en conséquence.

Il y a une dernière réflexion sur laquelle je voudrais vous laisser avant que vous me disiez dans les commentaires à quel point l'écriture d'une grille de données a été formidable pour vous. Comme j'ai passé tellement de temps à expliquer pourquoi vous ne devriez PAS créer votre propre grille JavaScript, je dois vous proposer une alternative. Qu'est-ce que je recommande? Ne réinventez pas la roue. Utilisez l'une des nombreuses roues déjà disponibles: utilisez une grille de données tierce. Et je ne peux parler d'aucune des multiples solutions disponibles, mais je peux dire que l'équipe de Kendo UI a fait de son mieux pour créer ces quatre grilles puissantes, mais faciles à mettre en œuvre:

Donc, avant de vous lancer sur la route longue et sinueuse de l'écriture de votre propre grille, prenez du recul et réfléchissez aux options qui s'offrent à vous. Si vous avez des exigences de base, vous pourrez peut-être créer quelque chose par vous-même ou utiliser l'une des nombreuses grilles de données open source disponibles. Cependant, si vous avez des exigences plus complexes et avancées, ou si vous connaissez suffisamment bien vos utilisateurs pour que vous puissiez les voir demander un jumeau Excel, alors prenez l'une de nos Kendo UI Data Grids pour un tour.

Nous les avons méticuleusement construits pour chaque framework afin de vous garantir de bénéficier d'une grille conviviale pour les développeurs et riche en fonctionnalités qui s'intègre bien à vos applications existantes – et en prime, nous ajoutons plus de 100 autres composants d'interface utilisateur dans chaque bibliothèque pour aide avec toutes les exigences UX non-grid. Allons-y!

P.S. Pour être précis, nous avons écrit beaucoup plus de grilles de données que ces quatre. Si vous souhaitez implémenter des grilles de données pour toute autre technologie, consultez ce qui est disponible dans notre boîte à outils pour développeurs, DevCraft .