如何接"地气"的接入微前端
前言
微前端，这个概念已经在国内不止一次的登上各大热门话题，它所解决的问题也很明显，这几个微前端所提到的痛点在我们团队所维护的项目中也是非常凸显。
但我始终认为，一个新的技术、浪潮，每每被讨论最热门的一定是他背后所代表的杰出思考。
“微前端就是…xx 框架，xx 技术”
这种话就有点把这种杰出的思路说的局限了，我只能认为他是外行人，来蹭这个词的热度。
在我所负责的项目和团队中，已经有非常大的存量技术栈和页面已经在线上运行，任何迭代升级都必须要保证小心翼翼，万无一失。
可以说，从一定程度来讲，微前端所带来的这些好处是从用户体验和技术维护方面的，对业务的价值并不能量化体现，落地这项技术秉
这一年我的对组件的思考
这一年，对于我来说真是压力空前，之前公司接需求的时候大部分情况是看排期，如果排期紧张再协调安排处理。
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等。
那么如何为自己的项目开槽，做插件呢？
调研
在了解了很多插件的项目源
性能优化之事件响应与相交算法
故事背景
为了解决用户使用过程中的体验问题，我们团队进行了走访用户调研，在调研过程中发现：在一些配置较差的机器上存在拖动模型异常卡顿的情况。
从以上的交互动图中可以观察发现，在已经实现的功能中，家具拖动过程中包含有几种交互：
* 家具移动
* 框选多个家具移动
* 与周围家具吸附交互
* 与墙体吸附交互
* 与墙体碰撞功能（在家具未完全移动出墙体时，保持模型在房间内）
* 与其他家具叠放
* 实时计算显示家具周围标注（实现模型周边感应功能）
在这么多交互同时运行中，肯定会出现一些计算过程，那么如何能够在不影响原有交互的基础上，实现更加高效低耗的实现过程呢？
发现问题
