大多数情况下,两个应用程序的逻辑和用户界面非常相似.
除了一些差异：
>移动设备的屏幕尺寸优化(例如,移动设备中隐藏的侧面菜
>移动中的触摸手势(3DTouch)与桌面中的悬停功能
>触摸移动设备中某些元素的反馈
>移动中的页面导航与桌面中的路由导航
我想过将angular-material组件用于桌面,将Ionic组件和移动导航用于两者都建立在角度之上.
当然,我的目标是尽可能多地共享代码,逻辑以及UI容器组件.
因此,我尝试在为桌面UI,移动UI,共享UI和逻辑创建单独的Angular模块时考虑构建项目的好方法：
一种选择是为两个应用程序提供一个核心模块,导入逻辑和共享UI模块.然后在为每个平台构建时在特定平台UI模块之间切换.在此选项中,特定于平台的UI组件将具有相同的选择器和@Inputs,但在其呈现的UI中会有所不同.
第二个选项是为每个将导入逻辑模块和共享UI组件模块的平台应用程序提供单独的核心模块.
也许有人有这样做的经验,可以分享他对涵盖所有这些的最佳项目结构的看法？
或者我建议哪个项目结构更好？
解决方法
>使用单独的文件结构创建2个单独的“前端”项目
在单独的目录中,使用特定的“命令行工具”
框架(Angular CLI,Ionic CLI,NativeScript CLI).
>创建一个包含要共享的公共模块的公共项目
通过’前端’项目
>从代码库导入共享模块到’前端
结束’项目(例如在名为’shared’的目录下) – 确保
您将前端项目与相同的通用版本保持一致
‘共享’项目
真正的技巧是设置“共享”模块的边界,以便在不增加代码复杂性的情况下最大化重用(例如,通过在’共享’代码中检查环境 – 我避免使用环境变量来定义是否代码以Ionic或Angular运行,并根据该变量做出决定.
对我来说,经验法则是“前端”项目定义所有组件(即组件不共享).
组件具有非常浅的逻辑,通常类似于以下内容
>他们在构造函数中定义他们使用的服务
>在ngOnInit()方法中,他们订阅了Observables
服务方法返回的兴趣 – 订阅逻辑
填充包含视图中显示的数据的变量
>在ngOnDestroy()中,他们取消订阅订阅
>组件定义管理前端事件的方法 – 例如
方法通常在共享服务上调用方法
编码时会出现正确的设计.我的意思是,一旦你建立了基本结构(即’前端’项目和’共享’项目),你开始编码一个前端(例如浏览器的Angular).一些决策很容易采取(例如,查询后端的所有逻辑通常都是共享的).其他一些决定更棘手,而且越接近前端表面的逻辑越真实.一旦你看到组件中的逻辑变得越来越厚,那么你就开始想知道是否有值得分享的东西,因为对于另一个’前端’也许是常见的(让我们说Ionic).如果是这种情况,那么您重构,将代码移动到“共享”服务.
还要记住通过测试充分保护“共享”服务.
我希望它有所帮助
