132017.6
16:51:31

svg里面有时候会用pattern去写一个背景图片,然后在其他元素里面去使用fill: url(#patternId)来调用它,这样就可以实现在一个svg里面定义自己的背景图片,而且还可以使用svg来画这种背景图。

但是有一个问题是,在IE里面,fill调用不支持style属性中使用,比如下面的无效代码:

<rect style="fill: url(#patternId)">

在Chrome下是正常的,但是在IE中使用的时候,没法正常显示,而你需要将fill属性改为attr:

<rect fill="url(#patternId)">

这样才能正常显示你想要的背景图效果。

已有0条回复 回复
222017.5
09:33:59

浏览器线程包括:GUI渲染线程,JavaScript引擎线程,浏览器事件触发线程,定时触发器线程,异步http请求线程。其中,JS引擎线程就是执行JS的主线程,GUI渲染线程跟JS引擎线程是互斥的,不能同时进行,所以当JS陷入死循环的时候,浏览器界面没法进行渲染,而如果渲染消耗了大量资源,JS也没法马上执行。

setTimeout(fun, 0)是一个有趣的现象。这里的知识点是,定时触发器线程和JS主线程是分开的,当执行setTimeout的时候,就是告诉JS主线程,需要被分发到定时触发器线程中去计时等待。线程与线程之间通过消息来通信,当定时触发器线程的某个任务执行完之后,它会把消息发送回主线程,这个消息其实就是回调函数,它把回调函数发回给主线程,但是发回的消息在主线程执行顺序的最末端。所以setTimeout(fun, 0)的效果虽然在时间上看上去是立即执行,但是相对于js程序而已,其实是有一个延时的,起码延时到当前主线程所有任务的最后面。

这好像没有什么用,但是起码在阅读代码的时候不会懵逼。

已有0条回复 回复
182017.5
10:17:43

今天见识到一门新的基于java的语言Kotlin,它有点类似TypeScript,是java的语法糖超集,据阅读到的一些文章看,Kotlin没有对java的实现全部重写。最重要的是,我看到有人指出,Kotlin可以直接编译成JavaScript。也就是说,一门语言,可以根据需要针对不同的应用,进行不同的撰写,然后编译出对应的语言去执行即可。你想在java平台上跑一个应用,用Kotlin写好,编译成java程序,拿去跑就可以了。你想在前端跑,用Kotlin写好,编译成JavaScript拿去跑就好了。我还不知道这种说法,是不是我想象的,一套代码根据需要编译成不同平台版本,但是这确实一点屌。难道现在的新生代语言都是这么玩儿的吗?语言已经突破平台的界限,更拼自己的语法和实现了吗?屌!

已有0条回复 回复
152017.5
12:48:22

利用概念推导、还原事物的形成过程、找共性这3个手段来找到事物的本质,再从这个本质推导基于此事物的上层建筑。——翟志军《即将三十,我不敢说我精通任何一项技术》

已有0条回复 回复
132017.5
13:58:33

一个组件的sass里面,不应该直接引用某个第三方vendor来进行继承,因为当sass compile的时候,会把第三方继承过来的code全部编译过来,导致你的组件编译后的css里面有大量第三方vendor的样式。正确的做法是当你要继承的时候,仅引入第三方的module文件,比如:

@import "~bootstrap-sass/.../_colors.scss";

因为一般的sass项目都会将单独的变量、函数等放在单独的文件中,而这些文件里因为没有实际的样式规则代码,所以在编译之后,它们实际上不会产生最终的css样式。

而如果你在写一个sass项目的时候,也应该遵循这种原则,如果你的组件的sass打算给其他组件去继承,也应该提供一个这样的modules的出口,这样别人只需要继承你的这个modules的出口文件,而不是你的样式出口文件。

已有1条回复 回复
102017.5
12:38:28

当一个作用域内的一个(或多个)函数使用的上述作用域的变量,而这个函数并不被立即使用,而是处于备用状态,那么这个作用域将会驻留在内存中(更长的生命周期),这种现象被称为闭包。这个作用域不一定是该函数内变量的上一级作用域,也可能是该函数上很多级作用域。不被立即使用有两种情况,一种是被作为返回值(或返回值的一个方法)被赋给作用域之外的变量,由该外部变量来决定什么时候使用;另一种情况是,被当作异步操作的回调函数。驻留内存的时间由该函数的引用最终被释放来决定,当这个作用域内类似的引用全部被释放时,作用域才可能在内存中被销毁,闭包才会关闭。

已有0条回复 回复
092017.5
10:34:31

有的时候需要获取用户的家目录路径,使用下面代码获取:

const USER_HOME = process.env.HOME || process.env.USERPROFILE

这样就可以在其他地方使用USER_HOME,如果为了多地方使用,可以写成一个函数导出模块。

已有0条回复 回复
042017.5
10:26:39

react和vue都如此的受追捧,是否意味着以组件为核心的开发模式已经成为各个公司前端开发的主要模式?而react和vue如此像,以至于网上那么多文章对它们进行比较。剖去语法和封装的不同,react和vue在本质思想上所运用的技术似乎非常接近,特别是vue2直接把react中的一些技术借鉴过来之后,两者的本质区别越来越模糊,这是否意味着它们实际上在共享一种还未被点破的前端思想,以至于它们会不约而同的给开发者惊喜。而这个被共享的思想,我觉得就是关于组件的思想,它们所要解决的一切,都是为了组件这个问题而出发。未来,这种思想,或许将会统一为一种技术,也是我现在思考的“组件衣服”的技术。

已有0条回复 回复
032017.5
09:23:21

阅读《Vuejs权威指南》的感触之一是,书里的内容实在太老了,很多api早都换了,无论是vue-resource还是vue-router都升级了多个版本。可见,一门技术必须从一开始就追,等到它都长大了,稳定了再看,就会发现很多东西都工程化复杂了很多。对于写权威指南的作者们而言,相信也很痛苦,要是更新书的版本,这些升级后的版本的内容肯定也要全部替换掉,工作量巨大啊。所以,我读这本书,也只是摸清一些原理性的东西,在整体感官上知道有什么,以后再阅读具体的官方文档,不至于陌生。

已有0条回复 回复
282017.4
13:03:51

我越来越觉得,技术是工具,是为生产服务的,而非本身是生产,我更愿意的生活状态是:我需要对某个数据进行分析来帮助决策时,现有的工具无法满足我的需要,这个时候我自己写个程序来快速实现,用完就算了,工具就是你用的时候马上用,用完就丢。未来不做开发,但是却可以充分利用编程这个工具,这才是我想要的生活。

已有0条回复 回复