babel-loader和webpack UglifyJS一起使用时console的问题
一起使用babel-loader和webpack UglifyJS时,babel会优先处理一遍代码,编译后的代码才进入webpack进行打包和优化操作。在使用扩展运算符...时,不同的情况会进行不同的处理。当在函数参数中使用时,会编译为arguments,而在调用参数时会编译为apply,如下:
function debug(...args) { console.log(...args) }
会被编译为:
function debug() {
var e
(e = console).log.apply(null, arguments)
}
这是很奇怪的一种解释方法,为什么要用一个多余的e变量来隔离console和log呢?如果这样编译之后,其结果自然不能被UglifyJS识别,drop_console等选项也就不生效了。解决的办法,就是在调用函数时,直接采用apply。
function debug(...args) { console.log.apply(null, args) }
因为没有使用扩展运算符,所以在编译的时候不会产生上面那种奇怪的分割代码,也就正常被UglifyJS优化了。
UglifyJS里的mangle选项可以设置boolean和object,直观的感觉是,mangle选项让你决定是否把代码里面的变量名进行优化,比如有些变量名很长的,它直接一个字母就替代了,极大的缩短了变量名长度带来的代码量问题,只要在同一个作用域里面,不被外部调用,这种替换非常安全。这一招直接让你的代码缩减巨大,即使你把compress选项设置为false,也能看到显著效果。它还提供更详细的设置选项,你可以选择是否替换toplevel的变量名(默认不替换),也可以有其他选项,具体可以看文档。
-
mangle 为object 怎么配置呢?
uglifyJS AST 语法树 混淆 怎么配置 知道吗? -
请查看官方文档#852 回复给#850 否子戈 2019-10-13 09:11
Promise catch往后传递
Promise实例有then方法和catch方法,一般用then来处理成功返回数据时的情况,为了把处理后的数据往下一个then传递,通过return一个新数据的方法,让下一个then的参数等于这个新数据。catch方法更有差别,当你调用一次catch之后,后面如果再继续调用catch方法,它们都会被忽略,因为从概念上也可以认为,catch之后,错误已经被捕获了,为了让后面的catch还能生效,和then的return类似,也可以通过一种方法往下传递,但是不是用return,而是用throw:
new Promise((resolve, reject) => reject('a')).catch(err => {
console.log(err)
throw err
})
.catch(err => console.log(err))
这样就可以使第二个catch也捕获到错误信息,当然,在第一个catch中,可以通过throw不同的err来传递不同的错误信息给下一个catch。
svg defs pattern fill image
svg里面有时候会用pattern去写一个背景图片,然后在其他元素里面去使用fill: url(#patternId)来调用它,这样就可以实现在一个svg里面定义自己的背景图片,而且还可以使用svg来画这种背景图。
但是有一个问题是,在IE里面,fill调用不支持style属性中使用,比如下面的无效代码:
<rect style="fill: url(#patternId)">
在Chrome下是正常的,但是在IE中使用的时候,没法正常显示,而你需要将fill属性改为attr:
<rect fill="url(#patternId)">
这样才能正常显示你想要的背景图效果。
setTimeout(fun, 0)是什么意思?
浏览器线程包括:GUI渲染线程,JavaScript引擎线程,浏览器事件触发线程,定时触发器线程,异步http请求线程。其中,JS引擎线程就是执行JS的主线程,GUI渲染线程跟JS引擎线程是互斥的,不能同时进行,所以当JS陷入死循环的时候,浏览器界面没法进行渲染,而如果渲染消耗了大量资源,JS也没法马上执行。
setTimeout(fun, 0)是一个有趣的现象。这里的知识点是,定时触发器线程和JS主线程是分开的,当执行setTimeout的时候,就是告诉JS主线程,需要被分发到定时触发器线程中去计时等待。线程与线程之间通过消息来通信,当定时触发器线程的某个任务执行完之后,它会把消息发送回主线程,这个消息其实就是回调函数,它把回调函数发回给主线程,但是发回的消息在主线程执行顺序的最末端。所以setTimeout(fun, 0)的效果虽然在时间上看上去是立即执行,但是相对于js程序而已,其实是有一个延时的,起码延时到当前主线程所有任务的最后面。
这好像没有什么用,但是起码在阅读代码的时候不会懵逼。
今天见识到一门新的基于java的语言Kotlin,它有点类似TypeScript,是java的语法糖超集,据阅读到的一些文章看,Kotlin没有对java的实现全部重写。最重要的是,我看到有人指出,Kotlin可以直接编译成JavaScript。也就是说,一门语言,可以根据需要针对不同的应用,进行不同的撰写,然后编译出对应的语言去执行即可。你想在java平台上跑一个应用,用Kotlin写好,编译成java程序,拿去跑就可以了。你想在前端跑,用Kotlin写好,编译成JavaScript拿去跑就好了。我还不知道这种说法,是不是我想象的,一套代码根据需要编译成不同平台版本,但是这确实一点屌。难道现在的新生代语言都是这么玩儿的吗?语言已经突破平台的界限,更拼自己的语法和实现了吗?屌!
sass项目中的modules出口
一个组件的sass里面,不应该直接引用某个第三方vendor来进行继承,因为当sass compile的时候,会把第三方继承过来的code全部编译过来,导致你的组件编译后的css里面有大量第三方vendor的样式。正确的做法是当你要继承的时候,仅引入第三方的module文件,比如:
@import "~bootstrap-sass/.../_colors.scss";
因为一般的sass项目都会将单独的变量、函数等放在单独的文件中,而这些文件里因为没有实际的样式规则代码,所以在编译之后,它们实际上不会产生最终的css样式。
而如果你在写一个sass项目的时候,也应该遵循这种原则,如果你的组件的sass打算给其他组件去继承,也应该提供一个这样的modules的出口,这样别人只需要继承你的这个modules的出口文件,而不是你的样式出口文件。
-
[…] 我今早写了一个Note,就是讲解决这个问题的思路。简单的说就是,不能直接@import "module",而是应该import一个具体的入口scss文件,而这个scss文件只提供变量、函数等的出口,而不产生实际的css规则。这样,当你import这个入口scss文件之后,虽然编译实际上还是会引用这个scss,但是编译的结果中没有任何module的css输出,因为你只是引入了当前你的项目文件中需要的一些scss全局变量之类的。 […]
当一个作用域内的一个(或多个)函数使用的上述作用域的变量,而这个函数并不被立即使用,而是处于备用状态,那么这个作用域将会驻留在内存中(更长的生命周期),这种现象被称为闭包。这个作用域不一定是该函数内变量的上一级作用域,也可能是该函数上很多级作用域。不被立即使用有两种情况,一种是被作为返回值(或返回值的一个方法)被赋给作用域之外的变量,由该外部变量来决定什么时候使用;另一种情况是,被当作异步操作的回调函数。驻留内存的时间由该函数的引用最终被释放来决定,当这个作用域内类似的引用全部被释放时,作用域才可能在内存中被销毁,闭包才会关闭。
有的时候需要获取用户的家目录路径,使用下面代码获取:
const USER_HOME = process.env.HOME || process.env.USERPROFILE
这样就可以在其他地方使用USER_HOME,如果为了多地方使用,可以写成一个函数导出模块。
react和vue都如此的受追捧,是否意味着以组件为核心的开发模式已经成为各个公司前端开发的主要模式?而react和vue如此像,以至于网上那么多文章对它们进行比较。剖去语法和封装的不同,react和vue在本质思想上所运用的技术似乎非常接近,特别是vue2直接把react中的一些技术借鉴过来之后,两者的本质区别越来越模糊,这是否意味着它们实际上在共享一种还未被点破的前端思想,以至于它们会不约而同的给开发者惊喜。而这个被共享的思想,我觉得就是关于组件的思想,它们所要解决的一切,都是为了组件这个问题而出发。未来,这种思想,或许将会统一为一种技术,也是我现在思考的“组件衣服”的技术。