javascript - Le processus métier de l'application Web est fondamentalement le même, plusieurs ensembles de thèmes (les styles sont fondamentalement différents et les interactions sont légèrement différentes) sont gérés et de nouveaux thèmes apparaissent constamment. Comment concevoir une architecture composée de composants ?

Question

Scénario commercial

Un ensemble d'applications d'une seule page doit être connecté à différents partenaires, l'interface utilisateur doit donc être ajustée et parfois certaines interactions doivent être modifiées, mais l'ensemble du processus est fondamentalement le même.

Actuellement, nous prévoyons d'utiliser Vue pour reconstruire le projet et avons séparé la logique métier publique en couche métier. Cependant, lors de l'écriture des composants au niveau de la page, nous avons constaté qu'il existe encore la plupart des codes réutilisables, comme sur la page de connexion :

 // viewModel
｛ 
    phoneNum, smsCode, loginbtn
 }

Il existe dans chaque version. Fondamentalement, un ensemble de modèles de vue peut être utilisé pour décrire ce processus métier. Je pense que cette partie du code répété est réutilisable.

Pour chaque nouvelle version, la plupart des changements concernent les styles et une petite quantité d'interactions (il existe également de nombreuses interactions, mais le processus de logique métier spécifique reste inchangé).

J'ai déjà pensé :

Option 1 :

1.分割viewmodel到各子组件，构建该页面时，引用这些业务组件拼凑，添加／修改样式；
2.子组件间事件通信或动态注册data。
3.交互变更大，新增某个子组件。

Cependant, il devrait généralement y avoir d'abord des composants d'interface utilisateur, puis des composants métier. La conception ici est d'avoir d'abord des composants métier, puis des composants d'interface utilisateur.

Option 2 :

1.先编写ui组件
2.再编写viewmodel对应的流程逻辑
3.引用ui组件，mixin对应逻辑

L'idée est très brouillonne, merci de me donner quelques avis, merci.

Answer 1

Tout d'abord, veuillez distinguer les notions de [composant] et de module. Les composants sont uniquement utilisés pour exprimer les interactions de l'interface utilisateur et ne doivent pas contenir de logique métier telle que des requêtes frontales et back-end.

Plus précisément, le développement de sites basés sur Sass doit souvent répondre à de telles exigences [fonction configurable] Processus courants :

.

1. Le backend ouvre l'interface [Configuration des fonctions] et le frontend obtient les informations [Paramètres de configuration de la page actuelle] lorsque la page est chargée

2. Le front-end encapsule chaque logique métier dans des modules JS indépendants et fournit des fonctions métier à la couche UI de Vue via la fonction du module d'exportation.

3. La couche d'interface utilisateur frontale appelle différentes fonctions du module en fonction de la configuration fonctionnelle.

Pour faire simple, le modèle de développement est cohérent avec l'application Vue monopage. Ajoutez simplement un module JS qui définit la logique de l'interface utilisateur en fonction de la configuration fonctionnelle et l'encapsule.

Quant à la fonction de changement de thème dynamique, elle peut également être implémentée via l'interface de configuration. Par exemple, le champ de style dans l'interface de configuration stocke le préfixe className qui identifie le thème de la partie commerciale actuelle, puis lie le préfixe de style à la page actuelle via la directive :class, et le changement de thème peut être facilement implémenté avec le CSS correspondant.

P.S. N'utilisez pas de mixins au début du projet. Les mixins peuvent rendre la logique métier difficile à trouver et à déboguer (après avoir mélangé les mixins, les fonctions et les variables importées depuis des emplacements inconnus peuvent être référencées). La bonne approche consiste à importer des modules métier à la demande.

Answer 2

1. Composants d'interface utilisateur et fonctionnels séparés (tels que les requêtes réseau, le stockage local), et les composants fonctionnels peuvent être librement combinés ;

Extraction et fractionnement des composants de l'interface utilisateur, la granularité spécifique dépend de l'ampleur de la différence entre les projets concernés et des exigences de vitesse de publication itérative, en réalité, ce n'est pas que plus le degré de réutilisabilité est élevé, mieux c'est, plus il y a de niveaux ; , l'exécution Plus l'efficacité est faible, plus le risque d'erreur est grand et plus la difficulté de débogage est élevée ;