Blogs
Blogs copied to clipboard
SugarTurboS Blog
## 前言 **单元测试的好处**: * 可保证得到结果的一致性,提高项目、组件稳定性。 * 开发者按单元测试思路去写代码,可清晰代码结构,提高代码的可读性。 由于笔者开发的项目越来越大,公共组件的复用性高,故其稳定性尤为重要。因此,引入单元测试刻不容缓。 **单元测试的不好**: * 会占用一定的开发成本,增加开发工作量。 * 旧项目加入单元测试改动很大,会有一定的风险。 * 会有一定的学习成本,对开发者要求比较高。 * 如果在一些复用性很低的组件使用单元测试,成效不大且开发成本高。 ## 选型 在做项目单元测试前,笔者参考了网上的一些文章以及官方文档,最后选型为Jest + react-test-renderer + Enzyme。 * Jest Jest 是 Facebook 出品的一个测试框架,相对其他测试框架,其一大特点就是就是集成了...
## 由来 经过近几年的沉淀,前端届的变革在现阶段总算是进入了一个平稳期。回顾一下前人走过的路,主要是在解决以下问题: - 浏览器支持的语言特性不太友好,影响开发效率 - 项目缺乏依赖管理,复制粘贴太低效且不好控制 - 需要工具来压缩代码、压缩图片、生成文件hash用于控制浏览器缓存等功能 - 开发时保存代码能实时刷新浏览器提高开发体验 为了解决这些问题,出现了以下解决方案: - babel,将ES6、typescript转成浏览器支持的ES5代码 - DSL(domain specific language),例如:less、sass等对于css的扩展,jsx、vue template、angular template对于html的扩展 - npm 依赖管理工具 - 利用工具处理压缩代码、压缩图片、生成文件hash等功能 - 利用live reload、browsersync、hot reload工具实时刷新浏览器 这些解决方法成为了我们开发中不可或缺的功能,于是我们需要一个工具把这些联立起来,于是前后出现像grunt、gulp、fis、webpack等前端工程化构建工具。经过一段时间的更新迭代后,webpack以万物皆模块的思想以及功能强大,渐渐在众多工具中脱颖而出,成为前端项目中常用的构建工具。...
> 笔者知识和理解水平有限,如有错误之处,欢迎指出和讨论 ### 从业务痛点说起 笔者参与的系统里面,需要接入大量的资源方的资源。对于每一个资源方,最开始的做法是,一个资源方对应着一个模块。所有模块都依赖于共同的SDK,SDK提供了获取资源各种数据的模板方法。资源模块要做的事情就是实现SDK的方法,并且往方法里面编写获取资源数据的逻辑。然后,在运行期,通过SPI机制动态去发现模块,获取相应的资源数据。过程如图所示: 首先是前端发送一个请求,会携带着资源方的ID,这样后端服务解析到资源方ID,根据这个ID去调用对应资源模块的对应方法获取对应的资源数据。  一开始,这样的实现方式运行良好,开发资源模块只需要在对应方法调用资源方接口,进行异构数据适配即可。 但是,随着接入的资源方变得越来越多,会发现存在以下问题: - **项目代码膨胀:一个三方资源对应着一个模块** - **无法动态上线新的资源方资源:因为基于SPI,我们需要事前开发好资源模块,资源模块一块打包部署,才能在运行期使用资源** - 联调成本高:由于都是远程进行接口联调,沟通效率低导致联调成本高 - 重复工作:接入资源方资源工作其实都是重复的,无非就是调用三方资源接口,适配数据 **其中项目代码膨胀、无法动态上线新的资源方资源、联调成本高是最核心的问题。** 那么,如何来解决这些问题呢? 对于项目代码膨胀问题,解决思路是拆离资源模块为独立的工程,主项目工程不依赖于资源模块。联调成本高问题,我们在思考是否可以让资源提供商基于我们提供的SDK为我们编写模块,最后按照我们约定的格式打包给到我们。这样,就会省去熟悉资源方数据结构时间、降低联调接口的成本,对大家都是有好处。重复工作问题,我们只能做到尽可能减少重复的工作。在我们预定好的SDK前提下,我们是否可以让有额外开发时间的小伙伴帮忙开发从而加快开发进度呢? 实际上,使用模块化开发就可以解决这些问题。具体如何使用模块化开发解决上述问题,各位看官且稍安勿躁,且听我慢慢道来。 ### 模块化开发的三种方式 相信大家对模块化开发都不陌生,从前端的seajs、requirejs到后端的JarsLink、OSGI 。都是一套模块化开发的解决方案的开源框架。 实际上,我们平时开发后端服务的时候,也在使用了模块化开发 —— 基于 maven 多模块。...
# 一、开篇 说起前端组件化是这几年老生常谈的话题,笔者就不在这里对前端组件化思想的发展史、优劣做详细的介绍。今天主要与大家分享一下,笔者在开发中从初期的小项目,到后期的项目功能迭代,功能模块越来越多,项目越来越大,组件化规范制定不够完善,多人团队协作开发导致的一些问题,与笔主自己处理的方案的思考。 # 二、发现、提出问题 ## 1、三张图说明一个业务模块功能迭代图。 ### 第1版 组件单向数据流,父组件状态单向传输子组件  ### 第2版 随着功能迭代,非父子组件会共享一些状态。 此处由于非父子组件间状态共享不复杂,优先使用状态提升(状态提升,我们需要把子组件间共享的状态,提升到容器组件进行管理,并有容器组件下发到子组件)解决此类问题。  ### 第3版 随着更多的功能迭代,模块分层越来越多,跨多层组件状态共享越来越复杂  状态管理redux、vuex就是为了解决此类问题而出现。  通过以上的项目模块迭代周期的发现,不可避免的出现多组件状态共享。 通常处理共享状态有三种方式: 1. 状态提升,我们需要把子组件间共享的状态,提升到容器组件进行管理,并有容器组件下发到子组件。 1. 状态管理redux、vuex。 1. 事件机制,子组件改变共享的状态,通过事件管理模块emit分发出去,需要同步更改状态的子组件通过on接收更改事件。...
# 一、为什么需要用node.js调用dll? 公司项目采用Electron( https://electronjs.org/ )开发pc应用,会涉及到与底层硬件设备的通信,而sdk封装 基本上都是通过 C++ 动态链接库dll实现的。 #### 有两种方案可供选择: - 方案一: 使用node-ffi - 方案二: 使用C++编写一个node addon,通过LoadLibrary调用dll 以上两种方案都可以解决dll调用问题,方案选型要个人对C++ 的掌握程度,如果熟悉C++开发,可以直接选择方案二最方便。如果完全不了解C++,那么只能采用方案一。 由于笔主不太懂C++,最终选择第一种方案。 # 二、什么是node-ffi? (https://www.npmjs.com/package/ffi) node-ffi是使用纯JavaScript加载和调用动态库的node addon,它可以用来在不写任何C++代码的情况下调用动态链接库的API 接口。 ffi究竟干了什么?其实它本质上还是一个编译后的Node addon,node_modules/ffi/build/Release/ffi_bindings.node, ffi_bindings.node就是一个addon ffi充当了nodejs和dll之间的桥梁。...
# 前言 本文将介绍笔者在React的项目中使用百度的富文本编辑器Ueditor的过程。注意本文不提供一条龙式的使用方法,只是将使用过程中的一些实现思路进行总结,供以参考。react项目中导入ueditor,会存在各种不正交的问题,需要注意。 ### 引入 首先在ueditor官网下载最新安装包,然后在项目入口的html中导入(导入方式不一,可以采用import的方式,需要自行度娘。但是无论哪种引入方式,只要想自定义功能,不正交问题就难以避免QAQ)。不管三七二十一先跑起来再说。。 ```html ueditor demo ······ ``` 在React项目中使用ueditor要注意 1. 导入的路径,笔者使用的是项目经webpack打包之后的相对路径。 2. 导入顺序,配置文件要先于源码。 3. 笔者这种引入方式存在缓存问题,所以修改ueditor.all.js后需要及时清理缓存,测试新的代码。 ### 封装 ```js /** * 封装UEditor */ import React from 'react'; import...
> * 苏格团队 > * 作者:Jason # 前言 某一天我收到了产品发来的微信消息。小X,我们的业务现在需要一个类似加入购物车的掉落动画,经过组织的慎重考虑,这个需求就交给你了。于是便有了这篇文章。本文并没有描述多少高深的技术,更多的是一些笔者在做动画时对动画原理的思考以及如何优化动画的一些思路。实现效果如下:  **图片质量有限,请谅解** # 技术分析 前端实现动画的方式有很多。无论是JS动画,CSS动画,Canvas动画还是SVG动画,哪怕是GIF动画实现一个简单的抛物线都是足够的。但考虑业务场景的需求以及可玩性,最终决定使用JS来实现这个动画。 # 实现分析 在笔者看来大多数动画效果,归根到底还是 **数学公式的应用**。所谓抛物线动画也无非就是让元素的运动符合抛物线的运动轨迹。 抛物线的方程为: `Y = A*X*X + B*X + C` 也许大家看到这个公式有点陌生。但曾经物理老师念念有词的 `L(距离) = 1/2*A(加速度)*T*T(时间)`...
> * 苏格团队 > * 作者:Jason ## 前言 笔者最近收到要求 **远程控制局域网内多N台终端同步操作** 的需求(功能类似windows上的远程桌面)。 最终笔者实现了一种**不太成熟,不太稳定**,但基本满足现阶段需求的方案,且未来会持续迭代。 出于种种复杂原因,笔者无法使用现在一些市面上很成熟的解决方案。但由于该项目仅限于内部人员使用,即对方案的成熟性,可靠性,可维护性没有太多要求(面部表情逐渐舒展)。 ## 分析 远程控制桌面,无论是1对1还是1对多。核心的数据的无非就是俩类。**音视频信息,控制信息** (键盘,鼠标,快捷键等)。当得到这俩个数据时,我们就可以 **在控制端实时获取受控端的视频信息以及传输控制指令** 。那么接下的操作就是: ### 1.获取被控制端的视频流 作为一个前端开发工程师,对于如何获取设备的音视频信息这件事,本能的我就想起了 **WebRTC** (网页即时通讯)协议。 然后就是分析具体的设备和场景是否适用,一顿脑补分析后,我看行(主要是WebRTC本身强大)。 ### 2.发送与接收控制信息 由于具体业务和某些神秘的限定和权衡。采用TCP协议传输消息是不可能的。那没啥好说的了,**UDP救我!** 虽然他们一次次给我带来的都是,**这个不行,那个也不行** 的种种限制,但是好消息也是有的,在一系列复杂的操作后,我拿到了受控方模拟鼠标和键盘操作的接口。得,齐活!...
> * 苏格团队 > * 作者:WDZ > * 交流QQ群:855833773 > * 欢迎加入我们的团队,微信联系方式:foreverpx_cjl 笔者在业务中碰到了需要**下载示例**和**拖拽上传并实现进度条**的功能,针对过程中遇到的问题,笔者进行了相应的总结。 ## 需求 1. 页面中增加下载示例按钮 2. 实现一块区域能够拖拽上传word文件,限制文件大小2MB和文件类型,能显示进度条,同时支持取消上传。 ## 文件下载 业务中要求的是示例放在静态文件夹中,并不需要请求后台。针对这种场景,笔者将介绍三种方法,分别是**window.open,form表单提交以及a标签**下载。笔者将通过下载img和word文档的例子,对这三种方法进行对比。 现构建dom结构如下: ```js window.open formSubmit aDownload ``` ### 方法一:使用`window.open`:...
> * 苏格团队 > * 作者:Demian ## 一、前言 本文是笔者在看了 frontendmaster 的状态管理课程之后,对 mobx 进行的初步学习的总结。 ## 二、Mobx 简介 mobx 是社区内使用的较为常见的一种状态管理库,mobx 官网称其 > 通过透明的函数响应式编程(transparently applying functional reactive programming - TFRP)使得状态管理变得简单和可扩展 mobx 主要有以下几个核心特性: -...