Cet article concerne le calendrier de l'Avent EDOCODE 2024, publié le 16 décembre 2024.
L'article précédent a été rédigé par Taiji Yamada, chef de produit chez EDOCODE : Système de messagerie automatisé utilisant les webhooks Notion et l'outil sans code "Make" (l'article est en japonais).
Veuillez également consulter le calendrier de l'Avent Wano de notre société mère !
Notre application, Gojiberry, est une application d'enquête Shopify qui aide les commerçants à recueillir de précieux commentaires de leurs clients.
Dès le début, nous avons construit Gojiberry avec un développement piloté par les tests (TDD) pour garantir que notre application est exempte de bogues et que nous pouvons publier de nouvelles fonctionnalités en toute confiance sans casser les fonctionnalités existantes. Cette fondation nous a permis d'apporter des changements à grande échelle, comme la migration de Create React App (CRA) vers Vite, avec un minimum de perturbations.
Lorsque CRA est devenu obsolète et que ses dépendances sont devenues obsolètes, nous avons décidé qu'il était temps de passer à un outil de construction moderne qui prendrait mieux en charge notre application en pleine croissance. La grande taille de notre base de code a ajouté une certaine complexité, mais le passage à Vite en valait la peine.
Notre objectif était de migrer nos deux projets React :
Si vous êtes propriétaire d'une boutique Shopify et que vous cherchez à recueillir des commentaires clients exploitables, essayez Gojiberry dès aujourd'hui sur l'App Store de Shopify !
CRA nous a bien servi dans le passé, mais il n’est plus maintenu et ses dépendances sont devenues obsolètes. Cela a posé plusieurs défis :
L'une des plus grandes améliorations de user-events v14 est l'obligation d'utiliser wait pour toutes les méthodes d'interaction. Cela élimine le besoin d'encapsuler les actions dans wait waitFor, ce qui rend le code de test plus propre et plus facile à maintenir.
Avant (événements utilisateur v13) :
import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import MyComponent from './MyComponent';
test('updates state on click', async () => {
render(<MyComponent />);
userEvent.click(screen.getByRole('button'));
await waitFor(() => {
expect(screen.getByText('Updated state')).toBeInTheDocument();
});
});
Après (événements utilisateur v14) :
import { render, screen } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import MyComponent from './MyComponent';
test('updates state on click', async () => {
render(<MyComponent />);
userEvent.click(screen.getByRole('button'));
await waitFor(() => {
expect(screen.getByText('Updated state')).toBeInTheDocument();
});
});
Ce changement simplifie les tests en supprimant le besoin de gérer explicitement les changements d'état avec waitFor. Les développeurs n'ont plus besoin de réfléchir au moment d'inclure wait waitFor, car la bibliothèque le gère automatiquement.
Les améliorations apportées aux événements utilisateur v14 et à Vitest ont résolu bon nombre de ces problèmes, offrant une expérience de développement plus propre, plus rapide et plus cohérente.
Avant de choisir Vite, nous avons évalué Next.js et Remix. Bien que les deux soient des frameworks puissants, ils ont nécessité des changements importants dans notre base de code et notre infrastructure :
Next.js et Remix :
Pourquoi nous avons choisi Vite :
En choisissant Vite, nous avons évité la complexité liée à l'adoption d'un framework à part entière tout en récoltant les avantages d'un outil de construction moderne et léger.
Nous avons abordé la migration de manière systématique puisque notre monorepo contient deux projets npm distincts. Voici comment nous avons exécuté la migration :
Commencez par le plus petit projet :
Étapes de migration :
Le processus pour chaque projet a suivi ces étapes :
Répéter pour le projet plus vaste :
La migration de CRA vers Vite, ainsi que la transition vers Vitest et user-events v14, ont apporté des améliorations substantielles à notre flux de travail de développement :
La migration a changé la donne, nous permettant d'itérer plus rapidement tout en conservant la confiance dans notre base de code.
Voici quelques points à retenir de notre expérience :
La migration de CRA vers Vite et Vitest a apporté des améliorations significatives à notre flux de travail. Nous bénéficions désormais de builds plus rapides, d'un code de test plus propre avec les événements utilisateur v14 et d'une base de code plus résiliente grâce à des règles TypeScript plus strictes.
L'un des facteurs clés qui ont rendu cette transition plus fluide a été notre investissement initial dans le développement piloté par les tests (TDD). Grâce à une suite complète de tests en place, nous avons pu apporter des modifications massives en toute confiance sans interrompre les fonctionnalités existantes.
Si vous envisagez une migration similaire, nous espérons que notre expérience vous fournira des informations précieuses pour guider votre voyage.
Demain, 17 décembre 2024, l'article sera Passer du B2C au B2B : la confession d'un marketeur par Amee Xu, responsable marketing produit chez Gojiberry.
Chez Wano Group, nous recrutons ! Si vous êtes intéressé, veuillez consulter nos postes ouverts en utilisant le lien ci-dessous :
EMPLOIS | Groupe Wano
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!
Quelles sont les méthodes pour implémenter la surcharge d'opérateurs en langage Go ?
Comment fermer le port 445
Solution d'erreur HTTP 503
format de données json
Exigences de configuration de l'ordinateur de programmation Python
La différence entre MS Office et WPS Office
Quelle est la différence entre Douyin et Douyin Express Edition ?
Dernier classement des échanges de devises numériques
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
