Il y a deux ans, j'ai conçu et développé une bibliothèque de stratégie de requêtes JavaScript appelée alovajs. Depuis sa promotion en avril 2023, il a été salué par les développeurs du monde entier et a récolté plus de 2 700 étoiles, notamment la reconnaissance des experts de grandes entreprises.
Actuellement, alova@3.x a été publié, positionné comme « l'outil de requête de nouvelle génération pour des flux de travail rationalisés ».
Je le maintiens sans compensation depuis 30 mois, et la version a atteint 3.x. Au cours de cette période, à travers une réflexion, un rejet et une refonte continus, j'ai eu pour objectif de réaliser quelque chose que d'autres outils de requête n'ont pas fait, devenir un outil qui peut véritablement aider au développement front-end. Je crois avoir trouvé une direction fiable.
C'est-à-dire créer un « outil de requête de nouvelle génération pour des flux de travail rationalisés », maximisant l'assistance au développement front-end en rationalisant le processus d'intégration d'API.
Ci-dessous, l'histoire d'exploration d'alovajs, qui est aussi l'histoire d'un projet open source depuis sa création.
Si les alovajs vous intéressent, je vous invite sincèrement à rejoindre la communauté et à progresser ensemble.
Un jour de mars 2022, en raison de certaines circonstances, j'ai eu l'idée de développer une application appelée "Con of goal". Inspiré par certaines applications, j'espérais que "Con of goal" pourrait permettre des demandes et des soumissions de données sans délai, c'est-à-dire un mode de réponse immédiate, même dans des conditions de réseau faibles ou inexistantes. Cependant, après avoir cherché en ligne sans trouver de solution adaptée, et des solutions de mise à jour optimistes similaires ne répondant pas aux besoins, ma foutue envie de partager m'a amené à décider de l'implémenter sous la forme d'une bibliothèque de requêtes, ce qui a été le point de départ d'alovajs, mais il n'avait pas de nom à cette époque.
Le début d'une bibliothèque n'est pas la conception, ni le développement, mais la clarification des besoins
Conseils de pro : Il est fortement recommandé de comprendre d'abord brièvement la section de présentation d'alovajs pour mieux comprendre le contenu suivant.
A cette époque, il n'y avait pas de positionnement de produit, juste la création d'une bibliothèque JavaScript pour répondre à mes propres besoins. J'ai étudié les bibliothèques de requêtes existantes et listé les besoins suivants :
Ensuite, en fonction des besoins, l'API de la bibliothèque a été conçue.
Pour le besoin 2, trois useHooks principaux ont été conçus : useRequest, useWatcher et useFetcher. Ceci est très familier à tout le monde, comme useRequest de ahooks, useAsyncState de vueuse, react-query et swr, il va sans dire que c'est en effet très pratique.
Étant donné que la conception useHook est utilisée, différents frameworks auront une gestion d'état différente, mais je ne veux pas créer une bibliothèque JavaScript pour chaque framework comme React-Query. Par conséquent, pour les besoins 3, les spécifications des adaptateurs stateHook, des adaptateurs de requête et des adaptateurs de stockage ont été conçues, et différents adaptateurs peuvent être écrits selon les spécifications, séparant l'environnement-cadre et la logique liée à l'environnement d'exécution en modules distincts.
Pour les besoins 4, le modèle de proxy d'instance de méthode a été conçu, et le proxy d'instance de méthode appelle les fonctions de hook de différents adaptateurs, de sorte que même si vous développez une application, vous pouvez démarrer avec alovajs sans aucune méconnaissance, et il peut également être transplanté de manière transparente.
Pour le besoin 5, des bibliothèques JavaScript similaires implémentent la mise en cache sous forme de clés personnalisées, mais mon idée est de me concentrer sur les informations de demande. Le scénario courant est que lors d'une requête sur la même interface avec la même méthode de requête et les mêmes paramètres, il est nécessaire d'accéder aux données de réponse de la dernière fois. Pourquoi n'utilisons-nous pas ces informations de demande comme clés de mise en cache ? Par conséquent, alovajs a conçu un mécanisme de mise en cache automatique, qui est activé par défaut sur les requêtes GET.
Pour le besoin 6, référez-vous et apprenez d'axios.
Ces conceptions ont en effet fait leurs preuves au fil du temps. alovajs est parfaitement compatible avec les frameworks Vue, React, Svelte grâce à la méthode adaptateur, et peut également fonctionner dans divers environnements JavaScript tels que les navigateurs, React Native, UniApp et Taro, tout en conservant une méthode d'utilisation cohérente, ce qui m'a donné un aperçu de j'espère.
Dans les mois suivants, bien qu'Alovajs soit sorti, il n'a pas été promu. D'une part, c'est parce que je l'ai utilisé dans le projet "Con of goal". Bien qu’il ait été tempéré et amélioré dans ce projet, il reste encore très incomplet et son positionnement n’est pas clair. L'introduction de la version initiale est comme ceci.
Plus tard, le projet "Con of goal" a été avorté, mais alovajs persiste toujours.
Avec l'obsession d'avoir été autrefois chef de produit Internet, j'espère toujours faire d'alovajs un produit différencié. Je me demande souvent quelle est la différence entre alovajs et les autres bibliothèques de requêtes ? Pourquoi les utilisateurs devraient-ils utiliser alovajs ? Elle est en effet différente des autres bibliothèques en termes de conception, ce qui n'est pas une question à laquelle on peut répondre immédiatement. Plus tard, j'ai essayé de positionner l'orientation de la bibliothèque de requêtes comme une « bibliothèque de requêtes légère » et une « bibliothèque de requêtes unifiées multi-extrémités », mais elles ont toutes été refusées par moi-même, car elles ne peuvent pas apporter une aide substantielle aux développeurs, et elles ne peuvent pas être appelé avantages.
En septembre 2022, une opportunité m'a fait découvrir l'excellente bibliothèque de requêtes basée sur Vue, vue-request. Ses usePagination et useLoadMore m’ont immédiatement inspiré. Cette forme de mise en œuvre de la pagination m'a fait réaliser que c'est aussi ce que je souhaite. En même temps, cela m'a fait prendre conscience du pouvoir de useHook. Je peux diviser le module en fonction du scénario de demande, utiliser différents useHooks pour différents scénarios, et l'interaction de données transparente précédemment implémentée est en fait l'un des scénarios. Si telle est la direction, les développeurs peuvent choisir différents useHooks en fonction de différents scénarios de demande, ce qui non seulement améliore l'efficacité du développement et réduit la complexité du codage, mais empêche également le front-end junior d'écrire du code inefficace et peut mieux utiliser les fonctionnalités de base de alovajs pour obtenir de meilleures performances et moins de pression sur le serveur. fonctionnalités de requête, jusqu'à présent, la "bibliothèque de stratégie de requête légère" a été choisie par moi.
Ensuite, afin de guider l'orientation future de la conception d'alovajs, j'ai également affiné et résumé le modèle de scénario de demande (RSM) d'alovajs, principalement divisé en quatre processus suivants :
Request timing -> Request behavior -> Request event -> Response processing
Faisons-le, j'ai commencé à reconstruire alovajs 2.0 selon ce positionnement, j'ai séparé la fonction d'interaction transparente des données de 1.0 et j'ai conçu un mécanisme middleware pour s'adapter au développement de stratégies de scénarios de requêtes plus useHooks, étudié et développé la stratégie de pagination et la stratégie d'interaction transparente des données.
La stratégie de pagination d'alovajs est ce que je pense être l'utilisation la plus utile de Pagination. Il utilise la fonction de mise en cache d'alovajs pour réaliser le préchargement des données de première et de dernière page, la recherche de données de pagination, l'anti-rebond au niveau de la demande et fournit une gestion automatisée des nouvelles fonctions d'édition et de suppression, ainsi que l'actualisation des données d'un code de page spécifié. sans réinitialiser.
La stratégie d'interaction transparente des données m'a pris 4 mois, me heurtant constamment à des impasses et repensant constamment le résultat. Il a mis au point une stratégie qui permet aux utilisateurs d'interagir avec les données sans délai, même dans des environnements réseau faibles ou déconnectés, et peut également garantir de manière plus stable le succès de la demande. J'ai conçu un élément de données virtuelles, qui peut être utilisé comme espace réservé pour les données de réponse avant la réponse, donnant aux utilisateurs le sentiment qu'il s'agit d'une réponse immédiate, puis remplacer les données virtuelles par des données réelles une fois la réponse réussie. Selon les résultats de l'exploration actuelle, ses scénarios d'utilisation peuvent être des applications de type éditeur, des modules de configuration du système et des listes plus simples.
Plus tard, des modules de stratégie de requête tels que useForm, useAutoRequest et useSSE ont également été ajoutés, mais c'est loin d'être suffisant.
Le 13 mai 2023, j'ai reçu un tel problème sur github
Au début, je n'ai pas prêté beaucoup d'attention à ce problème, j'ai simplement compris la fonction de génération automatique de code de requête pour openAPI, et j'ai pensé que c'était très bien, mais en raison d'une énergie limitée, je n'ai pas réfléchi profondément à et je n'avais pas pensé à la direction d'alovajs à ce moment-là. Mais récemment, je pensais occasionnellement à l'orientation d'alovajs, et ce problème qui est encore ouvert m'est toujours venu à l'esprit, puis j'ai tranquillement changé l'étiquette de ce problème de « demande de fonctionnalité » à « demande de fonctionnalité : confirmé » .
En même temps, ce problème m'a fait réaliser qu'alovajs peut également réduire la distance de collaboration entre le front-end et le back-end, et simplifier davantage le flux de travail de développement front-end. Voici l'orientation de développement que j'ai définie pour alovajs 3.0 :
alovajs aidera les développeurs à simplifier au maximum le workflow d'intégration des API, il vous suffit de spécifier quelle API utiliser (c'est aussi le résultat d'une réflexion de 3 mois)
Mon plan spécifique est le suivant :
Les étapes 1, 2, 3, 4, 6 de la figure ci-dessus sont résolues en générant automatiquement du code API, mais notre plan de génération ira plus loin par rapport à des outils comme openapi-generator. Il générera automatiquement un type ts complet, des fonctions de demande de description complètes, qu'il s'agisse d'un projet js ou d'un projet ts, il n'est pas nécessaire de l'introduire, laissera les développeurs appeler aussi facilement que d'appeler directement location.reload, et la fonction de requête pourra voir directement la description complète et les invites de type de paramètre de demande.
Étant donné que les fonctions de requête générées automatiquement ont des descriptions complètes et des invites de saisie, le plugin vscode complète la manière interactive de récupérer rapidement les API requises, et vous n'avez plus besoin de vous référer à la documentation de l'API.
Résolvez le problème de l'écart de collaboration front-end et back-end, et toute modification dans l'interface peut être automatiquement notifiée au front-end. Si des changements sont détectés pendant la construction du projet, une erreur sera générée pour arrêter la construction. S'il s'agit d'un projet ts, une erreur sera également générée lors de la compilation et les enregistrements de modifications peuvent également être consultés via le plugin vscode.
Voici la vidéo de démonstration de l'extension vscode.
Comment résoudre l'étape 6 « écrire une logique de requête complexe » ? Bien sûr, il s'agit d'utiliser le module de stratégie de requête, qui présente les caractéristiques de haute performance et basé sur des scènes, et les utilisateurs peuvent utiliser une très petite quantité de code pour implémenter diverses fonctions de requête de scène.
En mars 2024, le plan de développement d'alova@3.0 a été formulé, et il a fallu 4 mois pour restructurer la quasi-totalité du projet avec le membre principal MeetinaXD, et il y a de nombreuses optimisations :
L'architecture sous-jacente a été repensée et un ensemble de hooks peut être utilisé simultanément dans Vue, React, Svelte et même dans le style des options Vue.
La gamme disponible a été augmentée côté serveur. Vous pouvez utiliser alova dans des frameworks côté serveur tels que express, koa et nestjs, et de nouveaux hooks de serveur de stratégie de requête côté serveur ont été ajoutés.
10 configurations dans alova@2.x étaient obsolètes et 9 conceptions ont été optimisées.
De plus, la partie la plus importante de la 3.0, le plugin vscode, qui est en charge de notre membre principal czlin, est également disponible, et il a pratiquement atteint les objectifs que nous nous étions fixés au début.
Jusqu'à présent, alova@3.0 a dépassé la période bêta et peut être utilisé de manière stable dans l'environnement de production.
A cette époque, un article critiqué, Il est temps de remplacer vos axios, est arrivé dans la recherche chaude.
Ce n'était effectivement pas si bien quand il vient d'être lancé, mais je sais que chaque produit ne se réalise pas du jour au lendemain, et il faut du temps pour se précipiter.
L'ordinateur Apple 1 n'avait même pas de boîtier au début
Le parcours de développement de Vue est également un processus d'exploration et de progrès continus
Je suis juste ému par un tel parcours produit, et persister à faire une chose est le moyen le plus simple de réussir. Les bons produits doivent être testés pendant plusieurs années, sans parler des alovajs, qui n'existent que depuis environ un an et demi et qui n'ont été contactés par certaines personnes que depuis 8 mois. Au cours de cette période, il a également exploré de meilleures solutions et avancé étape par étape.
alovajs a initialement conçu des useHooks comprenant useRequest, useWatcher, useEffectWatcher, useManual, useController, puis progressivement réduit à seulement trois hooks principaux : useRequest, useWatcher et useFetcher.
Adresse de validation
Dans la conception de requêtes parallèles, qu'il s'agisse d'implémenter un formulaire similaire à Promise.all, ou la forme actuelle de liaison à la fonction onSuccess, j'ai été empêtré dans plusieurs versions, modifiées d'avant en arrière, et voici la conception du répondeur abandonné de cette année-là.
Enregistrement de validation introuvable
Afin d'être compatible avec les schémas de mise en cache asynchrone tels qu'IndexedDB, j'ai d'abord essayé de concevoir l'adaptateur de stockage comme une fonction asynchrone, mais cela entraînerait une série de problèmes, puis j'ai essayé d'implémenter le mécanisme d'événements via StorageConnector, qui n'est toujours pas assez parfait, et enfin au mécanisme de fonction asynchrone personnalisé localCache actuel.
Adresse de validation
Je remercie également les amis qui ont soutenu et contribué à alovajs. Voici quelques captures d'écran, et de nombreuses contributions ne sont pas incluses.
Et complétez continuellement les détails du document et améliorez les meilleures pratiques, essayez hardiment le plan de version du cache pour le mode de récupération du cache, et afin de fournir des invites de type ts complètes pour alovajs, essayez d'utiliser l'inférence de type automatique pour réduire le difficulté pour les développeurs de définir les types, et consacrent effectivement beaucoup d'efforts à l'optimisation et à la compatibilité avec différents frameworks d'interface utilisateur, etc.
Parmi eux, le document a été grandement modifié deux à trois fois. Je suis reconnaissant à @Orange Peel d'avoir fourni le premier avis de modification de document, et à @Well d'avoir fourni le deuxième avis de modification de document, et notre document a alors une telle réputation.
@green tree m'a aidé à ouvrir de nouvelles idées pour alova.
Beaucoup de choses ne sont plus claires, et les enregistrements sur npmjs m'indiquent que 146 versions ont été publiées.
Il y a aussi de nombreuses personnes sur github qui ont signalé des bugs, et j'ai également répondu et corrigé dans un premier temps. Je suis vraiment très reconnaissant. Si je ne peux pas juger le problème immédiatement, je le reproduirai également sur codesandbox et utiliserai cette démo comme pont de communication avec les utilisateurs.
Merci beaucoup pour votre lecture ?, aussi difficile soit-il, le chemin doit encore continuer.
Si vous reconnaissez alovajs, rendez-vous sur Github pour lui donner une étoile.
Si vous souhaitez comprendre alova, vous pouvez visiter le site officiel, où vous pouvez trouver une documentation plus détaillée et des exemples de code pour vous aider à mieux comprendre et utiliser cet outil.
Si vous avez des questions, vous pouvez rejoindre les discussions de groupe suivantes pour consultation, ou vous pouvez également publier des discussions dans le référentiel github. Si vous rencontrez des problèmes, veuillez les soumettre dans les problèmes github et nous les résoudrons dans les plus brefs délais.
Nous vous invitons également à apporter votre force, veuillez consulter le Guide de contribution.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!