weixin_33872660
weixin_33872660

有赞美业店铺装修前端解决方案

一、背景介绍

做过电商项目的同学都知道，店铺装修是电商系统必备的一个功能，在某些场景下，可能是广告页制作、活动页制作、微页面制作，但基本功能都是类似的。所谓店铺装修，就是用户可以在 PC 端进行移动页面的制作，只需要通过简单的拖拽就可以实现页面的编辑，属于用户高度自定义的功能。最终编辑的结果，可以在 H5、小程序进行展示推广。

有赞美业是一套美业行业的 SaaS 系统，为美业行业提供信息化和互联网化解决方案。有赞美业本身提供了店铺装修的功能，方便用户自定义网店展示内容，下面是有赞美业店铺装修功能的截图：

上面的图片是 PC 端的界面，下面两张图分别是 H5 和小程序的最终展示效果。可以简单地看到，PC 端主要做页面的编辑和预览功能，包括了丰富的业务组件和详细的自定义选项；H5 和小程序则承载了最终的展示功能。

再看看有赞美业当前的技术基本面：目前我们的 PC 端是基于 React 的技术栈，H5 端是基于 Vue 的技术栈，小程序是微信原生开发模式。

在这个基础上，如果要做技术设计，我们可以从以下几个角度考虑：

  • 三端的视图层都是数据驱动类型，如何管理各端的数据流程？

  • 三个端三种不同技术栈，业务中却存在相同的内容，是否存在代码复用的可能？

  • PC 最终生成的数据，需要与 H5、小程序共享，三端共用一套数据，应该通过什么形式来做三端数据的规范管理？

  • 在扩展性上，怎么低成本地支持后续更多组件的业务加入？

二、方案设计

所以我们针对有赞美业的技术基本面，设计了一个方案来解决以上几个问题。

首先摆出一张架构图：

2.1 数据驱动

首先关注 CustomPage 组件，这是整个店铺装修的总控制台，内部维护三个主要组件 PageLeft、 PageView 和 PageRight，分别对应上面提到的 PC 端3个模块。

为了使数据共享，CustomPage 通过 React context 维护了一个”作用域“，提供了内部三个组件共享的“数据源”。 PageLeft 、 PageRight 分别是左侧组件和右侧编辑组件，共享 context.page 数据，数据变更则通过 context.pageChange 传递。整个过程大致用代码表示如下：

// CustomerPage
class CustomerPage extends React.Component {
    static childContextTypes = {
        page: PropTypes.object.isRequired,
        pageChange: PropTypes.func.isRequired,
        activeIndex: PropTypes.number.isRequired,
    };

    getChildContext() {
        const { pageInfo, pageLayout } = this.state;
        return {
            page: { pageInfo, pageLayout },
            pageChange: this.pageChange || (() => void 0),
            activeIndex: pageLayout.findIndex(block => block.active),
        };
    }
    
    render() {
    	return (
    		

				
            	
            	
    		

    	);
    }
}

// PageLeft
class PageLeft extends Component {
    static contextTypes = {
        page: PropTypes.object.isRequired,
        pageChange: PropTypes.func.isRequired,
        activeIndex: PropTypes.number.isRequired,
    };
    
    render() {...}
}


// PageRight
class PageRight extends Component {
    static contextTypes = {
        page: PropTypes.object.isRequired,
        pageChange: PropTypes.func.isRequired,
        activeIndex: PropTypes.number.isRequired,
    };
    
    render() {...}
}
复制代码

至于 H5 端，可以利用 Vue 的动态组件完成业务组件的动态化，这种异步组件的方式提供了极大的灵活性，非常适合店铺装修的场景。

"item in components">
	"item.component" :options="convertOptions(item.options)" :isEdit="true">
	


复制代码

小程序因为没有动态组件的概念，所以只能通过 if else 的面条代码来实现这个功能。更深入的考虑复用的话，目前社区有开源的工具实现 Vue 和小程序之间的转换，可能可以帮助我们做的更多，但这里就不展开讨论了。

PC 编辑生成数据，最终会与 H5、小程序共享，所以协商好数据格式和字段含义很重要。为了解决这个问题，我们抽取了一个npm包，专门管理3端数据统一的问题。这个包描述了每个组件的字段格式和含义，各端在实现中，只需要根据字段描述进行对应的样式开发就可以了，这样也就解决了我们说的扩展性的问题。后续如果需要增加新的业务组件，只需要协商好并升级新的npm包，就能做到3端的数据统一。

/**
 * 显示位置
 */
export const position = {
    LEFT: 0,
    CENTER: 1,
    RIGHT: 2,
};

export const positionMap = [{
    value: position.LEFT,
    name: '居左',
}, {
    value: position.CENTER,
    name: '居中',
}, {
    value: position.RIGHT,
    name: '居右',
}];
复制代码

2.2 跨端复用

PageView 是预览组件，是这个设计的核心。按照最直接的思路，我们可能会用 React 把所有业务组件都实现一遍，然后把数据排列展示的逻辑实现一遍；再在 H5 和小程序把所有组件实现一遍，数据排列展示的逻辑也实现一遍。但是考虑到代码复用性，我们是不是可以做一些“偷懒”？

如果不考虑小程序的话，我们知道 PC 和 H5 都是基于 dom 的样式实现，逻辑也都是 js 代码，两端都实现一遍的话肯定做了很多重复的工作。所以为了达到样式和逻辑复用的能力，我们想了一个方法，就是通过 iframe 嵌套 H5 的页面，通过 postmessage 来做数据交互，这样就实现了用 H5 来充当预览组件，那么 PC 和 H5 的代码就只有一套了。按照这个实现思路，PageView 组件可以实现成下面这样：

class PageView extends Component {
	render() {
        const { page = {} } = this.props;
        const { pageInfo = {}, pageLayout = [] } = page;
        const { loading } = this.state;
	
       return (