React architecture pour une application métier énorme

Question

Nous avons donc récemment choisi React au sein de notre société comme technologie front-end pour la création de notre énorme application Web pour entreprises. En disant récemment, je veux dire que nous n’avons aucune expérience préalable de React (nous avons une vaste expérience d’AngularJS), et en disant énorme application, je veux dire que c’est vraiment énorme et très dynamique avec beaucoup, beaucoup de fonctionnalités et de fonctionnalités différentes.

Parce que nous aurons beaucoup de composants énormes qui jouent tous un rôle très important et qui ont une logique complexe, et parce que nous voulons qu’ils soient facilement enfichables et réutilisables, nous voulons qu’ils soient aussi isolés que possible du monde extérieur et des autres. parties de notre application, car sinon, en raison de leur taille et de leurs fonctionnalités complexes, il serait pratiquement impossible de les développer et de les maintenir. C’est la raison pour laquelle nous avons décidé de NE PAS utiliser Redux, du moins au début, pendant le développement de composants distincts, car cela compromet l’isolation des composants et rend impossible la compréhension de la logique du flux de données de l’application dans son ensemble. Composants. Bien que je pense que notre choix pourrait être erroné, car comme je l'ai déjà mentionné, nous n'avons aucune expérience de React.

Comme je l'ai déjà mentionné, l'application est très dynamique. J'entends par là que les composants sont réellement rendus par des données. Nous utilisons différentes classes de fournisseurs de configuration qui interagissent avec nos points de terminaison API pour obtenir les éléments de la configuration de notre application, tels que les configurations de navigation, les pages, divers formulaires, listes, etc., puis nous essayons de restituer les composants lus à partir de cette configuration.

Le problème est que, après quelques semaines de lutte pour obtenir l’élan acquis avec React et pour découvrir les modèles appropriés et les solutions communes à nos problèmes, nous avons discuté avec notre équipe, peut-être que React n’est peut-être pas la bonne technologie pour nous, car une bibliothèque d'interface utilisateur, pas un cadre, et cela ne nous aide pas beaucoup, mais ajoute simplement ses règles de rendu que nous devons parfois modifier pour obtenir la dynamique et l'indépendance des composants que nous souhaitons.

En ce qui concerne l'isolation des composants et la gestion des flux de données, j'ai personnellement entendu dire qu'il existe un langage pour le développement frontal Elm qui possède une architecture de flux de données assez robuste dans laquelle chaque composant a son propre modèle séparé des autres, mais je ne le sais pas. cela vaut la peine d'essayer, car il risque de ne pas être bientôt conforme à nos grandes exigences.

La raison pour laquelle j’écris cette question ici, c’est que j’espère avoir une idée de la part de personnes ayant une solide expérience du travail avec d’énormes applications frontales. J'aimerais savoir s'il est possible de développer une telle application avec React, si React convient à une telle complexité et dynamique, si nous avons vraiment besoin de Redux ou de quelque chose d'autre, quelles trajectoires, quelles pratiques, quelles idéologies devrions-nous suivre. Si vous avez bien compris ma question, c'est plus le côté de l'architecture avec lequel nous luttons que celui de la technologie. Peut-être que nous ne faisons que suivre le chemin qui mène à de plus en plus de lutte et de complexité, mais pas vers la production.

flexicious.com · Answer

Il ne fait aucun doute que React/Redux peut (et est largement) utilisé pour développer le type d’applications que vous décrivez. Rien dans votre description ne rend ce que vous construisez si unique qu'il exclut React en tant que plate-forme pour le construire. Nous travaillons activement avec un client de grande entreprise qui construit tout son front-end - avec 100 + SPA (applications d'une seule page) dans React. C'est une équipe de plus de 100 développeurs sur un projet de 2-3 ans.

La façon dont nous avons structuré cela a été cruciale -

Tout d'abord, vous voulez choisir une bibliothèque de composants d'interface utilisateur. Quelques exemples ci-dessous:

En gros, nous en avons pris une et avons créé une bibliothèque de composants, car nos composants ont un style très personnalisé.

Deuxièmement, nous avons créé une architecture modulaire, où chaque module (SPA) est un package npm avec un composant conteneur principal et un magasin redux.

Enfin, nous avons un paquet de serveur central, où chacun des modules est enregistré. Le package de serveur est responsable de l'authentification, de l'autorisation, de la journalisation, du routage, etc.

L’essence de cette réponse n’est pas de donner des conseils sur la manière de structurer une application React volumineuse, mais de vous faire savoir que React peut être (et est utilisé) pour développer des applications similaires à ce que vous décrivez.

Jakob Lind · Answer

Commencer à écrire des applications plus complexes dans React peut vraiment être un combat, je sais exactement ce que ça fait!

Comme vous le dites, React est une librairie d’UI et non un cadre d’événement. C'est pourquoi vous avez généralement besoin d'une bibliothèque pour gérer les événements, par exemple Redux. Vous déclarez clairement que vous avez décidé de ne pas utiliser Redux (vous avez même utilisé des majuscules pour ne pas :)). Je prendrais un pas en arrière si j'étais vous et reconsidérons cette décision. Vous dites que la raison de ne pas utiliser Redux est que vous ne pouvez pas garder vos composants facilement enfichables et réutilisables avec Redux. Je dirais que ce n'est pas vrai. Redux est totalement découplé de vos composants React. Redux ne gère que la réception des événements et l’état de gestion. Du point de vue des composants de React, il ne fait que recevoir des données dans les accessoires et envoyer des événements en appelant des fonctions standard. Il est possible de faire des tests unitaires, de les réutiliser, etc.

Je suggérerais que vous preniez un autre regard sur Redux avec ceci en considération. Heureux de vous aider si vous avez d'autres questions!

Jared G · Answer

Vous avez résolu le problème dans votre question: réagissez est une bibliothèque de vues, pas un cadre d'application. La vraie question est de savoir si React + Redux (ou un autre système de gestion d'état) est approprié pour une grande application métier.

Je partagerai quelques informations tirées de l’expérience de notre équipe dans ce domaine. Les grandes applications métier ont été développées à l'aide des modèles de conception MVC/MVP/MVVM depuis des décennies. Ce sont des modèles éprouvés qui livrent des logiciels. Ajoutez à cela une injection de dépendance et vous obtenez une application modulaire, testable et maintenable. AngularJS (2.0+) est fondé sur ces principes et les exploite profondément. Pour cette raison, nous utilisons AngularJS pour l’ensemble de nos applications métiers.

React, d’autre part, offre un rendu léger, avec vue par sprint, qui convient parfaitement aux petites applications et aux pièces faisant face au client (par exemple, une enquête dynamique ou un tableau de bord simple). Nous nous tournons souvent vers React et VueJS car la pile complète d’AngularJS est excessivement lourde et trop lourde.

Marfu · Answer

Je suis dans la même situation en ce moment. J'ai de l'expérience dans les applications de bureau volumineuses (ERP, LOB - WinForms, WPF) - plus de 1 000 modules, très dynamiques (plus de 70% de l'interface utilisateur ont été générés par les données d'entrée/configuration), l'ajout de nouvelles fonctionnalités consistait simplement à étendre une configuration. (sans toucher au code source).

J'étudie en profondeur les technologies Web actuelles et je suis de plus en plus convaincu que React ne convient pas à cela. React brille vraiment dans les applications de taille petite/moyenne où vous (et les autres membres de l’équipe) développez chaque page/composant «manuellement» (non généré de manière dynamique) et que vous souhaitez avoir un état global. Mais cela ne vous aide pas à construire des applications à grande échelle prêtes à l'emploi - il ne s'agit que d'une bibliothèque d'interface utilisateur (donc, aucun support pour les modules, le routage, les formulaires, les liaisons, les requêtes http, le typage statique (TypeScript), etc.). surprise, il n'y a pas de support pour l'observation de style/encapsulation (vous devez intégrer, par exemple, les modules CSS, par vous-même). Et à la fin, vous devez constamment vous préoccuper de la gestion des versions des bibliothèques (les faire fonctionner ensemble demande vraiment beaucoup de temps et d’énergie).

J'ai une grande expérience avec Angular 2/4 + et je pense que, pour le moment, il s'agit de la {meilleure technologie pour ce type d'applications (si vous connaître WPF, c’est très similaire). C'est un cadre complet, qui est préparé à la mise à l'échelle. Vous pouvez diviser votre application en modules indépendants (en spécifiant les composants qui seront visibles par le monde extérieur), chaque composant ayant une api publique (type statique, entrées/sorties) et des styles CSS encapsulés (il n'y a pas d'interférence entre les autres). Pour l’état global (utilisateur connecté, configuration globale, etc.), vous pouvez toujours utiliser la bibliothèque ngrx/store (qui implémente le motif Redux et qui vient avec d’autres fonctions intéressantes, comme «effets», et s’intègre parfaitement dans Angular écosystème).

J'ai essayé de faire Angular des trucs vraiment fous (générer dynamiquement toute l'application à partir de la configuration du backend) et tout a fonctionné parfaitement, comme prévu.

Gopinath Kaliappan · Answer

Réagir, Redux facilitera les choses parce que quand il s'agit de applications complexes que vous pouvez créer objet de données bien structuré. vous pouvez ensuite gérer l’UI complète via React et ses Matériaux ... Il y a quelques raisons pour lesquelles c'est un bon choix

Gestion d'état,
Traitement des données de la structure arborescente,
Réduire le code,
Vous saurez où les modifications ont été apportées (Actions, Réducteurs)
Votre composant ne s'occupera que des choses de l'interface utilisateur

Ce que vous devez faire est Structurer vos données

Ivan Mjartan · Answer

Comprenez parfaitement vos sentiments lorsque vous commencez avec React et Redux. Nous étions dans la même situation lorsque nous avons démarré avec React dans notre entreprise. Au début, React a une approche différente de celle des autres cadres. Oui bien sûr, ce n'est pas un cadre, c'est juste une bibliothèque. Vous devez commencer à penser de manière React et c’est-à-dire: faire réagir les composants, il suffit de rendre l’état (c’est comme si vous rendiez une scène sur votre carte graphique, vous devez au préalable préparer la scène, puis vous pouvez effectuer le rendu); ou mieux appeler seulement des créateurs d'action.

Vous avez besoin d'un moyen intelligent pour stocker l'état dans ce point, je vous suggère d'utiliser Redux.

Nous utilisons également TypeScript avec la combinaison React, Redux. vous devez écrire plus de code que JS pur, mais le contrôle de type statique n'a pas de prix lorsque vous travaillez sur un projet volumineux.

Séparer la logique des composants est une approche native de la réaction ... vous devez séparer la logique écrire "Composants factices" puis la réutiliser avec connect. Ou en passant des valeurs comme des accessoires.

Nous utilisons le middleware Thunk en tant que créateurs d’action, c’est bien parce que le composant connecté n’appelle que la méthode et que la logique est dans les créateurs d’action. Vous y avez accès à tout l'état de l'application, puis vous pouvez aller chercher quelque chose et vous baser sur le résultat, vous pouvez envoyer différentes actions.

Ce que j'aime sur react/redux, c'est comment implémenter les appels asynchrones, etc. Premier composant de conception pour mapper tous les états

1) comme je n'ai pas de données 2) chargement des données 3) chargement terminé 4) erreur de chargement

Pour cela, vous n'avez besoin que d'un sémaphore et de quelques vérifications dans la méthode de rendu. Ensuite, un créateur d’action qui chargera les données et se basera sur l’action de répartition des progrès décrivant les progrès.

Ce qui est également cool, c'est que dans Rea/Redux app, vous avez un seul flux de données, c'est bien quand un nouveau développeur saute dans le projet.

Pour l’interface utilisateur, nous utilisons l’interface matérielle, ce cadre a certes quelques problèmes, mais rien de ce que vous ne pourrez pas traiter.

Nous utilisons également le routeur pour naviguer dans l'application.

Au début, j'éviterai le rendu côté serveur car cela facilitera beaucoup le démarrage avec le rendu côté client et l'état initial.

Quand nous commençons pour nous, était utile ce modèle où tout fonctionne dans un projet JavaScriptServices

Alors bien sûr super Abramov tutoriels.

Pour les composants de conception très utile Storybook

Nous pouvons écrire pourquoi utiliser ou ne pas réagir pendant longtemps ... mais ce que je peux dire ... pour nous, c'était un bon choix, avec quelques difficultés à mendier, mais nous avons maintenant un bon retour sur investissement.