如何接"地气"的接入微前端
前言
微前端，这个概念已经在国内不止一次的登上各大热门话题，它所解决的问题也很明显，这几个微前端所提到的痛点在我们团队所维护的项目中也是非常凸显。
但我始终认为，一个新的技术、浪潮，每每被讨论最热门的一定是他背后所代表的杰出思考。
“微前端就是…xx 框架，xx 技术”
这种话就有点把这种杰出的思路说的局限了，我只能认为他是外行人，来蹭这个词的热度。
在我所负责的项目和团队中，已经有非常大的存量技术栈和页面已经在线上运行，任何迭代升级都必须要保证小心翼翼，万无一失。
可以说，从一定程度来讲，微前端所带来的这些好处是从用户体验和技术维护方面的，对业务的价值并不能量化体现，落地这项技术秉
这一年我的对组件的思考
这一年，对于我来说真是压力空前，之前公司接需求的时候大部分情况是看排期，如果排期紧张再协调安排处理。
BUT！ 来这边以后概况大致如下：
这边有个需求来处理下，什么？有其他任务？那不是很正常；
优先级？并行！都很重要，并行很正常，我这里也有好几个事并行呢，DeadLine是xxx号；
做的差不多了您看看？整理好一份文档描述清楚，以便沉淀；
你上次做的那个需求有地址吗，有相关介绍吗，有实现步骤，组件放在哪里了？这样聊不清楚，你写一份文档；
Hi all，这里有个地方我觉得这样处理非常零散，这不好…那不好…，我觉得可以这样！——好这件事，你负责跟进就按照你的想法处理。
这里我重新做了
Tumax-复合状态管理（显隐问题）
故事点介绍
在 Tumax 项目中，作为编辑器存在非常多的“视图交互”，其中关于显隐就是一块状态复杂、由多重因素影响的交互重灾区。
技术难点
随着项目的不断迭代，业务需求的不断增多，隐藏的交互事件也逐渐增多（墙体隐藏，吊顶隐藏，地面模型隐藏，硬装下隐藏，选择房间后隐藏，挂墙、门窗跟随隐藏，不同路由显隐不同），这么多显隐逻辑混在一起，逐渐发现我们以前原有的显隐逻辑变得异常混乱。
举个简单的例子：
在户型导航的逻辑中，要求对选中的房间以外的所有模型数据都隐藏，当我们执行这样的操作后，表现正常
在墙体隐藏的逻辑中，要求遮挡观察实现的墙体全部隐藏，当不遮挡视线后再恢复显示
1. 选择单
JavaScript 常见设计模式
前言
设计模式，这一话题一直都是程序员谈论的”高端”话题之一。许多程序员从设计模式中学到了设计软件的灵感和解决方案。
有人认为设计模式只在 C++或者 Java 中有用武之地，JavaScript 这种动态语言根本就没有设计模式一说。
那么，什么是设计模式？
设计模式：在面向对象软件设计过程中，针对特定问题的简洁而优雅的解决方案。
通俗一点讲，设计模式就是在某种场合下对某个问题的一种解决方案。如果再通俗一点说，设计模式就是给面向对象软件开发中的一些好的方法，抽象、总结、整理后取了个漂亮，专业的名字
其实很多设计模式在我们日常的开发过程中已经有使用到，只是差一步来真正意识、明确到：”哦
Vmo前端数据模型设计
Vmo 是一个用于前端的数据模型。解决前端接口访问混乱，服务端数据请求方式不统一，数据返回结果不一致的微型框架。
Vmo 主要用于处理数据请求，数据模型管理。可配合当前主流前端框架进行数据模型管理 Vue,React,Angular。
能够有效处理以下问题：
* 接口请求混乱，axios.get...随处可见。
* 数据管理混乱，请求到的数据结果用完即丢、拿到的数据直接放进Store。
* 数据可靠性弱，不能保证请求数据是否稳定，字段是否多、是否少。
* Action方法混乱，Action中及存在同步对Store的修改，又存在异步请求修改Store。
* 代码提示弱，请求到的数
Tumax-H5数据流向及解析
说明
相信很多 同事在刚刚接触图满意项目时，对项目中的数据流向和数据解析过程都很模糊， 不清楚数据到底是如何从一份 JSON 数据变为我们使用的数据对象。
这篇文章将会为你 介绍图满意项目中，数据的解析还原及数据流向，为你揭开这一神秘面纱。
通过这篇文章，你将会明白数据是如何通过接口返回的 JSON 一步步变为我们可以拿来使用的 Model，同时我会介绍为什么需要这样处理，如果不这样处理带来的 弊端是什么。
当阅读完文章后，需要对图满意项目有明确的数据流向认知，清晰 明了的了解 dataObject、ModelData 及 Model 的区别。后续开发业务代码需要
Tumax-H5设计要点
H5 项目中数据与视图的同步响应
Vuex 中不能解决的问题
使用 Vuex 更贴合 Vue 项目，Vuex 支持响应 Vue 内部的响应事件，比如：当某状态改变时 Vue 会同时触发改变 computed,render 等。
但缺点是在其他库中缺无法观察响应 Vuex 中的变化，比如：当 Vuex 中的一个状态值改变，需要对应的触发响应到 ThreeJS 和 PIXI 中去改变摄像机的位置，则需要在某个在生命周期范围内的组件去处理响应事件，并通知到 ThreeJS 和 PIXI 中去改变响应数据。这样整个过程就变得十分麻烦。
另外，当 ThreeJS 中有任何数据改变，反过来如果要触
JavaScript面向对象和模块化
JS 是否有必要使用面向对象、设计模式
在一次面试过程中，一位已经有 5 年工作经验的前端，在回答面试问题时这样说到。
问：你能说说 JS 的面向对象和设计模式吗？
回答说：这些内容主要是后端的 Java，C#这种高级语言才会用到的，前端一般我们没有用到。
对于这样的回答，不禁让我有点无话可说，JS 中是否有必要使用面向对象以及设计模式呢？我列举了以下几个场景：
数据接口请求
一般的，在请求接口方面，我们一般会使用一些第三方库，比如axios。然后在逻辑代码部分，比如在组件中直接使用axios进行请求，例如：
let methods = {
/**
* 获得分类信息
*
