今天我们来看一看慕课乐高的架构设计。
首先看一下需要多少个项目。
需要几个项目?
!
b端和编辑器,前后端分离:
- biz-editor-fe
- biz-editor-server
h5适合做SSR,性能考虑:
- H5-server
管理后台,前端分析:
- admin-fe
- admin-server
独立的业务组件库:
- npm 包
统计服务:
- openAPI
编辑器和h5页面组件应该是一致的,可以复用的,所以应该是形成一个组件库。
为了迭代优化产品,我们还需要统计服务完成完整的闭环。
好了,现在项目就是这些,我们来具体看看编辑页面需要写什么?
编辑页面的数据结构是什么?
这个编辑的页面,需要解决三个问题:
点击保存的时候数据结构是什么样的?
答:使用vnode作为数据结构,因为共识比较好,也经历过考验。
如何保证画布和属性是同步的?
答:使用vuex做数据的同步,具体如下。
{
// 作品
work: {
title: '作品标题',
setting: { /* 一些可能的配置项,用不到就先预留 */ },
props: { /* 页面 body 的一些设置,如背景色 */ },
components: [
// components 要用数组,有序结构
// 单个 node 要符合常见的 vnode 格式
{
id: 'xxx', // 每个组件都有 id ,不重复
name: '文本1',
tag: 'text',
attrs: { fontSize: '20px' },
children: [
'文本1' // 文本内容,有时候放在 children ,有时候放在 attrs 或者 props ,没有标准,看实际情况来确定
]
},
{
id: 'yyy',
name: '图片1',
tag: 'image',
attrs: { src: 'xxx.png', width: '100px' },
children: null
},
]
},
// 画布当前选中的组件
activeComponentId: 'xxx'
}
如果扩展图层面板,如何设计?
答:图层应该是computed计算出来的索引,而不是单独数据
{
layers() => {
store.work.components.map(c => {
return {
id: c.id,
name: c.name
}
})
}
}
数据流转
核心:B端、C端、管理后台,公用一个数据库。
- 创建作品:初始化一个JSON数据
- 保存作品:修改JSON数据
- 发布作品:修改一个标记
- C端浏览作品:获取JSON数据,SSR渲染
- 屏蔽作品:修改标记,C端判断