意见建议收集区
mcuking opened this issue · 18 comments
该 issue 专门用于收集大家对该项目的意见和建议，欢迎大家积极留言建议。
一个人的能力和精力是有限的，众人拾材火焰高，希望一起把这个项目做成 h5 写移动应用的最佳模板🤠
（如果是反馈 bug，还请另外开 issue）
关于 数据持久化 跟 全局的状态管理，是怎么设计的呢。有一个场景，不依赖indexedDB，作为数据来源。请求后端数据后生成一个总的表单对象，编辑新增删除，都是对这个对象操作。除了vuex在这个项目中能有什么思路吗
或者说 vuex 跟 实体，怎么更好的结合，各自的分工是什么，我有点模糊
不是很清楚您的意思，不过我说下我们公司里实际项目的应用情况吧：
首先目前新的项目都会单独分出来一个 npm 包命名为 core，用来抽离业务逻辑，分层和这个项目大致是一样的，不过因为逻辑并没有太复杂，所以没有单独的实体层。
然后 mobile 和 pc 的项目共用 core 包提供的，通过 lerna 去管理 mobile 和 pc 项目（当然也可以分开进行独立开发），结构大致如下
至于 vuex 也有应用，主要是管理一些需要放在全局的状态，例如 userInfo, cacheComponents（keepalive 生效的组件名数组，可以动态控制页面是否需要缓存）等等，所有的子应用共用这些全局状态，并没有放过多的业务逻辑。也就是说，vuex 和这种业务分层架构没有混用
不知道有没有解决你的困惑，有什么好想法也可以继续留言讨论～
能不能全面介绍下 core 这个目录下
@push-over
core 就是所有的非视图层，包括了 Services、 Interactors、Entities（如果有实体的话）三个层，下面是详细的介绍：
https://github.com/mcuking/mobile-web-best-practice#%E5%88%86%E5%B1%82%E6%9E%B6%E6%9E%84
或者说 vuex 跟 实体，怎么更好的结合，各自的分工是什么，我有点模糊
你说的是一个数据持久化的问题，这块在 redux 里面有 redux-presist 这个库提供支撑。vue 的技术栈我不太熟，想必有类似的库，可以很容易的实现你的需求
总体来说原理其实比较简单，通过监听 store 中数据发生改变，来动态存储数据到本地存储。过去我们使用 Object.definePropoties 不过现在使用 Proxy API 可以很容易的实现这一点。
其实整个过程和 vue 的双向数据绑定类似。
另外你可能觉得每次数据改变都重新 reset 整个 store 对性能会造成浪费，这里可以研究一下数据结构中的 Immutable，在数据变化的时候仅更新 store tree 中的最小变化单元来避免极大数据量情况下的性能损耗，当然这个属于比较高阶的用法了
离线包的差分是针对上一版本的，如果用户缓存的当前版本是上上个或者更久的版本，那应该怎么处理？
离线包的差分是针对上一版本的，如果用户缓存的当前版本是上上个或者更久的版本，那应该怎么处理？
你可以在上传离线包到管理后台的时候，将版本向前3个版本做差分，比如上传版本 5，则和 2, 3, 4 版本做差分。
客户端缓存版本和线上版本之差超过 3 的时候，就直接下载版本 5 的全量包
离线包的差分是针对上一版本的，如果用户缓存的当前版本是上上个或者更久的版本，那应该怎么处理？
你可以在上传离线包到管理后台的时候，将版本向前3个版本做差分，比如上传版本 5，则和 2, 3, 4 版本做差分。
客户端缓存版本和线上版本之差超过 3 的时候，就直接下载版本 5 的全量包
感谢指教。还有个问题，是不是离线包上传的时候，全量包和差分包都要上传？
离线包的差分是针对上一版本的，如果用户缓存的当前版本是上上个或者更久的版本，那应该怎么处理？
你可以在上传离线包到管理后台的时候，将版本向前3个版本做差分，比如上传版本 5，则和 2, 3, 4 版本做差分。
客户端缓存版本和线上版本之差超过 3 的时候，就直接下载版本 5 的全量包感谢指教。还有个问题，是不是离线包上传的时候，全量包和差分包都要上传？
不需要，只需要上传全量包就好，生成差分包功能是在离线包管理平台这个服务实现的
想问一下博主大佬，到了现在的话，这个最佳实践是否还有参考价值，有没有一些方案已经被更好的方案替代呢。
想问一下博主大佬，到了现在的话，这个最佳实践是否还有参考价值，有没有一些方案已经被更好的方案替代呢。
随着时间推移，其中有一些方案可能会有更好的替代品，所以这个问题不是很好回答你是还是不是，需要你自己去判断和比较。不过里面的一些想法还是会有一定的价值的～
感谢大佬，看你的源码还是学到了很多。
欢迎交流, 大家一起摸索前进!
以下是我个人的一些观点和建议
-
IOC,DI做全局的注入, 在程序入口做, 做在domain里会导致抽象和实现绑定了, 没有达到IOC的意图, 即推迟决定实现
-
entity这个单位很小, 建议你改换model. AggregateRoot可由1..n个entity组成.
-
到了model这一层已经是最底层了, 实体不必要在使用接口了, 没有控制反转的需求了
-
service和repo最好也分开, service如果是领域服务那其实现也在domain中(一般就一个实现,不需要接口, 多实现是策略的时候), 但是repo的实现是在infrastructure层的, 如果service是防腐用实现可以在infrastructure层.
-
前端场景控件逻辑要内聚, 组件内操作控件模型和视图模型以及应用服务组成组件的业务逻辑, 视图负责渲染即可.
@mcuking 一步你好，我看了“样式适配”一节，里面提到 vw 方案无法限制最大宽度，刚好我最近写了个屏幕适配插件，postcss-mobile-forever，可以利用 vw 限制最大宽度，而不使用 JS，请问能否在“样式适配”这一节采纳我这个插件。
如果有需要的话我也可以提一下适配插件之后的 PR，我看到这个项目里用的 vue-cli 内置的是 PostCSS 7 的版本，是否考虑升级 vue-cli 从而内置 PostCSS 8，我目前在持续维护 PostCSS 8 的 mobile-forever，虽然我也开发了基于 PostCSS 6 的 mobile-forever，但旧版本维护有点麻烦。
点击查看插件适配后，桌面端屏幕的展示效果。
 |
 |
 |
 |