9 choses apprises Construire la même application avec Angular & React

J'ai réécrit une application Angular avec React pour comparer et contraster le développement d'applications Angular et React. Voici 9 choses que j'ai apprises au cours du processus de réécriture.

J'ai réécrit une application Angular avec React.

Je l'ai fait pour deux raisons: d'abord, j'apprends React dans mon nouveau rôle de KendoReact défenseur des développeurs, et je trouve que travailler sur de vraies applications est la meilleure façon d'apprendre une nouvelle technologie. Deuxièmement, je voulais vraiment comparer React à Angular, car j'ai passé les dernières années de ma carrière à travailler avec Angular, et je voulais voir comment React aborde les mêmes problèmes de développement Web.

Dans cet article, je Je vais énumérer neuf choses que j'ai apprises au cours du processus de réécriture, mais d'abord, je vais vous donner un peu de contexte sur l'application elle-même afin que vous ayez un peu de contexte.

Contexte

GO Checklists est une application Web que les joueurs de Pokémon GO utilisent pour suivre les Pokémon qu'ils ont capturés dans un certain nombre de catégories différentes.

Avant de rire, vous devez savoir que GO Checklists compte environ 10 000 utilisateurs et que le jeu qu'il prend en charge, Pokémon GO, a rapporté 1,4 milliard de dollars en 2019 . (Pour référence, Fortnite a gagné 1,8 milliard de dollars.)

Donc, même si cette application est relativement simple, elle a une véritable base d'utilisateurs que je ne veux pas perdre. Par conséquent, je devais m'assurer que la réécriture préservait toutes les fonctionnalités existantes et n'introduisait pas non plus de régressions de performances.

Avec ce contexte à l'esprit, regardons ce que j'ai trouvé.

1) Réagir est plus simple dans plusieurs Ways

Lorsque j'ai commencé avec React, la première chose que j'ai remarquée était la simplicité de la structure de projet par défaut de React – du moins par rapport à Angular. Dans Angular, une simple application hello world avec un composant et un routage ressemble à ceci.

 src
├── app
│ ├── routage d'application  .module  .ts 
│ ├── app  .component  .css 
│ ├── app  .component  .html 
│ ├── app  .component  .ts 
│ ├── app  .module  .ts 
│ └── helloworld
│ ├── helloworld-routing  .component  .ts 
│ ├── helloworld  .component  .css 
│ ├── helloworld  .component  .html 
│ ├── helloworld  .component  .ts 
│ └── helloworld  .module  .ts 
├── index  .html 
├── styles  .css 
└── main.ts

Et l'équivalent dans React ressemble à ceci.

.
├── public
│ └── index  .html 
└── src
    ├── App  .css 
    ├── App  .js 
    ├── index  .css 
    └── index.js

Le fait d'avoir une arborescence de fichiers plus petite a facilité la navigation de l'application lors du codage, ce qui était formidable, mais le véritable avantage était l'architecture de mon application. Comme les composants React sont considérablement plus légers à créer et à utiliser, je me suis retrouvé à expérimenter la modularisation de mon code React plus que je ne l'ai fait avec Angular.

Par exemple, lors de la recréation de la page principale de mon application dans React, j'ai créé

[19659029] et composants que je n'avais pas pris la peine de construire avec Angular, et j'ai trouvé le résultat final plus propre.

La simplicité de React ne s'applique pas seulement à sa structure de fichiers et à son modèle de composant. Une chose qui m'a toujours dérangé à propos d'Angular est l'ensemble vertigineux de dépendances que le framework installe lorsque vous démarrez une application. Voici la liste des dépendances que vous obtenez avec la commande CLI angulaire ng serve à ce jour.

 "dépendances" : {
   "@ angular / animations" :  "~ 8.2.14" ,
   "@ angulaire / commun" :  "~ 8.2.14" ,
   "@ angular / compiler" :  "~ 8.2.14" ,
   "@ angular / core" :  "~ 8.2.14" ,
   "@ angular / forms" :  "~ 8.2.14" ,
   "@ angular / platform-browser" :  "~ 8.2.14" ,
   "@ angular / platform-browser-dynamic" :  "~ 8.2.14" ,
   "@ angular / router" :  "~ 8.2.14" ,
   "rxjs" :  "~ 6.4.0" ,
   "tslib" :  "^ 1.10.0" ,
   "zone.js" :  "~ 0.9.1" 
},
 "devDependencies" : {
   "@ angular-devkit / build-angular" :  "~ 0.803.21" ,
   "@ angular / cli" :  "~ 8.3.21" ,
   "@ angular / compiler-cli" :  "~ 8.2.14" ,
   "@ angular / language-service" :  "~ 8.2.14" ,
   "@ types / node" :  "~ 8.9.4" ,
   "@ types / jasmine" :  "~ 3.3.8" ,
   "@ types / jasminewd2" :  "~ 2.0.3" ,
   "codelyzer" :  "^ 5.0.0" ,
   "noyau de jasmin" :  "~ 3.4.0" ,
   "jasmine-spec-reporter" :  "~ 4.2.1" ,
   "karma" :  "~ 4.1.0" ,
   "karma-chrome-launcher" :  "~ 2.2.0" ,
   "karma-coverage-istanbul-reporter" :  "~ 2.0.1" ,
   "karma-jasmin" :  "~ 2.0.1" ,
   "karma-jasmine-html-reporter" :  "^ 1.4.0" ,
   "rapporteur" :  "~ 5.4.0" ,
   "ts-node" :  "~ 7.0.0" ,
   "tslint" :  "~ 5.15.0" ,
   "tapuscrit" :  "~ 3.5.3" 
}

Je travaille avec Angular depuis des années et je ne pourrais pas vous dire ce que font la moitié de ces dépendances, ni pourquoi elles sont nécessaires dans une application Hello World. Et comme avec la structure de fichiers, avoir une liste de dépendances aussi folle a des conséquences réelles pendant le développement.

Par exemple, dans les grandes applications angulaires, j'ai trouvé que le suivi de mes propres dépendances et devDependencies devient problématique, car ils peuvent se perdre entre tous les dépendances angulaires qui encombrent votre package.json .

Avec React la liste équivalente des dépendances pour une nouvelle application ressemble à ceci.

 "dépendances" : {
   "@ testing-library / jest-dom" :  "^ 4.2.4" ,
   "@ testing-library / react" :  "^ 9.3.2" ,
   "@ testing-library / user-event" :  "^ 7.1.2" ,
   "réagir" :  "^ 16.12.0" ,
   "react-dom" :  "^ 16.12.0" ,
   "react-scripts" :  "3.3.0" 
}

Cela vous facilite vraiment la vie en tant que développeur lorsque vous avez moins de choses à gérer mentalement, et l'arborescence de fichiers, le modèle de composant et la liste de dépendances plus simples de React étaient tous une bouffée d'air frais.

Mais comme toutes les bonnes choses dans la vie, quand quelque chose semble trop beau pour être vrai, c'est généralement le cas, et bien que React rend ces processus simples, il se passe beaucoup plus de choses sous le capot.

2) La création de l'application React fait beaucoup de magie [19659012] Créer une application React qui est la méthode par défaut et recommandée pour démarrer les applications React, fait un travail incroyable en simplifiant le processus de démarrage et de gestion de nouvelles applications React. Mais à un moment donné, j'ai commencé à me demander comment mes applications avaient tant de fonctionnalités avec si peu de dépendances. Puis j'ai trouvé cette section concernant le README de Create React App .

Holy features Batman! Pour avoir une idée de la lourdeur de l'application Create React, vous pouvez exécuter le script d'éjection de l'outil qui installe toutes les dépendances transitoires et les fichiers de configuration de votre application directement dans votre application.

I encouragez chaque développeur React à exécuter le script d'éjection au moins une fois, juste pour avoir une idée de l'ampleur de ce que Create React App fait pour vous. Par exemple, au moment d'écrire ces lignes, une application hello world post-éjection a 56 dépendances. Oui, 56.

Cette même application possède maintenant un ensemble vertigineux de scripts, ainsi qu'un fichier de configuration de webpack de 674 lignes qui commence par une liste impressionnante

Pour être juste, la plupart des petites et moyennes applications n'auront jamais besoin d'être éjectées, et les valeurs par défaut fonctionneront très bien . Je n'ai aucune intention d'éjecter GOChecklists car je n'ai pas besoin de faire quoi que ce soit hors de l'ordinaire. Cela étant dit, voir l'ampleur de ce que fait l'application Create React me donnerait une pause si je commençais une grande application React que j'avais l'intention de maintenir pendant des années.

Le monde du logiciel change rapidement, et je ne voudrais pas compter sur un processus d'éjection pas spécialement propre pour répondre à mes besoins futurs. Heureusement, vous pouvez créer des applications React sans utiliser Create React App, ce qui est probablement ce que je ferais si je commençais une grande application React aujourd'hui. Voici le meilleur guide que j'ai trouvé pour configurer cela.

3) Les crochets React sont déroutants

React a récemment introduit un nouveau concept appelé Les crochets React qui est une nouvelle façon de gérer l'état et d'autres fonctionnalités de React sans écrire de classe.

Pour moi, React Hooks est un microcosme de ce que je ressens à propos de React en général: ils sont puissants et concis, mais aussi ésotériques parfois.

Pour en discuter , commençons par le premier exemple de la documentation React sur les crochets .

 import  React, {useState}  de   'react' ;

 fonction   Exemple  ()  {
   const  [count, setCount]  = useState ( 0 );

   retour  (
     < div > 
       < p >  Vous avez cliqué {count} fois  </  p > 
       <  bouton   onClick  =  {()  =>  setCount (count + 1)}>
        Cliquez moi
       </  bouton > 
     </  div > 
  );
}

Si vous n'avez jamais vu React Hooks en action auparavant, ce code peut sembler un peu bizarre, principalement parce que useState est une API bizarre. Commençons par examiner la ligne de code ci-dessous, car c'est celle qui utilise un crochet React.

 const [ count setCount] = useState ( 0 )

Ce code crée une nouvelle variable d'état nommée count ainsi qu'une fonction pour changer cet état nommé setCount () . Vous passez useState la valeur initiale de votre variable d'état, qui dans ce cas est 0 .

Bien qu'initialement déroutant, j'ai trouvé useState comme étant assez élégant, et je me suis habitué à l'API après l'avoir utilisé dans quelques fichiers.

Par exemple, le prochain crochet dont j'avais besoin était le crochet d'effet de React, qui, selon la documentation de React «vous permet d'effectuer des effets secondaires dans les composants de fonction. . "Cette description à elle seule est un peu déroutante, mais leur exemple initial est assez simple.

 import  React, {useState, useEffect}  de   'react' ;

 fonction   Exemple  ()  {
   const  [count, setCount]  = useState ( 0 );

  useEffect ( ()  =>  {
     document  .title =  `Vous avez cliqué sur  $ {count}  fois» ;
  });

   retour  (
     < div > 
       < p >  Vous avez cliqué {count} fois  </  p > 
       <  bouton   onClick  =  {()  =>  setCount (count + 1)}>
        Cliquez moi
       </  bouton > 
     </  div > 
  );
}

Dans cet exemple, useEffect met à jour le titre du navigateur à chaque fois que la variable d'état count change. Assez simple.

Le premier problème que j'ai rencontré dans mon application a été de savoir comment exécuter un effet exactement une fois. Essentiellement, j'avais besoin d'obtenir des données JSON à partir d'un backend lorsque mon composant se charge, ce qui semble être un cas d'utilisation extrêmement courant. Une recherche rapide sur Google m'a dit de transmettre useEffect un tableau vide pour ce faire, ce qui est étrange, mais cela a fonctionné.

 React.useEffect ( ()  =>  {
  pokemonService
    .get (pageMode)
    .then ( data  =>  {
      
    });

}, []);

Ce code a fonctionné, mais j'ai eu cette erreur dans ma console.

 .  /src/components/Dex.js
  Ligne 40: 6: React Hook React.useEffect a des dépendances manquantes: 'pokemonService'. Incluez-le  ou  supprimez la dépendance  tableau  react-hooks / exhaustive-deps

Je ne sais toujours pas pourquoi React pense que pokemonService devrait être une dépendance de mon effet. Si vous recherchez ce problème sur Google, ce que j'ai fait, vous trouvez l'un des fils les plus longs que j'ai jamais vus sur GitHub se terminant par cette conclusion déroutante.

Je suis nouveau dans React, mais je n'ai aucune idée de ce que cela signifie. Et après avoir lu l'intégralité du fil GitHub, j'ai décidé d'abandonner et de supprimer l'avertissement comme un développeur responsable. Mon code ressemble maintenant à ceci.

 React.useEffect ( ()  =>  {
  pokemonService
    .get (pageMode)
    .then ( data  =>  {
      
    });


}, []);

Une grande partie de cela est sur moi, car je suis nouveau dans React et je cherche toujours à comprendre comment ces nouvelles API fonctionnent. Mais j'ai tendance à préférer utiliser des frameworks et des API intuitifs, et tous les hooks React au-delà de useState () m'ont dérouté, ce qui me fait hésiter à les introduire dans une grande base de code.

Cela étant dit, Je prévois de revenir sur ce sujet après avoir eu plus de temps pour apprendre et expérimenter. Et aussi, même si j'ai trouvé Hooks déroutant, il y avait certainement des API Angular déroutantes que j'étais heureux de supprimer.

4) I Don't Miss Angular's Modules, or Services, or Dependency Injection

Ma partie la moins préférée de travailler dans Angular créait et configurait des modules. Les modules angulaires sont essentiellement des fichiers de métadonnées que vous devez fournir manuellement pour indiquer au compilateur angulaire et à l'exécution comment votre application doit fonctionner.

Voici le premier exemple fourni par la documentation angulaire .

 import  {NgModule}  de   '@ angular / core' ;
 importation  {BrowserModule}  de   '@ angular / platform-browser' ;
@NgModule ({
  importations: [ BrowserModule ],
  fournisseurs: [ Logger ],
  déclarations: [ AppComponent ],
  exportations: [ AppComponent ],
  bootstrap: [ AppComponent ]
})
 classe d'exportation     AppModule  {} 

J'ai passé une bonne partie de ma carrière à travailler avec Angular, et je ne pourrais toujours pas vous expliquer pourquoi toutes ces métadonnées sont nécessaires. J'ai également passé une grande partie de ma carrière à enseigner Angular, et je peux vous dire qu'essayer de comprendre la différence entre importations fournisseurs déclarations et les exportations dans ces fichiers sont une source courante de confusion.

Parce qu'il y a tellement de choses à déclarer individuellement, les modules angulaires ont tendance à être fastidieux à créer, et également sujets aux erreurs, car il est facile de mettre accidentellement un importe ou vice versa, et les messages d'erreur ne vous dirigent pas toujours dans la bonne direction.

De même, Angular a également un concept de services et d'injection de dépendances que j'ai

La création d'un service dans Angular prend quelques étapes, dont la première consiste à créer un fichier .service.ts et à marquer la classe exportée de ce service avec un @Injectable décorateur.

 @Injectable  ()
 classe d'exportation     MyService   {...}

Ensuite, vous devez inclure votre nouveau service dans le tableau des fournisseurs de chaque module angulaire dans lequel vous avez l'intention d'utiliser le service.

 @  NgModule  ({
   fournisseurs : [MyService],
 ...
})

Et enfin, vous injectez votre service dans vos composants en l'incluant comme argument dans le constructeur de votre composant.

  constructeur  ( privé  myService : MyService)  

Si tout cela vous semble un peu déroutant, c'est parce que c'est le cas.

Il y a toute une science derrière l'injection de dépendance et pourquoi Angular adopte cette approche, mais cela m'a toujours paru inutile. Le seul avantage concret que j'ai jamais retiré de l'injection de dépendance est pendant les tests unitaires, car les services injectés sont faciles à simuler lors des tests. Mais les bibliothèques de simulation JavaScript sont assez puissantes de nos jours, et cet avantage ne rend pas l'abstraction digne de tous les tracas pour moi.

React n'a rien de cette structure, et franchement, c'est une sorte de libération. Si j'ai besoin d'une nouvelle fonctionnalité dans mon application, je crée un nouveau dossier et j'ajoute un nouveau fichier. Si j'ai besoin d'un service, je crée un fichier qui renvoie une fonction.

Mais bien que j'apprécie la simplicité de React pour la plupart des choses, il y a un outil que j'ai abandonné que je ne savais pas combien je manquerais.

5) I Miss TypeScript

Je pourrais ne manquez pas les modules ou services Angular, mais je manque définitivement TypeScript, ce que je n'aurais jamais pensé avoir dit il y a quelques années.

Le processus d'abandon de TypeScript m'a rappelé un article de l'équipe Slack a fait quand ils ont adopté TypeScript . Les deux plus grandes découvertes qu'ils ont faites ont été:

«Premièrement, nous avons été surpris par le nombre de petits bogues que nous avons trouvés lors de la conversion de notre code.»

«Deuxièmement, nous avons sous-estimé la puissance de l'intégration de l'éditeur. Grâce au service de langage de TypeScript, les éditeurs avec une fonction de saisie semi-automatique peuvent prendre en charge le développement avec des suggestions contextuelles. "

J'ai aussi découvert ces choses, juste de façon négative.

Tout d'abord, je m'étais habitué à écrire TypeScript que j'ai complètement oublié de faire toute validation de type sur mes paramètres de fonction JavaScript. Je m'attendais simplement à ce qu'ils soient toujours ce que je pensais qu'ils seraient, et – alerte spoiler – ils ne l'étaient pas.

J'ai fini par ajouter un tas de vérifications de type et parseInt appels à ma base de code, et chaque fois que je regarde ce code, je me déteste un peu.

En ce qui concerne l'intégration de l'éditeur, j'ai été agréablement surpris de voir à quel point le code Visual Studio s'est amélioré à IntelliSense dans les fichiers JavaScript vanilla, mais il ne peut toujours pas correspondre ce que TypeScript fournit.

J'ai spécifiquement manqué les messages d'erreur en ligne utiles que vous obtenez avec TypeScript. Par exemple, supposons que j'essaye de faire quelque chose de stupide comme ceci.

  parseInt  ( "10"  "10" );

Le deuxième paramètre ici n'est pas valide (il doit être un nombre), mais dans un fichier .js Code ne donne aucune indication que quelque chose ne va pas. Ce sont de petites choses comme celle-ci qui m'ont fait regretter d'avoir abandonné un framework qui utilise TypeScript par défaut.

Une dernière note: je sais que Create React App prend désormais en charge l'utilisation de TypeScript, et c'est quelque chose que j'ai l'intention de vérifier. Cela étant dit, la bonne chose à propos d'Angular est que 100% des exemples de code, des articles de documentation, des questions sur Stack Overflow et ainsi de suite utilisent tous TypeScript – tandis que la faction TypeScript de la communauté React semble être une minorité. Au moins pour l'instant ?

6) Je préfère la façon dont Angular gère les CSS

Dans Angular, CSS fonctionne dans un sens et il fonctionne très bien. Lorsque vous définissez un composant, vous pouvez fournir une propriété de métadonnées styleUrls et lui transmettre un tableau d'URL de feuille de style. Habituellement, cela ressemble à ceci.

 importation  {Component}  de   "@ angular / core" ;

@Composant({
  sélecteur:  "mycomponent" ,
  styleUrls: [ "./ my.component.css" ],
  templateUrl:  "./ my.component.html" 
})
 classe d'exportation    MyComponent {...}

Angular garantit que le CSS que vous écrivez dans ces fichiers est limité à ce composant. Signification, si vous écrivez une règle comme h4 {couleur: bleu; } Angular s'assurera que la règle couleur: bleu ne sera appliquée qu'aux éléments

rendus par MyComponent et pas à tous les éléments

de votre application. [19659003] J'ai toujours trouvé que c'était une manière élégante de gérer CSS. J'ai placé toutes mes règles à l'échelle de l'application et les noms de classe partageables dans un fichier au niveau de l'application .css puis j'ai placé mon style spécifique au composant dans des fichiers de portée spécifiques au composant.

Dans React CSS, c'est le Far West. Vous pouvez presque obtenir l'équivalent de l'approche CSS d'Angular en utilisant quelque chose appelé modules CSS qui vous permet d'écrire une série de noms de classe qui sont limités à un composant par défaut. Pour un composant React qui ressemble à ceci:

 .heading  { color : blue; }

 importation  React  de   "react" ;
 importez  des styles  de   "./ myComponent.module.css" ;

 fonction d'exportation   par défaut     MyComponent  ()  {
   return   < h1   className  =  {styles.heading} >  Salut  </  h1 > ;
}

Cela fonctionne, mais vous êtes limité à utiliser uniquement les noms de classe dans vos fichiers CSS, et vous devez appliquer manuellement ces noms de classe à l'aide de JSX (par exemple className = {styles.heading} dans le code ci-dessus), et cela peut devenir maladroit dans les applications du monde réel où vous devez gérer de nombreux noms de classe.

L'autre option populaire pour le style au niveau des composants dans React est d'utiliser une technique appelée CSS-in-JS, qui, comme son nom l'indique, vous permet d'appliquer directement les règles CSS en JavaScript. J'ai expérimenté cette approche, et jusqu'à présent, je l'ai trouvée étonnamment élégante. Par exemple, voici à quoi ressemble un de mes composants en utilisant des composants de style l'une des bibliothèques les plus populaires pour effectuer CSS-in-JS dans React.

 import  React  de [19659054] "réagit" ;
 importation  stylisé  de   "styled-components" ;

 const  LoadingImage = styled.img  `
  position: fixe;
  haut: 50%;
  gauche: 50%;
  margin-top: -60px;
  marge gauche: -60px;
";

 fonction d'exportation   par défaut   fonction   Chargement  ()  {
   retour  (
     < LoadingImage 
       src  =  "/ images / loading.gif" 
       alt  =  "Loading" > 
     </ 19659062] </  LoadingImage > 
  );
}

Bien que j'aime initialement la méthodologie CSS-in-JS, j'ai des problèmes de performances, car les composants stylisés appliquent CSS au moment de l'exécution plutôt qu'au moment de la construction, et je suis préoccupé par le coût de le faire à grande échelle. [19659003] Je sais qu'il existe des options CSS-in-JS qui appliquent le style au moment de la construction, et c'est un sujet que j'ai l'intention de rechercher au cours des prochaines semaines.

Quoi qu'il en soit, la raison pour laquelle je préfère l'approche angulaire est tout cette recherche n'était pas nécessaire pour faire du CSS dans Angular. Angular a une manière saine et performante de gérer CSS, et cela fonctionne.

7) React a une empreinte plus petite, mais Angular s'améliore

Angular est un cadre plus grand que React, et en tant que tel, je m'attendais à ce que mon application soit plus petite lorsque je suis passé d'Angular à React

Pour obtenir des repères précis que je pourrais utiliser pour une comparaison, j'ai fait ce qui suit:

1. J'ai créé chaque application pour une utilisation en production, ce qui signifiait exécuter ng build --prod pour Angular, et npm run build pour React
2. J'ai généré des versions compressées .gzip de chaque fichier JavaScript généré en exécutant gzip .js --keep
3. J'ai exécuté http-server --gzip dans les dossiers de génération générés respectifs de chaque application, afin d'avoir un serveur HTTP local que je pourrais utiliser pour tester chaque application sur
4. J'ai ouvert la page d'index de chaque application dans une nouvelle fenêtre Chrome incognito

Mon application Angular exécutait la version 8.1.2, et sa seule dépendance externe était RxJS .

Ma version Angular a fini par être trois fichiers JavaScript qui étaient un 93,0 Ko après compression gzip.

Mon application React exécutait la version 16.12.0, et sa seule dépendance externe était React Router .

Ma build React a fini par être deux fichiers JavaScript qui étaient une combinaison 52,4 Ko après compression gzip.

Au total, le passage de React à Angular a réduit ma charge utile JavaScript de 93 Ko à 52 Ko, ce qui était plutôt agréable.

Cela étant dit, je suis assez impressionné par tout ce que l'équipe Angular a fait pour réduire la taille de ses paquets au fil des ans. En tant que personne qui se souvient du moment où les faisceaux angulaires ont commencé à 300 Ko, voir un nombre inférieur à 100 Ko est un excellent signe que des caractéristiques comme le chargement différentiel angulaire font une réelle différence. Et la prochaine version d'Angular 9 comprend un nouveau moteur de rendu par défaut qui promet de réduire encore plus la taille des bundles angulaires.

Pour l'instant, React a toujours l'avantage de vous permettre de créer de plus petites applications, mais il

8) Je m'inquiète de la façon dont les applications React évolueront

Pour expliquer mes réflexions sur ce point, je dois vous donner un peu de contexte. Au cours des dernières années, j'ai travaillé en tant que défenseur des développeurs sur NativeScript qui est un projet qui vous permet de créer des applications iOS et Android en utilisant des cadres comme Angular. Dans le cadre de mon rôle de défenseur des développeurs, j'ai dû exécuter de nombreuses applications, que ces applications soient des applications personnelles, des applications de démonstration ou des applications clientes.

Alors que je passais plus de temps dans ce rôle, j'ai commencé à apprécier comment Angular's un ensemble extrêmement complet de directives de développement m'a permis de sauter facilement dans des applications inconnues et de trouver rapidement mon chemin.

En revanche, lorsque je saute dans une application React aléatoire, je dois immédiatement me demander un nombre des questions. Les développeurs de cette application ont-ils utilisé l'application Create React? Que font-ils pour CSS? Ont-ils utilisé Redux? Et les crochets? Que signifient ces conventions de dénomination?

Pour être juste, ce n'est pas nécessairement une mauvaise chose que React vous donne plus de choix et de liberté. Heck, j'ai complimenté React sur cette flexibilité à plusieurs reprises dans cet article. Cependant, je pense que les développeurs qui lancent de nouvelles applications React, en particulier les grandes applications React, devraient s'efforcer de suivre autant que possible les conventions établies de la communauté, comme le guide de style React / JSX d'Airbnb .

Cela vaut également la peine établir des conventions au sein de votre propre organisation afin que vos applications React restent aussi cohérentes que possible. Toutes les optimisations d'intégration que vous effectuez sont vraiment importantes, car les développeurs feront inévitablement évoluer votre équipe.

9) Cela n'a vraiment pas d'importance quel framework vous utilisez

Si vous êtes venu dans cet article, cherchez-moi à vous recommander fortement un framework sur un autre, eh bien j'ai de mauvaises nouvelles pour vous: malgré les différences entre Angular et React, ma plus grande conclusion est que, au bout du compte, les deux frameworks sont remarquablement similaires.

React et Angular les deux font la liaison de données, ils ont tous deux une syntaxe de modélisation riche, ils gèrent tous les deux des événements, ils ont tous les deux des routeurs, et ils vous permettent tous les deux d'utiliser des fonctionnalités JavaScript modernes.

mes deux bases de code pour être étonnamment semblables. Pour vous donner un exemple, voici deux morceaux de code qui créent un élément de liste avec Angular (en haut) et React (en bas).

Assez similaire, hein?

Cela étant dit, malgré les similitudes, je pense qu'il y a des différences entre les deux cadres qui importent. En général, je trouve que React vous donne plus de flexibilité dans la façon dont vous choisissez de créer vos applications, et Angular vous donne plus de structure. Cette structure peut être avantageuse lorsque vous travaillez sur de grandes applications ou sur une grande équipe, mais vous pouvez répliquer une structure similaire dans React en respectant des guides de style bien établis.

Aucune des deux approches n'est fausse, et le cadre que vous devez choisir descend aux préférences personnelles, ainsi qu'aux besoins de votre équipe ou de votre organisation. En cas de doute, créez une petite application avec les deux pour voir quel framework répond le mieux à vos besoins. C’est ce que j’ai fait ?

CONSEIL : Les développeurs React et Angular ont tous deux besoin de composants d’interface utilisateur, et nous les fabriquons pour les deux frameworks! Si vous êtes un développeur React, vous devriez consulter KendoReact et si vous êtes un développeur Angular, vous devriez essayer Kendo UI for Angular ???

---