Eine Reihe von Single-Page-Anwendungen muss mit verschiedenen Partnern verbunden werden, daher muss die Benutzeroberfläche angepasst werden und manchmal müssen einige Interaktionen geändert werden, aber der gesamte Prozess ist im Grunde der gleiche.
Derzeit planen wir, das Projekt mit Vue zu rekonstruieren, und haben die öffentliche Geschäftslogik in die Geschäftsschicht unterteilt. Beim Schreiben von Komponenten auf Seitenebene haben wir jedoch festgestellt, dass es immer noch die meisten wiederverwendbaren Codes gibt, beispielsweise auf der Anmeldeseite:
// viewModel
｛
phoneNum, smsCode, loginbtn
}Es gibt grundsätzlich eine Reihe von Ansichtsmodellen, um diesen Geschäftsprozess zu beschreiben. Ich denke, dieser Teil des wiederholten Codes ist wiederverwendbar.
Bei jeder neuen Version handelt es sich bei den meisten Änderungen um Stile und eine kleine Menge an Interaktionen (es gibt auch viele Interaktionen, aber der spezifische Geschäftslogikprozess bleibt unverändert).
1.分割viewmodel到各子组件，构建该页面时，引用这些业务组件拼凑，添加／修改样式；
2.子组件间事件通信或动态注册data。
3.交互变更大，新增某个子组件。Im Allgemeinen sollten jedoch zuerst UI-Komponenten und dann Business-Komponenten vorhanden sein. Der Entwurf sieht hier vor, dass zuerst Business-Komponenten und dann UI-Komponenten vorhanden sind.
1.先编写ui组件
2.再编写viewmodel对应的流程逻辑
3.引用ui组件，mixin对应逻辑
Die Idee ist sehr chaotisch, bitte geben Sie mir ein paar Meinungen, danke.
首先，请区分【组件】和模块的概念。组件仅仅用于表达 UI 交互，不应包含前后端请求等业务逻辑。
具体到问题，Sass 化的站点开发经常需要处理这类【功能可配置】的需求，常见流程：
后端开放【功能配置】接口，前端在页面加载时获取【当前页面配置参数】信息
前端封装各业务逻辑为独立的 JS 模块，通过 export 模块的功能，将业务功能提供给 Vue 的 UI 层使用。
前端 UI 层根据功能配置，调用不同的模块功能。
简单说，开发模式和 Vue 单页应用是一致的，追加根据功能配置定义 UI 逻辑的 JS 模块，做好封装即可。
至于主题动态切换的功能，同样可用配置接口实现。例如，配置接口中存储 style 字段标识当前业务方主题的 className 前缀，然后通过
:class指令绑定该样式前缀至当前页面上，配合相应的 css 即可轻松实现主题切换。P.S. 不要在项目开始阶段使用 mixin。mixin 会使得业务逻辑难以查找与调试（混入 mixin 后可以引用不知从何位置导入的函数和变量）。按需导入业务模块才是正确做法。
分离 ui 与 功能组件（例如：网络请求，本地存储），实现功能组件基本上可以自由搭配组合；
ui 组件抽取拆分，具体粒度到多小，主要看题主项目之间差异有多大，还有迭代发布速度要求；现实中并不是可复用程度越高越好，层级越多，执行效率越低，出错机会越大，调试难度越高；需要取得一个平衡点。