Modèle d'architecture MVVM pour une application ReactJS
Je suis un développeur semi-senior react et JavaScript, j'ai fait plusieurs applications Universal react.
Aujourd'hui, notre CTO m'a dit: Utilisez-vous un modèle architectural logiciel pour votre application?
Je n'ai pas de réponse, il pointe l'équipe Android qui utilise MVVM pour ses applications.
Je cherche gourmand mais je n'ai pas trouvé de méthodologie de tendance ou d'exemple pour cette situation. J'ai utilisé Redux, Redux-Saga, React-Context et etc.
Je ne sais pas comment expliquer à notre CTO ou quelle est sa réponse?
Par conséquent: ne application react a-t-elle vraiment besoin d'un modèle architectural logiciel?
React lui-même n'est pas particulièrement avisé sur l'architecture logicielle. C'est une bibliothèque qui facilite le paradigme des composants réutilisables aux côtés de directives pour gérer des choses comme l'état et le partage de données (accessoires). À un moment donné, Facebook a décrit cela comme the V in MVC mais ont depuis abandonné ce marketing pour l'appeler de manière plus abstraite A JavaScript library for building user interfaces.
Bien sûr, les outils typiques associés aux applications React se prêtent à quelque chose d'une architecture lorsqu'ils sont utilisés ensemble.
Quelques façons potentielles d'y penser:
Simple React peuvent être simplement "VVM" ou "VC"
MVC est probablement le plus connu des deux dans le monde du développement. La principale différence conceptuelle entre un contrôleur (C) et un modèle de vue (VM) pourrait se résumer en: un contrôleur peut avoir de nombreuses responsabilités diverses, comme écouter les événements et les acheminer dans la bonne direction. C'est la colle qui facilite la fonctionnalité d'une application entière. Un modèle de vue , d'autre part, est simplement responsable de coller l'état actuel des données au modèle.
Ainsi, l'utilisation originale de Facebook de "V dans MVC" aurait probablement tout aussi bien pu être "V dans MVVM" - le terme contrôleur a plus de sens dans le monde du développement backend.
Une application nue React, sans Redux, qui extrait les données directement dans les composants (par exemple fetch dans componentDidMount ou exploitant GraphQL) avec une manipulation de données limitée de toute sorte pourrait être appelé un simple modèle "VVM".
View-Model (VM) : code lié aux composants qui gère l'état simple, transmet les données directement à View, peut potentiellement renvoyer les données directement à partir de View
Vue (V) : à quoi ressemblent les visuels (JSX, CSS)
Ajoutez de la complexité, et vous pourriez l'appeler "MVVM"/"MVC"
Si vous lancez dans Redux, redux-saga, ou même commencer à faire des choses folles avec un simple React état du composant, vous introduisez des opérations de modèle. Il y a au moins deux choses ce Model ( M) peut représenter:
- Logique métier réelle pour votre application
- Stockage et gestion de comportements complexes chez votre client
La logique métier est parfois indésirable dans la pratique: par exemple, si vous contrôlez le serveur, il peut être utile de conserver toute votre logique métier au même endroit (sur le serveur) et de simplement fournir à l'interface utilisateur ce dont elle a besoin pour interagir avec l'utilisateur. Mais si vous avez limité les points de terminaison REST et que vous devez faire quelques querelles (par exemple dans vos sagas ou au sein de composants), ce sera la logique métier.
La gestion du comportement du client est probable, en particulier dans les applications complexes où vous pouvez faire des choses comme afficher différentes choses à l'utilisateur en fonction de sa session (par exemple, il s'agit d'un utilisateur non enregistré vs utilisateur vs administrateur). Vous faites probablement cela dans toutes les interactions de magasin redux qui sont contenues pour être utilisées uniquement par le client.
Avertissement : discuter de MVC, MVVM, etc. est susceptible de conduire à de nombreuses opinions différentes sur exactement ce qu'elles signifient [ 1]. Ci-dessus, j'ai essayé de faire des parallèles entre les modèles courants que j'ai vus et comment ils s'intègrent dans MVC/MVVM, mais il y a tellement de façons différentes de l'aborder ou de façons plus granulaires d'y penser. Je ne serais pas trop accroché à y mettre une étiquette tant que votre système est facile à comprendre: modulaire, SEC, abstrait, etc. à des niveaux qui conviennent à votre cas d'utilisation et à votre échelle de développement.
[1] Discuté plus longuement dans réponses et commentaires à cette question