位什么我的facebook名字.多语言姓名.别名都不能改或填

每次打完他都说 你的姓名变更要求已被自动核准系统拒绝了。

更多： 还有我想再名字旁边有一个括号的名字也不能

公司目前制作一个H5活动，特别是有一定统一结构的活动，都要码一个重复的轮子。后来接到一个基于模板的活动设计系统的需求，便有了下面的内容。借油开车。

需求一到，接就是怎么实现，技术选型自然成为了第一个问题。鉴于目前web前端mvvm框架以及组件化开发方式的流行，决定技术栈采用：vue + es6 + 组件化。

这里首先简单说下web前端组件化开发方式的历程：

最早的组件化结构，代码结构可能如下：

然后向它传入一个普通字符串：

根据vue响应的特性，props也可以是动态的：

类似于用 v-bind 绑定 HTML 特性到一个表达式，也可以用  v-bind  绑定动态 Props 到父组件的数据。每当父组件的数据变化时，也会传导给子组件：

也可以使用v-bind的缩写语法来简化绑定：

改变输入框的值，子组件的文本会跟着改变

关于props的其他介绍，请参考 ：props

尽管可以访问父链上任意的实例，不过子组件应当避免直接依赖父组件的数据，尽量显式地使用 props 传递数据。另外，在子组件中修改父组件的状态是非常糟糕的做法，因为：

这让父组件与子组件紧密地耦合；

只看父组件，很难理解父组件的状态。因为它可能被任意子组件修改！情况下，只有组件自己能修改它的状态。

Vue 实例实现了一个自定义事件接口，用于在组件树中通信。这个事件系立于原生 DOM 事件，用法也不同。

每个 Vue 实例都是一个事件触发器：

不同于 DOM 事件，Vue 事件在冒泡过程中第一次触发回调之后自动停止冒泡，除非回调明确返回  true 。

在子组件的输入框输入值以后，点击按钮，父组件的Messages:[]文本会对应变化

多个组件可以使用同一个挂载点，然后动态地在它们之间切换。使用保留的  <component> 元素，动态地绑定到它的 is 特性：

如果把切换出去的组件保留在内存中，可以保留它的状态或避免重新渲染。为此可以添加一个  keep-alive  指令参数：

在创建复杂应用的时候，动态组件或许就显得不那么灵活了，这时可以使用路由，vue-router路由扩展可以看做是动态组件的升级版，可参考：vue-router

5.最后，组件实例的生命周期：

Vue 实例在创建时有一系列初始化步骤——例如，它需要建立数据观察，编译模板，创建必要的数据绑定。在此过程中，它也将调用一些生命周期钩子，给自定义逻辑提供运行机会。例如 created 钩子在实例创建后调用：

 也有一些其它的钩子，在实例生命周期的不同阶段调用，如 compiled、 ready 、destroyed。钩子的 this 指向调用它的 Vue 实例。一些用户可能会问 Vue.js 是否有“控制器”的概念？答案是，没有。组件的自定义逻辑可以分割在这些钩子中。

组件的简单介绍就到这里。

在大型应用中，状态管理常常变得复杂，因为状态分散在许多组件内，在不同的作用域内。以vue来说，当使用vue-router以及组件化开发(.vue)来构建大型单页应用的时候，组件之间状态的数据的传递会很困难，虽然props、dispatch、broadcast等能够进行跨组件的数据传递，但是大量使用它们会使组件之间的耦合程度很高，组件越多，层级越多，维护起来就越复杂。怎么办呢？能否在全局提供一个状态管理构架？

这里得提出一个概念：Flux

Flux是Facebook用来构建用户端的web应用的应用程序体系架构。它通过利用数据的单向流动为React的可复用的视图组件提供了补充。相比于形式化的框架它更像是一个架构思想，不需要太多新的代码你就可以马上使用Flux构建你的应用。

creators - dispatcher辅助方法 - 一个被用来提供描述应用所有可能存在的改变的语义化的API。把它理解为Flux更新闭环的第四个组成部分可以帮助你更好的理解它。

一句话：Flux就是手动将Action从数据流底层视图中的事件手动绑定到数据顶层的数据流架构。

单向数据流的设计目的：任何UI不能直接对数据有写操作，就是防止同一份数据有多个地方同时在写。相对于直接进行双向绑定，编码稍微会复杂一点，但换来了排错和维护的便捷。

Flux 架构常用于 React 应用中，但它的核心理念也可以适用于 Vue.js 应用。比如 Vuex 就是一个借鉴于 Flux，但是专门为 Vue.js 所设计的状态管理方案。React 生态圈中最流行的 Flux 实现 Redux 也可以通过简单的绑定和 Vue 一起使用。

Vuex 是一个专门为 Vue.js 应用所设计的集中式状态管理架构。它借鉴了 Flux 和 Redux 的设计思想，但简化了概念，并且采用了一种为能更好发挥 Vue.js 数据响应机制而专门设计的实现。

当你的应用还很简单的时候，你多半并不需要 Vuex。也不建议过早地使用 Vuex。但如果你正在构建一个中型以上规模的 SPA，你很有可能已经需要思考应该如何更好地归纳 Vue 之外，应用的其他组成部分。这就是 Vuex 要大显身手的时刻。

我们在单独使用 Vue.js 的时候，通常会把状态储存在组件的内部。也就是说，每一个组件都拥有当前应用状态的一部分，整个应用的状态是分散在各个角落的。然而我们经常会需要把状态的一部分共享给多个组件。一个常见的解决策略为：使用定制的事件系统，让一个组件把一些状态“发送”到其他组件中。这种模式的问题在于，大型组件树中的事件流会很快变得非常繁杂，并且调试时很难去找出究竟哪错了。

为了更好的解决在大型应用中状态的共用问题，我们需要对组件的 组件本地状态(component local state) 和 应用层级状态(application level state) 进行区分。应用级的状态不属于任何特定的组件，但每一个组件仍然可以监视(Observe)其变化从而响应式地更新 DOM。通过汇总应用的状态管理于一处，我们就不必到处传递事件。因为任何牵扯到一个以上组件的逻辑，都应该写在这里。此外，这样做也能让我们更容易地记录并观察状态的变更（Mutation，原意为突变），甚至可以实现出华丽如时光旅行一般的调试效果。（译注：是时候安利一波 vue-devtools 了）

Vuex 也对如何管理分撒各地的状态增加了一些约束，但仍保留有足够面对真实使用的灵活性。

如果你倾向于对象风格的分发方式，你可以用这种语法：

再次强调，我们通过分发 mutation 的方式，而非直接改变  store.state ，是因为我们想要更明确地追踪到状态的变化。这个简单的约定能够让你的意图更加明显，这样你在阅读代码的时候能更容易地解读应用内部的状态改变。此外，这样也让我们有机会去实现一些能记录每次状态改变，保存状态快照的调试工具。有了它，我们甚至可以实现如时间穿梭般的调试体验。

Vuex 使用 单一状态树 —— 是的，用一个对象就包含了全部的应用层级状态。至此它便作为一个『唯一数据源(SSOT)』而存在。这也意味着，每个应用将仅仅包含一个 store 实例。单状态树让我们能够直接地定位任一特定的状态片段，在调试的过程中也能轻易地取得整个当前应用状态的快照。

以上只是一个用来展示 store 究竟是什么的一个极简例子。再谈谈三哥核心概念：State（状态），Mutations（变更） 和 Actions（动作）。

通过在根实例中注册 store 选项，该 store 实例会注入到根组件下的所有子组件中，且子组件能通过  this.$store  访问到。不过事实上，我们几乎不会需要直接引用它。

 请留意 vuex 的这个特殊选项（译注：getters 子对象）。它是我们指定当前组件能从 store 里获取哪些状态信息的地方。它的每个属性名将对应一个 getter 函数。该函数仅接收 store 的整个状态树作为其唯一参数，之后既可以返回状态树的一部分，也可以返回从状态树中求取的计算值。而返回结果，则会依据这个 getter 的属性名添加到组件上，用法与组件自身的计算属性一毛一样。

组件不能直接修改store实例的状态：

请始终记得非常重要的这点，就是：组件永远都不应该直接改变 Vuex store 的状态。因为我们想要让状态的每次改变都很明确且可追踪，Vuex 状态的所有改变都必须在 store 的 mutation handler (变更句柄) 中管理。为了强化该规则，在开启(严格模式(Strict Mode))时，若有 store 的状态在 mutation 句柄外被修改，Vuex 就会报错。现在有了这一规则，我们 Vue 组件的职能就少了很多：他们通过只读的 getter 与 Vuex store 的状态相绑定，组件唯一能影响全局状态的方法就是想办法触发 mutations（我们接下来会谈到）。若有必要，组件仍然能够处理和操作本地状态，但是我们不再在单独的组件中放置任何数据请求或全局状态变更的逻辑。这些操作全部都集中于 Vuex 相关的文件中，这样能让大型应用变得更容易理解和维护。

用全部大写命名 mutation 是一个惯例，方便将它和 actions 区分开。

因为当 mutation 触发的时候，回掉函数还没有被调用，我们不知道什么时候回调函数实际上被调用。任何在回调函数中进行的的状态的改变都是不可追踪的。

Mutation必须遵守Vue的响应系统规则：

1.尽可能在创建 store 时就初始化 state 所需要的所有属性。

乍一眼看上去感觉多此一举，我们直接分发 mutations 岂不更方便？实际上并非如此，还记得 mutations 必须同步执行这个限制么？Actions 就不受约束！我们可以在 action 内部执行异步操作，比如执行一个ajax请求数据的操作：

我们可以这样在组件中调用actions：

通常在大型 App 中，action 应该按不同目的进行 分组 / 模块化 的管理，具体请参考： Actions

下面再谈谈一个重要的东西，数据流：

为了更好地理解 Vuex app 中的数据流，我们来开发一个简单的计数器 app。注意：这个例子仅仅是为了更好地解释概念，在实际情况中并不需要在这种简单的使用 Vuex.

// 仅需要在根组件中注入 store 实例一次即可

你会注意到组件本身非常简单：它所做的仅仅是绑定到 state、然后在用户输入时调用 actions。

你也会发现整个应用的数据流是单向的，正如 Flux 最初所定义的那样：

1.用户在组件中的输入操作触发 action 调用。

3.Store 实例的状态变化反过来又通过 getters 被组件获知。

最后：Vuex 并不强制要求所有的状态都必须放在 Vuex store 中 ，如果有些状态你觉得并没有需要对其变化进行追踪，那么你完全可以把它放在 Vuex 外面(比如作为组件的本地状态)。比如公共组件对外的接口，通过props传递数据更为有效。

Vuex的完整介绍请参考：Vuex

可以看到组件的prop属性、计算属性、vue getter属性等，以及Vuex中的触发的mutation、state 当前的值等我们可能关注的内容都直观地展示了出来。

对于大型项目，为了更好地管理代码使用模块构建系统非常必要。推荐代码使用 CommonJS 或 ES6 模块，然后使用 Webpack 或 Browserify 打包。

Webpack 和 Browserify 不只是模块打包器。两者都提供了源码转换 API，通过它可以用其它预处理器转换源码。例如，借助 babel-loader 或 babelify 代码可以使用 ES 语法。

选择哪种构建工具取决于你的和需求。Webpack 的功能更强大，如代码分割，将静态资源当作模块，提取组件的 CSS 到单独的一个文件等，不过它的配置相对复杂一点。如果你不需要 Webpack 的那些功能，使用 Browserify 更简单，最快的构建方式是使用官方出品的脚手架工具 vue-cli。参考：vue-cli

 活动模板设计系统

这个设计系统只是对活动模板要展示的内容进行设计，具体的样式和交互由活动h5页面根据视觉和交互设计来定夺。活动里面的每一个子项都可以抽象为一个组件，h5展示端拿到每个组件的内容再套上对应组件的样式和交互逻辑，最终就形成了一个h5活动页面。

每一个活动组件对应三个模式组件：

1.标签组件，通过拖动来创建对应类型的组件

2.预览组件，展示当前组件各项的内容

 3.编辑组件，用来编辑当前选中的组件的各项内容

完成后大概是这样的，以一个最简单的节标题组件为例：

如上图所示：左侧容器排列着这些常用组件的标签。将活动需要的组件标签拖入预览区域后，会生成对应的预览组件和编辑组件；点击这个预览组件，组件编辑区域会显示对应的编辑组件；在编辑组件中可以对组件各项进行编辑。编辑完成后，通过事先的数据绑定，预览区域对应的组件就会更新视图，显示组件当前的最新内容。

以上就是这个系统的一个大概方案，下面谈谈具体的实现。

首先，从标签区域开始：

标签组件是每个活动组件的开端，也就说每一个标签组件必须有一个属性来标识它代表的是哪一个活动组件。那就先给它们指定类型 type：

然后每当我们拖动一个标签组件到预览区域，再根据该标签组件的type生成对应的预览和编辑组件。预览和编辑组件需要确定的无非就是有哪些编辑项，这些编辑项是什么内容。以节标题组件为例，它就只有一个编辑项：节标题的文本。也就是说节标题的预览组件用来显示节标题的文本，编辑组件需要有一个文本域来对节标题文本进行编辑，在模板事先绑定好对应的数据，文本域的数据变化会反应到预览组件的DOM上。

我们需要有一个保存所有组件数据(对象)的容器，可以使用一个数组。

我更喜欢操作一个数组而不是对象的原因：vue对数组的基本方法(push、splice、shift等)都进行了封装，通过这些方法来改变数组的数据，结果都是响应的。而在保持响应的情况下，改变对象的数据要麻烦些，特别是复杂的嵌套对象。如果使用对象可以通过id直接匹配到对应数据，通过数组需要遍历一下。但是有了es6的for of，代码还是很简单，而且也不是在操作DOM，性能影响不大。

每个组件数据对象的id属性是唯一的，是拖入标签组件时生成的，这个id属性是关联预览组件与对应编辑组件的关键，通过它可以找到每个预览组件对应的编辑组件。为什么不通过type来判断呢？因为每个活动可能有多个相同的组件，比如节标题。通过type没法确定对应关系。

这里我们通过Vuex创建一个store来存储及修改这个数组(官方点的说法就是管理state状态)。按照上面提到的Vuex的数据流规则：UI不允许直接修改数据。在编辑项里面改变某项输入框的值，并不是直接改变了对应组件数据中那一项的值，而是通过DOM事件触发对应的action，action再派发对应的mutaion处理函数来修改state。这种方式可以确保所有对某项组件数据的修改都是通过触发某一个公共的action来完成的，这个action就是进行某项修改的统一和唯一的入口。

当我们知道需要生成什么预览和编辑组件的时候，并放进组件数据容器的时候，我们就必须知道这个组件到底有哪些编辑项(除了组件类型外，我们放入的这个组件数据对象还需要哪些属性)，这时候我们就需要一个map，来管理组件type和组件编辑项的关系，以活动的投票组件为例：

根据需求，投票组件需要有以下编辑项：

2.投票项，每项要有一个名称，后续每项可能还会有其他属性(类似正确选项的标记等)

就能获取到组件数据并存入组件数据容器了。由于我们在预览组件和编辑组件的模板视图已事先对DOM进行了数据绑定，当我们改变组件容器中某个组件的数据项时，更新就会反应到DOM上。当我们保存整个模板的时候，只需要取出组件数据容器中的值就行了，其实也就是那个数组本身。H5展示端通过这个组件数据数组，可以拿到组件的数据以及排序，按照定好的模板渲染出来即可。当然，像投票组件这类有交互数据的组件，该系统设计的模板只是确定了要展示的固定的内容。具体的投票总数、每项投票数等属性需要后端处理后插入到对应组件数据里面，供展示端显示。

整个系统大概的设计思想就是这样的，下面挑些具体的来讲讲：

因为标签组件的表现和交互逻辑等都是一致的，这里做了一个公共可复用的标签组件，对外接收两个参数：title(标签文本)和type(标签类型)。在标签容器组件创建一个包含所有标签组件数据对象的数组，在模板视图中遍历这个数组，就创建了所有的标签组件。

公共标签组件的统一的属性和方法等存入了一个对象字面量里面，导入以后通过mixin方式混合，组件就会拥有这些属性和方法。目前这样做的意义不大，因为已经有一个公共的标签组件了，mixin里面的东西完全可以直接写到这个公共组件内。但如果每个类型的标签组件都是一个单独的.vue组件文件，mixin的好处就体现出来了：可复用、易维护。

具体实现的代码，省略掉样式

预览组件相对较简单，除了数据的绑定，就是拖动排序。拖动排序的实现是通过html5原生的drag事件，基于vue数据驱动的原理，拖动的时候并不需要去手动改变预览区域内各组件的DOM顺序，只需要改变组件数据数组里面各数据对象的index即可，数据的变化会反应到DOM上。简单的节标题预览组件：

还是以节标题组件为例：

还有一些公共组件以及store等就不再介绍了，前面的讲解已基本包含，差不多就到这里了。最后完成后是这样的：

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持爱安网。