这一年我的对组件的思考

这一年,对于我来说真是压力空前,之前公司接需求的时候大部分情况是看排期,如果排期紧张再协调安排处理。 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 分析事
Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×