这一年我的对组件的思考
这一年，对于我来说真是压力空前，之前公司接需求的时候大部分情况是看排期，如果排期紧张再协调安排处理。
BUT！ 来这边以后概况大致如下：
这边有个需求来处理下，什么？有其他任务？那不是很正常；
优先级？并行！都很重要，并行很正常，我这里也有好几个事并行呢，DeadLine是xxx号；
做的差不多了您看看？整理好一份文档描述清楚，以便沉淀；
你上次做的那个需求有地址吗，有相关介绍吗，有实现步骤，组件放在哪里了？这样聊不清楚，你写一份文档；
Hi all，这里有个地方我觉得这样处理非常零散，这不好…那不好…，我觉得可以这样！——好这件事，你负责跟进就按照你的想法处理。
这里我重新做了
Bit初体验
官网
Github
Bit makes it easy to share and manage components between projects and apps at any scale.
It lets you isolate components from existing projects with 0 refactoring, with fully-automated dependancy definition/resolution and scalable versioning.
It lets you reuse individual components across
为你的JavaScript库赋予插件能力
前言
最近在做一个中台框架的设计开发，在做了主框架的基础能力后，思考在框架落实真实业务需求过程中，需要对主框架功能有非常多的定制化内容存在。如果在主体框架中做了哪怕一点业务改动，都可能会对后面的拓展性及灵活性有所限制。
所以为了让主体框架做的更加灵活、扩展性更搞，在主框架有了基础能力后，就不再对主框架做任何非主框架能力的业务功能开发。
要为主框架不断的”开槽”
其实在很多前端库中都有类似的设计，才能够让更多的开发者参与进来，完成各种各样的社区驱动开发。比如：Webpack，Babel，Hexo，VuePress等。
那么如何为自己的项目开槽，做插件呢？
调研
在了解了很多插件的项目源
性能优化之事件响应与相交算法
故事背景
为了解决用户使用过程中的体验问题，我们团队进行了走访用户调研，在调研过程中发现：在一些配置较差的机器上存在拖动模型异常卡顿的情况。
从以上的交互动图中可以观察发现，在已经实现的功能中，家具拖动过程中包含有几种交互：
* 家具移动
* 框选多个家具移动
* 与周围家具吸附交互
* 与墙体吸附交互
* 与墙体碰撞功能（在家具未完全移动出墙体时，保持模型在房间内）
* 与其他家具叠放
* 实时计算显示家具周围标注（实现模型周边感应功能）
在这么多交互同时运行中，肯定会出现一些计算过程，那么如何能够在不影响原有交互的基础上，实现更加高效低耗的实现过程呢？
发现问题
一个命名引发的性能问题
故事背景
我最近主要在定位、解决当前项目中的一些性能相关问题。
在反馈的问题中，比较严重的问题之一是在户型预览编辑过程，电脑的 CPU 占用率高，及时什么都不做的情况下，CPU 占用也非常的高。
同样的，利用 Chrome 提供的 Performance 录制 ⏺ 了无任何操作的 JavaScript 调用火焰图，发现 Pixi 内部会利用浏览器的requestAnimationFrame接口，执行自身的 render 方法进行 2D 场景的绘制渲染。
发现问题
初步定位，CPU 占用只可能与 2D 场景中 PIXI 的 render() 有关系，使用 Performance 分析事
Pixi 1px线段性能优化
故事背景
随着图满意项目的不断迭代，功能的不断叠加，时不时会有一些用户反馈卡顿，甚至页面崩溃的情况出现。
为了解决和定位问题，我们特意做了用户调研，以及尝试做一些性能监控捕获异常。在调研过程中，我们发现在用户配置较低的电脑上对于 2D 下的一些缩放事件会出现明显的卡顿现象，帧率大概下降到 20fps。
需求
在 2D 界面中，有一个背景网格一直在页面中显示。它的交互要求是：不论界面如何缩放，网格的线段粗细始终保持不变，否则将会出现非常不好看的粗线条以及细线条等。
除了 2D 网格需要此交互，项目中任意物体的描边也同样需要次交互需求，如：墙体描边，门窗描边，标注线等。
问题发现
在之
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 的区别。后续开发业务代码需要
