最近遇到了一个问题，背景是这样的。设备端会发送一张图片到服务器上，然后服务器分析这张图片并且上传到七牛云上，然后再保存成一个事件，结果发现总会有一个设备的图片被串到别的设备的事件当中。

本以为这是七牛云的bug，因为我的文件的后缀都是一串时间戳.jpg，只有前面的url会不一样，猜测是因为七牛云只对后面多少位长度的字符串做截取处理，所以造成了存储别的字符串。

后来发现是这个原因，gin的处理函数通常是用一个*gin.Context类型的参数，上传图片我开了个新的goroutine去做，会把这个指针直接传给goroutine，因为我接受设备的事件是个异步操作，所以这个context在gin调度的时候会认为已经用完，分配新的请求的内容到这个地址，于是上传时用的指针指向的内容是另外一个值，造成了上传图片错误，在并发数量大的情况下会发生这样的事情。所以修改为了按值传递参数，在goroutine执行时，会生成一个副本，就不会串了。

goroutine有2点需要注意的。

1. 传递指针时，需要保证，这个指针不会被别的代码所改变
2. goroutine可以用的内存不多，如果选择按值传递参数的话，需要保证那块内容的内存足够的小，这样才能发挥goroutine的优势。

这篇东西觉得有必要写下来，缺失了一些信息，但写给自己看。

See the Pen ELgXJN by Ni (@nisiyu) on CodePen.

前些天做了个网页，tooltip显示时发现tooltip总会盖在别的元素下方，纵使我给tooltip加了很高的z-index，还是会显示在下面。

本以为是第三方组件的问题，但是我发现同样的问题不会在别的地方出现，所以我猜测有某些样式会影响到z-index让其失效，当我一个个style的勾选框去掉时，发现tooltip的父元素去掉transform属性时z-index会失效。这里直接给出codepen。

1. 原来我遇到的那个问题是因为用了translate来使元素居中，但其实可以有别的居中方法。所以需要减少不必要的transform。
2. 实在难以居中要用这个方式时，还是只能规避，用js去计算位置，就可以避免transform。
3. 要用z-index时，需要检查一下代码，父级元素中是否有transform同时出现。

公司里最近让我负责一个项目，我试着引入了typescript，感受一下强类型的威力，原先已经有个react项目模版，改成了ts版的，这里把工作的笔记写在这里，可能不太全，将就着记录。

尝试步骤

1. 添加编译设置
2. 修改js代码至ts
3. types文件改动

编译选项设置

1. typescript官网有一个如何在React使用typescript的文档，里面介绍的是用create-react-app创建一个app脚手架，但是问题是创建出来的项目是用一个react-ts-scripts的工具编译的。我观察了很久没找到它是不是用webpack的，觉得似乎没什么可以配置的地方，最终还是用webpack中typescript的loader，这样可以用一套更加熟悉的工作流。
2. loader可以使用ts-loader或者awesome-typescript-loader，这两个loader都出现在了官方的文档中，我使用的是awesome-typescript-loader，据文档称比ts-loader快一些。同时也在原来配置eslint-loader的位置改成了配置tslint-loader
3. 在项目根目录下添加了2个文件: tsconfig.json以及tslint.json，这两个文件设置了一些基本的ts编译选项。类比一下，和.babelrc或者eslint.json差不多。文件内容来源于一个github上的一个react-ts-boilerplate
4. 我曾经想尝试只用awesome-typescript-loader而不用babel-loader，但是编译出来的代码虽然target是es5，但有些浏览器不能跑(这点我一直在疑惑为什么)，放在微信web开发者工具里面一直报错，所以在项目里ts编译后还是用了babel的loader再转一下，保证和原来一样能够运行。

修改js代码至ts代码

1. 首先，就是把js代码扩展名变成ts，然后就开始根据ts的编译错误提示进行修改。
2. 需要注意的一点是模块引用有着些许的不同，引入模块默认的export要按照as的语法写，例如原来引入React是

    import React from 'react';

typescript中必须这样

    import * as React from 'react';

3. 为函数以及变量添加类型，具体定义类型的语法一般是: type，如果不确定可以通过加any类型使代码被编译器所接受。
4. 全局变量的操作，有一些代码依赖于别的script tag，如微信的JS SDK，会在window下面挂一个wx对象。这时候如果直接调用wx.someAPI()，那么ts检查会报错，没有wx对象。但是如果调用window.wx,编译器还是会报错，因为window对象在types里已经有了一个window类型，下面没有wx这个field，除了改写types文件，还可以用类型断言的语法：

    (<any> window).wx.someAPI();
    // 或者
    (window as any).wx.someAPI();

5. React相关写法。typescript中的类型定义中，interface是一个比较重要的语法，可以规定object中有哪些类型的field。这个就非常适合定义React组件的props和state的类型，typescript会对调用组件用的props进行类型检查，React定义为了一个泛型，一个标准写法如下：

    interface someStateType {
        ...
    }
    
    interface somePropsType {
        ...
    }
    
    class someComponent extends React.Component<somePropsType, someStateType> {
        ...
    }

types配置

1. 安装@types包，一般常用的js第三方库目前都有了声明文件，在membership-h5项目中，package.json配置了以下包：

    "@types/node": "^9.3.0",
    "@types/react": "^16.0.34",
    "@types/react-dom": "^16.0.3",
    "@types/react-router-dom": "^4.2.3",
    "@types/react-tap-event-plugin": "0.0.30",

有了这些包后，例如在用react代码时，ts检测到是js包，则会自动到node_modules/@types/目录下去找react的声明文件，那静态检查时用的规则就是按照声明文件为主。

2. 但是如果是其他第三方库，有可能没有types文件。
   • 有的时候是这样解决的，例如某公司内部库，会在所有js文件加一个同名的.d.ts文件，这样引入进来时直接把.d.ts引入进来
   • membership项目中采取的是这样的方式，自己觉得最好不要修改node_modules已经存在的东西，公共库还不是太了解，没有很大胆量去做声明文件。tsconfig.json中，有一个编译选项，是typeRoots。于是在配置里面加上了这句，用dts目录 放.d.ts文件

    "typeRoots" : ["./node_modules/@types", "./src/dts"]

3. 可以建立专门的types文件为业务数据建模，dts目录下写了commodity.d.ts，定义了一些业务数据的类型和存在的fields，如积分商品，兑换记录。这样定义好还有文档的作用。

todos

1. 取消项目中现在暂时填写any的部分，完善类型。
2. 调查有没有办法完全取消babel-loader。
3. 利用typescript的静态类型检查做更加完善的数据校验函数，防止出现一些取undefined下数据的异常。
4. 找到一些tslint warning的比较好的解决办法。

上周我在公司进行了一些分享，主要是想以非技术的视角，说一些自己进步的动力和一些原因。

我把工作分成了三个阶段，第一个阶段是初级的阶段，第二个阶段是突破自己的阶段，第三个阶段就是挑选自己爱的技术进行钻研的阶段。

初级阶段，我倔强也不爱问人，造成了进步比较慢。
第二阶段也并没有变得爱问人问题，但是我开始尝试自己修改别人的代码运行，后来就发现原来有些没接触的框架也没那么难，自己试着做一做总能做出来，于是突破了自己，自此之后感觉前端问题都能通过自己研究研究出来。
第三阶段就是不断练级的阶段，自己读文档，找项目，找issue来帮助自己解决一些问题，并且自己通过读源码来解决问题。

有时候自己钻研效率低，但辩证地看，自己钻研促使了我成为了一名工作中比较独立的工程师，同事有很多时候并不是研究自己遇到问题的专家，即使他们更有经验他们也需要重新学习，有可能会耗费很长的时间。自己建立一套思维过程比什么都重要。

自己其实一直在酝酿，什么时候该向身边更有经验的工程师求助这个话题。
1. 遇到什么事情，首先选择调研，项目官方文档和搜索引擎能告诉自己的事，绝对不应该麻烦别人。
2. 没有相关内容，可以进行求助，但是需要有些条件。包括描述自己现在遇到的状况背景，以及自己尝试过的方法，遇到的错误。这样可以给出很多信息给被求助者，排除错误答案或者节省尝试时间，而且也会更赞赏你是一个动脑子的人。
3. 当自己的背景知识高度太低以至于搜索引擎很难帮助到自己的时候，毫不犹豫应该麻烦别人给自己进行一次知识普及。例如不知道一个特殊的技术名词，只能用通俗语言描述现象时，该问一下相关的技术名词是什么，否则连搜索引擎搜索的关键词都不知道写什么。这些技术名词可以说是你和这个世界的共同语言，这点共同语言其实也应该在平时的学习中进行积累，多看点未必有立即直接作用的内容，储备下来在脑海中成为索引，这样才能使前两步更加有效。

一晃时间已经到了8月份，我转行也转了一年了，我在生日的后一天到新公司报到，然后新公司今年给我过生日时，也就到了整整一年。

今天突然想起来要更新一下博客，总结一下自己这一年来的心路历程。想想自己的路该如何继续。

去年8月份到年底，可以算是第一个阶段，我以前没有做过什么前端的项目，也就是准备面试题的时候大致了解了一下包含了哪些东西。一开始起步的时候主要是为我们的产品做模版，无外乎就是写一些模版文件和对应的css，懂了大致的模版的运作，然后学会了sass之类的东西，在公司已经搭好的项目框架中填内容，也有boilerplate，所以就成为了页面仔，开始熟悉起了各种样式。至今，css仍然是我很不喜欢的一样东西，因为搞兼容时会觉得它根本不讲道理。。。

后来到了今年，做过3个模版的我，会把自己的心放在如何变得更厉害上。但是周围对我的诉求都是修改模版之类的，和设计稿不是很一致要叫我改，和设计稿一致了但觉得不太好还是要我改。有时也会心理上不舒服，觉得好像是别人对我的工作不认可，就当即怼回去，“你觉得这样好，我还觉得那样好呢。” 有时侯会搞得不太愉快，不过我还是很高兴的，起码大家的出发点都是为了公司为了共同的事业好，跟某为的情况完全不一样。不过这就让我隐隐有点担心，一直做改个style这样的工作，没什么提升啊，于是我就找机会主动担起修改店铺页面框架和建站工具的工作，也是渐渐地handle住了公司所有的前端代码库，这里面我最喜欢干的还是修改建站工具来着，因为觉得比较特别，不像普通的curd程序，做起来好玩。

公司走了两个比较有经验的程序员，所以我也是渐渐地挑起了一些梁，比如最近就在将原先的react版的建站工具改成vue版的。（起初修改似乎是reduxform经常会有些奇怪的问题搞不懂，所以换了）总的来说，我觉得框架并没有太大的区别，但我个人不是很喜欢看jsx的语法，觉得vue的模版语法看上去更舒服一点。在重写的过程中遇到了不少困难，不过好在都一一解决了。

这一年来呢，我有些基本的进步，但毕竟我还是有着收入大幅上升且增加水平的目标，这点进步根本不快。

我有的时候会觉得“这样设计又不一定好，我不想做，而且代码实现起来也不优雅”这样的固执，但是我觉得是不太好的，好不好还是应该让运营和产品经理负责，研发人员最重要的还是要执行力，一个人一个想法很难将一个多人协作的产品推行下去。比如一件东西不好，再通过快速迭代修改过来，我觉得也是没错的。

所以我想的就是，在我职业生涯的第二年，我的第一个目标就是要做得更快更快，我有很多时间现在还是在”调程序“中度过的，应该要变得更成熟一点，对自己写的东西更有信心一些。做得快——我认为在初创公司中很能代表我在这个工种上的价值，还需要摸索摸索。目前先想到这两件事：

1.  减少写一句看一句的动作，靠写基本的单元测试之类的来保证
2. 写每一个feature前也更加做好整个系统的规划，记录下来，待做好之后回顾与 预想之间的区别，总结一下自己哪里容易没想到。

好的，先这样吧。我认为可以。

最近我除了做模版也在做一些可改进的部分，也做了些更有挑战的内容。感觉收获不少，公司的建站工具属于主打产品，最近也修改了很多其中的代码，学习了一些关于react的小技能。

最近想做一个“拖动调整板块顺序”的特性，看到前辈写过一段代码是可以给导航菜单拖动排序的，准备学习一下移植到建站工具的页面板块中来。

0x00 背景说明

建站工具是一项有些的技术，我司的产品中是在建站工具项目中插入一个iframe，iframe中运行着客户网站的项目，能够和react的项目通信。

左侧预览窗口是网站前端的项目，右侧的设置栏是建站工具的项目，它们互相进行通信，通过通信的消息类型和数据回调，保持配置数据和网页前端样式的同步。

假设网页前端项目叫做Front 建站工具项目叫做Editor，这个特性的流程可以说是这么样的：

1. 在右侧拖动一张卡片，原来顺序是m，拖动到n。
2. Editor计算好新的板块顺序的数据，发送给Front。
3. Front收到消息后保存了这段数据，重新渲染iframe里的页面，顺序发生改变。
4. Front刷新页面后会给Editor发送数据，Editor根据Front的数据来更新卡片顺序（项目以这个前提运行，这段不能不运行）

卡片顺序必须缓存着，这样可以快速保存。
在这里我们选用了react-dragula插件，该插件会生成一个decorator，将一个容器以ref和这个decorator绑定，就可以使这个容器下的子元素变得可以拖动并排序。decorator本身有很多支持的特性，插件的具体用法可以在https://github.com/bevacqua/dragula和https://github.com/bevacqua/react-dragula查看更多

0x01 问题

预想流程如下：

1. 使用拖动插件拖动
2. 监听drop事件，根据drag位置和drop位置计算新的顺序存进缓存
3. 读取缓存中的内容用react中setData的方式刷新页面

问题来了，我每次拖动修改顺序后，会跳变两次，
一次是插件本身的顺序调整，
还有一次是修改数据引起的调整。

查看了数据以后，发现数据没有错，更新的数据顺序对了，但是显示的是错的，那就说明react-dragula这个插件本身会保存一个状态，这个状态可能是做过的拖动操作后形成的一个新排序和旧排序的映射。

然后怎么改都觉得不太成功，于是看了看项目的issue，看了很多，找到了https://github.com/bevacqua/dragula/issues/188

这篇文章的标题写的是Option to not move or clone，正是我所想的“保留数据，但是摒弃新排序和旧排序的映射”，但是作者似乎并没有加这个option，但我从下面找到了react的解决办法，每次drop时重新计算顺序，再改变插件中的状态。不过评论说，在数据量多的时候也许有性能问题，我们的板块最多十来个，所以我就使用了这套方案。

https://github.com/bevacqua/dragula/issues/188#issuecomment-206762598

后面我自己的解决和业务太相关就不说了。
也算是一次比较愉快地通过看issue解决问题地经历～分享一下。