耗砸

耗砸 查看完整档案

成都编辑  |  填写毕业院校  |  填写所在公司/组织 yaozage.com 编辑
编辑

canvas

个人动态

耗砸 赞了文章 · 6月15日

这篇 iTerm2 + Oh My Zsh 教程手把手让你成为这条街最靓的仔

前言

作为一名程序员,开发环境不舒服会很大程度影响开发效率,所以一定要花时间好好整一下开发环境(好了,我知道你是在给摸鱼找借口)。

最近短短几个月,换了两次新电脑,经历了两次装机(由于各种原因,没法备份恢复,你懂的),每一次都得重新搞一套属于自己的开发环境。

这里就记录一下我是如何一步一步的打造属于自己的 TerminalmacOS 上的 Terminal 是怎么样的,你如果想和我一样,直接 cv 大法 就可以搞一套一样的。

文中的链接在微信里无法打开,如果有需要可以点击阅读全文跳转到掘金的文章里。

Terminal

Terminal 我们经常会称作 终端,现在中文版的 mac 里也是叫做这个。

我们每天都需要在其中输入很多命令去做一些事情。可以说,每天有大量的时间都需要面对它。

我记得我第一次点下鼠标,打开这个终端的时候,看到了这样一个界面:

我傻了。怎么这么丑?macOS 上怎么允许有这么丑的应用?

不行,如果让我每天对着它,一定会把电脑砸了(虽然它是高贵的 16寸 MacBook Pro),我得找一个第三方 Terminal 来替代它。

iTerm2

很快,我就找到了新欢,它的名字叫 iTerm2,它是一款完全免费,为 macOS 打造的一款终端工具,可以说是程序员必备了,如果还没用过的,赶紧跟着这篇文章用起来吧。

iTerm2 官网 符合国外网站一向的极简风格(又不是不能用,搞那么花里胡哨干嘛)。

直接下载,解压,拖入 Application 里就 ok 了。打开看看。

怎么感觉不太对,虽然你的背景变黑了,但依然掩盖不了你的丑啊。

没事儿,先天不足,后天努力嘛。

告别黑底白字,整出最骚终端,开始吧。

on my zsh

主角是它,拥有了它,你一定是你们组最靓的仔。

Oh My Zsh is an open source, community-driven framework for managing your zsh configuration.

安装

官网提供了两种安装方式:

# via curl
sh -c "$(curl -fsSL https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

# via wget
sh -c "$(wget -O- https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

如果,由于一些原因,上面两种方法你都没能安装成功,可以试一下手动安装:

# 下载 oh-my-zsh 源码
git clone git://github.com/robbyrussell/oh-my-zsh.git ~/.oh-my-zsh
# 并且把 .zshrc 配置文件拷贝到根目录下
cp ~/.oh-my-zsh/templates/zshrc.zsh-template ~/.zshrc
# 让 .zshrc 配置文件生效
source ~/.zshrc

嗯... 你和我说,clone 也不行啊,不可描述的原因,网速不允许啊。

那你这样做。

oh-my-zsh GitHub 上下载 zip -> 解压 -> 移动 oh-my-zsh 目录到根目录:

cd ~/Downloads
mv ohmyzsh-master ~/.oh-my-zsh
cp ~/.oh-my-zsh/templates/zshrc.zsh-template ~/.zshrc
source ~/.zshrc

如果还不行,你来找我。

好了,重新启动 iTerm2,是不是已经变了。

.zshrc

这个文件非常关键,是 oh-my-zsh 的配置文件,它的位置在根目录下,可以通过 vim ~/.zshrc 查看。

每一次修改它之后,如果想要立即生效需要手动执行 source ~/.zshrc

修改配色方案

一打开 .zshrc,就可以看到关于配色方案的配置:

# Set name of the theme to load --- if set to "random", it will
# load a random theme each time oh-my-zsh is loaded, in which case,
# to know which specific one was loaded, run: echo $RANDOM_THEME
# See https://github.com/ohmyzsh/ohmyzsh/wiki/Themes
ZSH_THEME="agnoster"

oh-my-zsh 提供了很多内置的配色方案,可以通过命令来查看:

ls ~/.oh-my-zsh/themes

也可以打开 https://github.com/ohmyzsh/ohmyzsh/wiki/Themes 更为直观的查看所有的配色方案。

只要修改 ZSH_THEME 的值就可以设置对应的配色方案了。

如果你想每天都过得不一样,可以设置成 random,每次打开 iTerm2 的都会随机使用一种配色方案。

我曾经有一段时间,由于不想折腾,使用的是这个配色方案:agnoster,它是这样的:

当然,有一天,我突然想造作一下,就开始自己配色。(没备份... 找不着了...)

如果你觉得默认的配色方案不够骚,并且觉得自己的审美 ok,也可以自己来搭配颜色。

自定义配色方案

入口:菜单栏 -> Profiles -> Open Profiles -> Edit Profiles -> + 一个配置 -> 选择 Colors

像我这样审美不行的人,花了一整天的时间搞这个,到头来发现,还是默认的更好看一点...

⚠️ 别摸一下午鱼搞这个被老板发现,还是下班了再搞吧。

第三方配色方案

当然,不是只有你和我想要自己搞一套最骚的配色方案,大家都有这样的想法。

iTerm2-Color-Schemes 这里有非常多的配色方案题,也已经在 GitHub 上开源。

你可以像我一样这样做:

# 找一个目录存放 iterm2 相关的文件
mkdir Code/other/iterm2
# 下载 iTerm2-Color-Schemes
git clone https://github.com/mbadolato/iTerm2-Color-Schemes
# schemes 文件夹就是真实存放配色方案的目录
cd iTerm2-Color-Schemes/schemes

同样,如果 clone 不下来就下载 zip 解压就好了。

通过以下操作路径可以导入所有配色方案:

菜单栏 -> Profiles -> Open Profiles -> Edit Profiles -> 选择 Colors -> 右下角 Color Presets -> Import...

找到 schemes 文件夹选中所有配色方案就好了,然后你就 眼花缭乱 会收获满满的幸福。

没事,等等会有更高级的方案。

安装字体 PowerFonts

为什么要安装字体呢?有些主题是会设置图标的,我们电脑上的字体一般都不支持这些图标,会出现乱码。

打开 Fonts 下载 zip 包都本地解压,就会得到很多字体。

# 将下载好的 fonts 移动到之前建的目录
mv ~/Downlaods/fonts-master ~/Code/other/iterm2/fonts
cd ~/Code/other/iterm2/fonts
# 执行安装文件
./install.sh

这样就安装好了,然后通过以下操作路径设置字体:

菜单栏 -> Profiles -> Open Profiles -> Edit Profiles -> 选择 Text

可以选择 Meslo 这个字体,乱码的图标就正常了。

毛玻璃效果/窗口大小

如果想要更高逼格的毛玻璃效果,并且找到自己舒服的大小(???),可以在这里设置:

操作路径:菜单栏 -> Profiles -> Open Profiles -> Edit Profiles -> 选择 Window

自定义背景

激动人心的时刻,你可以为你的终端设置一个自己喜欢的 小姐姐 图片作为背景,敲命令的时候都会更带劲吧:

咳咳,Dota 云玩家们,你是更喜欢冰女还是火女?

操作路径:菜单栏 -> Profiles -> Open Profiles -> Edit Profiles -> 选择 Window

状态栏

可以为每个打开的终端都设置一个状态栏,显示一些系统信息(比如 CPU、RAM、当前目录等)。

操作路径:菜单栏 -> Profiles -> Open Profiles -> Edit Profiles -> 选择 Session

总结

经过这一番折腾,一个属于你自己的高颜值终端就诞生了。

不过,总感觉这样还是有点麻烦,有没有更厉害的玩意儿?有的,我们这就用起来。

神器 Powerlevel10k

Powerlevel10k 简单来说就是一个 ZSH 的主题,只不过它的功能很强大,以下简称 p10k

安装

我们用的是 Oh My Zsh,所以这样安装 p10k 即可:

git clone --depth=1 https://github.com/romkatv/powerlevel10k.git ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/themes/powerlevel10k

然后需要打开 ~/.zshrc 设置 ZSH_THEME:

ZSH_THEME="powerlevel10k/powerlevel10k

安装字体 Nerd Fonts

上文我们已经安装了 PowerFonts,如果需要使用一些图标,这个字体是不够用的,我们需要一个强大的字体:Nerd Fonts,它支持下面这么多种图标:

安装

你可以如官网所说,通过 brew 来安装:

brew tap homebrew/cask-fonts
brew cask install font-hack-nerd-font

但是我不建议这样,包括不建议你下载 zip 包,因为这个文件太大了,太大了,太大了。。。

我们可以这样:

打开 https://github.com/ryanoasis/nerd-fonts/releases,滑动页面找到 Assets 区域,如图:

我们只要下载箭头所指的 Hack.zip 这个字体包,解压缩之后就会获得一些 ttf 字体文件,双击安装即可。

zshrc 设置字体

POWERLEVEL9K_MODE="nerdfont-complete"
ZSH_THEME="powerlevel10k/powerlevel10k"

注意,需要设置在 ZSH_THEME 之前。

iTerm2 设置字体

操作路径:菜单栏 -> Profiles -> Open Profiles -> Edit Profiles -> 选择 Text

这样,所有的图标就都可以正常显示了。

自动配置

如果你指定了 ZSH_THEME="powerlevel10k/powerlevel10k" 但是在 zshrc 里没进行任何手动的配置,打开 iTerm2 的时候就会触发自动配置的流程。

也可以通过以下命令再次进入自动配置的流程:

p10k configure

问题大致如下:

  1. 这个符号看起来像钻石(旋转的正方形)吗?
  2. 这个符号看起来像锁吗?
  3. 这个符号看起来像 Debian logo 吗?
  4. 这些图标都交叉分布在 X 之间吗?
  5. 风格
  6. 编码
  7. 是否显示时间
  8. 目录层级分隔符
  9. 头部(左边)
  10. 尾部(右边)
  11. 是否换行
  12. 左边和右边是否有连接线
  13. 命令行和提示是否连接
  14. 两行命令之间分布稀疏还是松散
  15. 是否需要图标

后面几个选项随意,执行完命令之后,就会初始化 p10k:在根目录下生成 ~/.p10k.zsh,并且在 ~/.zshrc 底部写入:

如果想废除 p10k 的配置,只需要删除 ~/.p10k.zsh,并且删除上面这条命令即可。

自定义配置

如果你想当高玩,也可以在 ~/.zshrc 里手动配置 p10k,或者在 ~/.p10k.zsh 基础上进行修改。

这个得要自己看文档摸索啦,这里我简单说几个配置:

  • POWERLEVEL9K_LEFT_PROMPT_ELEMENTS
  • POWERLEVEL9K_RIGHT_PROMPT_ELEMENTS
  • POWERLEVEL9K_VCS_GIT_GITHUB_ICON

POWERLEVEL9K_LEFT_PROMPT_ELEMENTS

显示在命令行左边区域的元素:

和上图相对应的配置为:

POWERLEVEL9K_LEFT_PROMPT_ELEMENTS=(user dir vcs newline)

POWERLEVEL9K_RIGHT_PROMPT_ELEMENTS

显示在命令行右边区域的元素:

和上图相对应的配置为:

POWERLEVEL9K_RIGHT_PROMPT_ELEMENTS=(time)

可以在 POWERLEVEL9K_LEFT_PROMPT_ELEMENTSPOWERLEVEL9K_RIGHT_PROMPT_ELEMENTS 里用的字段有:

字段含义
user用户名
dir当前目录名
vcs远程仓库信息
os_icon系统图标
date日期
host主机名
status上一条命令的执行状态
time当前时间
......

如果还想了解更多,自行前往文档查看。

POWERLEVEL9K_VCS_GIT_GITHUB_ICON

如果它是一个 Github 目录,就会显示这个图标:

所以出现在窗口里的图标都可以自定义,可以通过命令查看目前正在使用的图标:

get_icon_names

找到想要修改的 KEY 就可以修改图标了。

注意:需要使用 Nerd Fonts 才能收获这满满的快乐。

有人问,这个图标的代码该去哪找呢?

在这里:https://www.nerdfonts.com/cheat-sheet

这是 Nerd Fonts 能够支持的所有图标,可以直接使用关键字进行搜索。

比如,我想修改 Git 的图标:

找到喜欢的图标之后,右下角的 f113 就是这个图标的值,只需要这样就了:

POWERLEVEL9K_VCS_GIT_GITHUB_ICON=$'\uf113'

快造作起来~

插件

到了这一步,你的 iTerm2 应该已经颜值爆表,足够好看了。

毕竟这是我们的饭碗,光好看不行,得好用,来了解一下强大的插件体系。

首先,我们先了解一下插件在 ~/.zshrc 的哪个位置,找到下面这个字段就不会错了:

plugins=(git)

git

git 插件是自带插件,默认已经开启,它可以让我们使用非常好用的的 git 命令,提高开发效率:

用了插件之前的 git 命令用了插件之后的 git 命令
git add --allgaa
git branch -DgbD
git commit -a -mgcam
git checkout -bgcb
git checkout mastergcm

是不是简单多了。可以通过命令查看所有配置:

vim ~/.oh-my-zsh/plugins/git/git.plugin.zsh

自动跳转对应目录

如果你像我一样是一个整理狂魔,会把文件、目录一层一层的整理好。

整理一时爽,用时就不爽

目录层级深了,年龄大了,就找不到文件放哪了,cd 起来也不方便了,有什么办法可以解决呢?教你两招。

设置别名 alias

打开 ~/.zshrc 输入别名,比如:

alias articles='~/Code/GitHub/articles'

然后执行 articles 就会自动跳到 ~/Code/GitHub/articles 了。

这样还是比较麻烦的,得为每个目录都配置 alias

autojump 插件

autojump 插件会记录你所有的访问记录,不同单独配置,直接访问即可。

安装
brew install autojump
配置

打开 ~/.zshrc 加一行代码:

[[ -s $(brew --prefix)/etc/profile.d/autojump.sh ]] && . $(brew --prefix)/etc/profile.d/autojump.sh

然后就是 source 一下就生效了。

使用

使用 j 命令就可以执行 auto-jump,比如 j articles

前提是你访问过 articles 目录,也就是你得让它记住。

zsh-autosuggestions

这个插件的作用很简单,就是像它名字一样,会在你输入命令的时候提示并且自动完成:

brew install zsh-autosuggestions

colors

这是一个文件目录美化插件,如图所示:

gem install colorls

然后执行 colors 就好了,你也可以设置 alias 更高效一点:

alias lc='colorls -lA --sd'

设置了别名之后,就像我一样,输入 lc 就好了。

我就只用了以上几个插件,已经能够大幅度提升工作效率了,如果有其它好用的插件,一定要告诉我呀。

VS Code 配置

如果你用的是 VS Code,需要再配置一下字体:

{
  "terminal.integrated.fontFamily": "Hack Nerd Font"
}

homebrew 安装

上面的几个插件都用的是 brew 命令安装,应该不在少数的人刚开始电脑上是没有 brew 的:

brew: command not found

然后就百度了一下,说要装一个叫 Homebrew 的东西,然后就按照官网的方式执行安装:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"

如果安装成功了,恭喜你,你的运气真的很好。如果没安装成功,那你一定会各种百度如何安装,然后还是安装不成功:

curl: (7) Failed to connect to raw.githubusercontent.com port 443: Connection refused

有人告诉你,换一个中科大的源试试:

/usr/bin/ruby -e "$(curl -fsSL https://cdn.jsdelivr.net/gh/ineo6/homebrew-install/install)"

然后,你可能会卡在这:

==> Tapping homebrew/core
Cloning into '/usr/local/Homebrew/Library/Taps/homebrew/homebrew-core'...

也就是因为不可描述的原因,下载 homebrew-core 这个库的时候网络不行了,那我们就手动 clone 一个吧,或者下载一个 zip 包解压到对应目录:

cd "$(brew --repo)/Library/Taps/"
mkdir homebrew && cd homebrew
git clone git://mirrors.ustc.edu.cn/homebrew-core.git

然后再执行上面的命令安装就好了:

/usr/bin/ruby -e "$(curl -fsSL https://cdn.jsdelivr.net/gh/ineo6/homebrew-install/install)"

会看到成功安装的提示:

==> Installation successful!

写在最后

就问你这样一套终端开发环境骚不骚好不好用。不说别的,看着这背景,写代码都更有动力了。

交流讨论

欢迎关注公众号「前端试炼」,公众号平时会分享一些实用或者有意思的东西,发现代码之美。专注深度和最佳实践,希望打造一个高质量的公众号。

查看原文

赞 12 收藏 11 评论 2

耗砸 收藏了文章 · 6月15日

这篇 iTerm2 + Oh My Zsh 教程手把手让你成为这条街最靓的仔

前言

作为一名程序员,开发环境不舒服会很大程度影响开发效率,所以一定要花时间好好整一下开发环境(好了,我知道你是在给摸鱼找借口)。

最近短短几个月,换了两次新电脑,经历了两次装机(由于各种原因,没法备份恢复,你懂的),每一次都得重新搞一套属于自己的开发环境。

这里就记录一下我是如何一步一步的打造属于自己的 TerminalmacOS 上的 Terminal 是怎么样的,你如果想和我一样,直接 cv 大法 就可以搞一套一样的。

文中的链接在微信里无法打开,如果有需要可以点击阅读全文跳转到掘金的文章里。

Terminal

Terminal 我们经常会称作 终端,现在中文版的 mac 里也是叫做这个。

我们每天都需要在其中输入很多命令去做一些事情。可以说,每天有大量的时间都需要面对它。

我记得我第一次点下鼠标,打开这个终端的时候,看到了这样一个界面:

我傻了。怎么这么丑?macOS 上怎么允许有这么丑的应用?

不行,如果让我每天对着它,一定会把电脑砸了(虽然它是高贵的 16寸 MacBook Pro),我得找一个第三方 Terminal 来替代它。

iTerm2

很快,我就找到了新欢,它的名字叫 iTerm2,它是一款完全免费,为 macOS 打造的一款终端工具,可以说是程序员必备了,如果还没用过的,赶紧跟着这篇文章用起来吧。

iTerm2 官网 符合国外网站一向的极简风格(又不是不能用,搞那么花里胡哨干嘛)。

直接下载,解压,拖入 Application 里就 ok 了。打开看看。

怎么感觉不太对,虽然你的背景变黑了,但依然掩盖不了你的丑啊。

没事儿,先天不足,后天努力嘛。

告别黑底白字,整出最骚终端,开始吧。

on my zsh

主角是它,拥有了它,你一定是你们组最靓的仔。

Oh My Zsh is an open source, community-driven framework for managing your zsh configuration.

安装

官网提供了两种安装方式:

# via curl
sh -c "$(curl -fsSL https://raw.github.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

# via wget
sh -c "$(wget -O- https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

如果,由于一些原因,上面两种方法你都没能安装成功,可以试一下手动安装:

# 下载 oh-my-zsh 源码
git clone git://github.com/robbyrussell/oh-my-zsh.git ~/.oh-my-zsh
# 并且把 .zshrc 配置文件拷贝到根目录下
cp ~/.oh-my-zsh/templates/zshrc.zsh-template ~/.zshrc
# 让 .zshrc 配置文件生效
source ~/.zshrc

嗯... 你和我说,clone 也不行啊,不可描述的原因,网速不允许啊。

那你这样做。

oh-my-zsh GitHub 上下载 zip -> 解压 -> 移动 oh-my-zsh 目录到根目录:

cd ~/Downloads
mv ohmyzsh-master ~/.oh-my-zsh
cp ~/.oh-my-zsh/templates/zshrc.zsh-template ~/.zshrc
source ~/.zshrc

如果还不行,你来找我。

好了,重新启动 iTerm2,是不是已经变了。

.zshrc

这个文件非常关键,是 oh-my-zsh 的配置文件,它的位置在根目录下,可以通过 vim ~/.zshrc 查看。

每一次修改它之后,如果想要立即生效需要手动执行 source ~/.zshrc

修改配色方案

一打开 .zshrc,就可以看到关于配色方案的配置:

# Set name of the theme to load --- if set to "random", it will
# load a random theme each time oh-my-zsh is loaded, in which case,
# to know which specific one was loaded, run: echo $RANDOM_THEME
# See https://github.com/ohmyzsh/ohmyzsh/wiki/Themes
ZSH_THEME="agnoster"

oh-my-zsh 提供了很多内置的配色方案,可以通过命令来查看:

ls ~/.oh-my-zsh/themes

也可以打开 https://github.com/ohmyzsh/ohmyzsh/wiki/Themes 更为直观的查看所有的配色方案。

只要修改 ZSH_THEME 的值就可以设置对应的配色方案了。

如果你想每天都过得不一样,可以设置成 random,每次打开 iTerm2 的都会随机使用一种配色方案。

我曾经有一段时间,由于不想折腾,使用的是这个配色方案:agnoster,它是这样的:

当然,有一天,我突然想造作一下,就开始自己配色。(没备份... 找不着了...)

如果你觉得默认的配色方案不够骚,并且觉得自己的审美 ok,也可以自己来搭配颜色。

自定义配色方案

入口:菜单栏 -> Profiles -> Open Profiles -> Edit Profiles -> + 一个配置 -> 选择 Colors

像我这样审美不行的人,花了一整天的时间搞这个,到头来发现,还是默认的更好看一点...

⚠️ 别摸一下午鱼搞这个被老板发现,还是下班了再搞吧。

第三方配色方案

当然,不是只有你和我想要自己搞一套最骚的配色方案,大家都有这样的想法。

iTerm2-Color-Schemes 这里有非常多的配色方案题,也已经在 GitHub 上开源。

你可以像我一样这样做:

# 找一个目录存放 iterm2 相关的文件
mkdir Code/other/iterm2
# 下载 iTerm2-Color-Schemes
git clone https://github.com/mbadolato/iTerm2-Color-Schemes
# schemes 文件夹就是真实存放配色方案的目录
cd iTerm2-Color-Schemes/schemes

同样,如果 clone 不下来就下载 zip 解压就好了。

通过以下操作路径可以导入所有配色方案:

菜单栏 -> Profiles -> Open Profiles -> Edit Profiles -> 选择 Colors -> 右下角 Color Presets -> Import...

找到 schemes 文件夹选中所有配色方案就好了,然后你就 眼花缭乱 会收获满满的幸福。

没事,等等会有更高级的方案。

安装字体 PowerFonts

为什么要安装字体呢?有些主题是会设置图标的,我们电脑上的字体一般都不支持这些图标,会出现乱码。

打开 Fonts 下载 zip 包都本地解压,就会得到很多字体。

# 将下载好的 fonts 移动到之前建的目录
mv ~/Downlaods/fonts-master ~/Code/other/iterm2/fonts
cd ~/Code/other/iterm2/fonts
# 执行安装文件
./install.sh

这样就安装好了,然后通过以下操作路径设置字体:

菜单栏 -> Profiles -> Open Profiles -> Edit Profiles -> 选择 Text

可以选择 Meslo 这个字体,乱码的图标就正常了。

毛玻璃效果/窗口大小

如果想要更高逼格的毛玻璃效果,并且找到自己舒服的大小(???),可以在这里设置:

操作路径:菜单栏 -> Profiles -> Open Profiles -> Edit Profiles -> 选择 Window

自定义背景

激动人心的时刻,你可以为你的终端设置一个自己喜欢的 小姐姐 图片作为背景,敲命令的时候都会更带劲吧:

咳咳,Dota 云玩家们,你是更喜欢冰女还是火女?

操作路径:菜单栏 -> Profiles -> Open Profiles -> Edit Profiles -> 选择 Window

状态栏

可以为每个打开的终端都设置一个状态栏,显示一些系统信息(比如 CPU、RAM、当前目录等)。

操作路径:菜单栏 -> Profiles -> Open Profiles -> Edit Profiles -> 选择 Session

总结

经过这一番折腾,一个属于你自己的高颜值终端就诞生了。

不过,总感觉这样还是有点麻烦,有没有更厉害的玩意儿?有的,我们这就用起来。

神器 Powerlevel10k

Powerlevel10k 简单来说就是一个 ZSH 的主题,只不过它的功能很强大,以下简称 p10k

安装

我们用的是 Oh My Zsh,所以这样安装 p10k 即可:

git clone --depth=1 https://github.com/romkatv/powerlevel10k.git ${ZSH_CUSTOM:-~/.oh-my-zsh/custom}/themes/powerlevel10k

然后需要打开 ~/.zshrc 设置 ZSH_THEME:

ZSH_THEME="powerlevel10k/powerlevel10k

安装字体 Nerd Fonts

上文我们已经安装了 PowerFonts,如果需要使用一些图标,这个字体是不够用的,我们需要一个强大的字体:Nerd Fonts,它支持下面这么多种图标:

安装

你可以如官网所说,通过 brew 来安装:

brew tap homebrew/cask-fonts
brew cask install font-hack-nerd-font

但是我不建议这样,包括不建议你下载 zip 包,因为这个文件太大了,太大了,太大了。。。

我们可以这样:

打开 https://github.com/ryanoasis/nerd-fonts/releases,滑动页面找到 Assets 区域,如图:

我们只要下载箭头所指的 Hack.zip 这个字体包,解压缩之后就会获得一些 ttf 字体文件,双击安装即可。

zshrc 设置字体

POWERLEVEL9K_MODE="nerdfont-complete"
ZSH_THEME="powerlevel10k/powerlevel10k"

注意,需要设置在 ZSH_THEME 之前。

iTerm2 设置字体

操作路径:菜单栏 -> Profiles -> Open Profiles -> Edit Profiles -> 选择 Text

这样,所有的图标就都可以正常显示了。

自动配置

如果你指定了 ZSH_THEME="powerlevel10k/powerlevel10k" 但是在 zshrc 里没进行任何手动的配置,打开 iTerm2 的时候就会触发自动配置的流程。

也可以通过以下命令再次进入自动配置的流程:

p10k configure

问题大致如下:

  1. 这个符号看起来像钻石(旋转的正方形)吗?
  2. 这个符号看起来像锁吗?
  3. 这个符号看起来像 Debian logo 吗?
  4. 这些图标都交叉分布在 X 之间吗?
  5. 风格
  6. 编码
  7. 是否显示时间
  8. 目录层级分隔符
  9. 头部(左边)
  10. 尾部(右边)
  11. 是否换行
  12. 左边和右边是否有连接线
  13. 命令行和提示是否连接
  14. 两行命令之间分布稀疏还是松散
  15. 是否需要图标

后面几个选项随意,执行完命令之后,就会初始化 p10k:在根目录下生成 ~/.p10k.zsh,并且在 ~/.zshrc 底部写入:

如果想废除 p10k 的配置,只需要删除 ~/.p10k.zsh,并且删除上面这条命令即可。

自定义配置

如果你想当高玩,也可以在 ~/.zshrc 里手动配置 p10k,或者在 ~/.p10k.zsh 基础上进行修改。

这个得要自己看文档摸索啦,这里我简单说几个配置:

  • POWERLEVEL9K_LEFT_PROMPT_ELEMENTS
  • POWERLEVEL9K_RIGHT_PROMPT_ELEMENTS
  • POWERLEVEL9K_VCS_GIT_GITHUB_ICON

POWERLEVEL9K_LEFT_PROMPT_ELEMENTS

显示在命令行左边区域的元素:

和上图相对应的配置为:

POWERLEVEL9K_LEFT_PROMPT_ELEMENTS=(user dir vcs newline)

POWERLEVEL9K_RIGHT_PROMPT_ELEMENTS

显示在命令行右边区域的元素:

和上图相对应的配置为:

POWERLEVEL9K_RIGHT_PROMPT_ELEMENTS=(time)

可以在 POWERLEVEL9K_LEFT_PROMPT_ELEMENTSPOWERLEVEL9K_RIGHT_PROMPT_ELEMENTS 里用的字段有:

字段含义
user用户名
dir当前目录名
vcs远程仓库信息
os_icon系统图标
date日期
host主机名
status上一条命令的执行状态
time当前时间
......

如果还想了解更多,自行前往文档查看。

POWERLEVEL9K_VCS_GIT_GITHUB_ICON

如果它是一个 Github 目录,就会显示这个图标:

所以出现在窗口里的图标都可以自定义,可以通过命令查看目前正在使用的图标:

get_icon_names

找到想要修改的 KEY 就可以修改图标了。

注意:需要使用 Nerd Fonts 才能收获这满满的快乐。

有人问,这个图标的代码该去哪找呢?

在这里:https://www.nerdfonts.com/cheat-sheet

这是 Nerd Fonts 能够支持的所有图标,可以直接使用关键字进行搜索。

比如,我想修改 Git 的图标:

找到喜欢的图标之后,右下角的 f113 就是这个图标的值,只需要这样就了:

POWERLEVEL9K_VCS_GIT_GITHUB_ICON=$'\uf113'

快造作起来~

插件

到了这一步,你的 iTerm2 应该已经颜值爆表,足够好看了。

毕竟这是我们的饭碗,光好看不行,得好用,来了解一下强大的插件体系。

首先,我们先了解一下插件在 ~/.zshrc 的哪个位置,找到下面这个字段就不会错了:

plugins=(git)

git

git 插件是自带插件,默认已经开启,它可以让我们使用非常好用的的 git 命令,提高开发效率:

用了插件之前的 git 命令用了插件之后的 git 命令
git add --allgaa
git branch -DgbD
git commit -a -mgcam
git checkout -bgcb
git checkout mastergcm

是不是简单多了。可以通过命令查看所有配置:

vim ~/.oh-my-zsh/plugins/git/git.plugin.zsh

自动跳转对应目录

如果你像我一样是一个整理狂魔,会把文件、目录一层一层的整理好。

整理一时爽,用时就不爽

目录层级深了,年龄大了,就找不到文件放哪了,cd 起来也不方便了,有什么办法可以解决呢?教你两招。

设置别名 alias

打开 ~/.zshrc 输入别名,比如:

alias articles='~/Code/GitHub/articles'

然后执行 articles 就会自动跳到 ~/Code/GitHub/articles 了。

这样还是比较麻烦的,得为每个目录都配置 alias

autojump 插件

autojump 插件会记录你所有的访问记录,不同单独配置,直接访问即可。

安装
brew install autojump
配置

打开 ~/.zshrc 加一行代码:

[[ -s $(brew --prefix)/etc/profile.d/autojump.sh ]] && . $(brew --prefix)/etc/profile.d/autojump.sh

然后就是 source 一下就生效了。

使用

使用 j 命令就可以执行 auto-jump,比如 j articles

前提是你访问过 articles 目录,也就是你得让它记住。

zsh-autosuggestions

这个插件的作用很简单,就是像它名字一样,会在你输入命令的时候提示并且自动完成:

brew install zsh-autosuggestions

colors

这是一个文件目录美化插件,如图所示:

gem install colorls

然后执行 colors 就好了,你也可以设置 alias 更高效一点:

alias lc='colorls -lA --sd'

设置了别名之后,就像我一样,输入 lc 就好了。

我就只用了以上几个插件,已经能够大幅度提升工作效率了,如果有其它好用的插件,一定要告诉我呀。

VS Code 配置

如果你用的是 VS Code,需要再配置一下字体:

{
  "terminal.integrated.fontFamily": "Hack Nerd Font"
}

homebrew 安装

上面的几个插件都用的是 brew 命令安装,应该不在少数的人刚开始电脑上是没有 brew 的:

brew: command not found

然后就百度了一下,说要装一个叫 Homebrew 的东西,然后就按照官网的方式执行安装:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install.sh)"

如果安装成功了,恭喜你,你的运气真的很好。如果没安装成功,那你一定会各种百度如何安装,然后还是安装不成功:

curl: (7) Failed to connect to raw.githubusercontent.com port 443: Connection refused

有人告诉你,换一个中科大的源试试:

/usr/bin/ruby -e "$(curl -fsSL https://cdn.jsdelivr.net/gh/ineo6/homebrew-install/install)"

然后,你可能会卡在这:

==> Tapping homebrew/core
Cloning into '/usr/local/Homebrew/Library/Taps/homebrew/homebrew-core'...

也就是因为不可描述的原因,下载 homebrew-core 这个库的时候网络不行了,那我们就手动 clone 一个吧,或者下载一个 zip 包解压到对应目录:

cd "$(brew --repo)/Library/Taps/"
mkdir homebrew && cd homebrew
git clone git://mirrors.ustc.edu.cn/homebrew-core.git

然后再执行上面的命令安装就好了:

/usr/bin/ruby -e "$(curl -fsSL https://cdn.jsdelivr.net/gh/ineo6/homebrew-install/install)"

会看到成功安装的提示:

==> Installation successful!

写在最后

就问你这样一套终端开发环境骚不骚好不好用。不说别的,看着这背景,写代码都更有动力了。

交流讨论

欢迎关注公众号「前端试炼」,公众号平时会分享一些实用或者有意思的东西,发现代码之美。专注深度和最佳实践,希望打造一个高质量的公众号。

查看原文

耗砸 收藏了文章 · 2019-11-24

Git仓库代码以及提交记录迁移

背景需求

项目的后台是用Node开发,仓库迁移需求如下:
1、代码以及提交记录迁移至新仓库。
2、生产服务器上的项目远程仓库更换为新仓库,无需重新部署。

1、代码以及迁移

首先我们先建好一个新的远程仓库,之后我们需要把代码和commit记录都提交到这个仓库上了。

# 本地创建新项目
$ mkdir new-project

# 克隆旧仓库代码
git clone git@old_repository.git

# 远端仓库重新命名
git remote rename origin old-origin

# 添加新的远程仓库
git remote add origin git@new_repository.git

# 推送代码以、提交记录、标签到新仓库,并指定origin(新仓库)为默认主机
# --all: 推送所有分支
# --tags: 推送所有本地新增的标签;默认情况下,git push并不会把标签传送到远端服务器上
git push -u origin --all
git push -u origin --tags

2、服务器更换远程仓库地址

# 重设远程仓库地址
git remote set-url origin git@new_repository.git

# 查看当前远程仓库地址
git remote -v
查看原文

耗砸 收藏了文章 · 2019-11-05

1024 巨献!!一文看尽过去一年前端领域的那些好文(700 篇大汇总)

1024,在这个“程序猿” 和 “程序媛” 特有的节日,我们为您送出一份节日大礼包 —— 过去一年政采云 ZooTeam 前端小报推荐过的 700 篇好文,篇篇人肉筛选推荐,一文看尽一年的精华沉淀,强烈建议收藏~!

由于字数限制,想要查看全部 700 篇好文,请戳这里:1024 巨献!!一文看尽过去一年前端领域的那些好文(700 篇大汇总)

表现

行为

服务端

性能体验

React 相关

Vue 相关

工具相关

方案汇总

浏览器

多终端

安全相关

HTTP 相关

职业感悟

ZooTeam_QRCode_Search.png

查看原文

耗砸 关注了用户 · 2019-11-05

SegmentFault @segmentfault

SegmentFault 社区管理媛 - 思否小姐姐

纯粹的技术社区离不开所有开发者的支持和努力 biubiu

更多技术内容与动态欢迎关注 @SegmentFault 官方微博与微信公众号!

点击添加思否小姐姐个人微信号

关注 83843

耗砸 收藏了文章 · 2019-11-05

2019 年,React 开发人员应该掌握的 22 种神奇工具

本文经 Jsmanifest 授权 LeanCloud 翻译转载,原文链接

众所周知,React 是 JavaScript 库,用于构建出色的用户界面。但是,并不是每个人都在使用相同的工具或都知道所有有用的工具,这些工具有助于使 React 开发体验更有趣,更主动。

如果大家还没使用 React ,或者你有对它感兴趣的朋友,当他们问你为什么选择这个库的时候,你该怎么回答呢?除了告诉他们这个库有多棒以外(这应该是首先要说的事),我还想提一下,这些由开源社区创建的工具有助于把开发体验带到一个全新的令人兴奋的水平。

以下是 2019 年大家可以用来构建 React 应用程序的 22 个工具(该列表没有按它们的重要性排序)。

1. webpack-bundle-analyzer

大家有没有想过自己的应用程序哪些包或哪部分占用了全部空间?好了,我们可以用 webpack-bundle-analyzer 来查看,它将帮助我们识别出占用最多空间的输出文件。

它将创建一个实时服务器,并向我们提供捆绑包内容的交互式可视化树状图。借助此工具包,我们可以查看所显示文件的位置,它们的 gzip 大小,解析后的大小及其所属的父子级文件。

有什么好处?我们可以根据看到的图示来优化我们的 React 应用!

这是它的屏幕截图:

图一

我们可以清楚地看到 pdf 软件包在应用程序中占据了最大的空间。它还占据了最大屏幕,这对我们都很有用。

不过,屏幕截图质量非常小。我们还可以输入有用的选项以查看更多详细信息,如 generateStatsFile: true, 并且可以选择生成静态 HTML 文件,保存在开发环境之外的某个地方,以备后用。

2. React-Proto

React-Proto 是面向开发人员和设计人员的原型制作工具。这是一个桌面软件,所以在使用之前,我们需要下载安装该软件。

以下是工具页面样式:

图二

该应用程序允许我们声明属性及其类型,在树状图中查看组件,导入背景图像,将其定义为有状态或无状态,定义其父组件,放大/缩小,以及将原型导出到一个新的或已有的项目中。

该应用程序似乎更适合 Mac 用户,不过,它也支持 Windows。

当我们完成用户界面映射后,可以选择导出到现有项目或新项目中。如果选择导出到现有项目并选择了根目录,它们将被导出到 ./src/components,如下所示:

图三

以下是在示例中我们使用组件之一的例子:

图四

React-Proto 在 GitHub 上获得了 2,000 个星标。

不过,我认为这个应用程序还需要更新,并且还有很多需要做的工作,尤其是 React Hooks 的发布。

除非我们有一张可见的背景图片,不然就不能缩小。换句话说,如果导入一张背景图片,缩小,然后删除这张图片后,图就无法放大了,因为操作按钮已经变灰色,不可使用了。

放大的唯一方法是重新导入背景图片,放大后将其删除。这个缺陷改变了我对这个工具产生的好感,但因为在其他地方看不到此开源文件,所以把它加入了列表中。当然,成为开源软件对这个应用程序来说是件好事,因为这使它有可能成为未来流行的开源存储库列表。

3. Why Did You Render

Why Did You Render 猴子补丁 React 通知我们可以避免重渲染。这不仅非常有用,还可以指导我们对项目进行性能修复,帮助我们了解 React 工作的方式。而且,当我们对 React 工作原理有更多的了解时,也能让我们成为更好的 React 开发人员。

猴子补丁: 这个叫法起源于 Zope 框架,大家在修正 Zope 的 Bug 的时候经常在程序后面追加更新部分,这些被称作是“杂牌军补丁(guerilla patch)”,后来 guerilla 就渐渐的写成了 gorllia(猩猩),再后来就写了monkey(猴子),所以猴子补丁的叫法是这么莫名其妙的得来的。

我们可以通过声明一个额外的静态属性 whyDidYouRender,并将其值设置为 true,把一个侦听器附加到任意自定义组件:

import React from 'react'
import Button from '@material-ui/core/Button'

const Child = (props) => <div {...props} />

const Child2 = ({ children, ...props }) => (
  <div {...props}>
    {children} <Child />
  </div>
)

Child2.whyDidYouRender = true

const App = () => {
  const [state, setState] = React.useState({})

  return (
    <div>
      <Child>{JSON.stringify(state, null, 2)}</Child>
      <div>
        <Button type="button" onClick={() => setState({ hello: 'hi' })}>
          Submit
        </Button>
      </div>
      <Child2>Child #2</Child2>
    </div>
  )
}

export default App

只有这样做之后,我们的控制台才会弹出令人难以置信的烦人警报:

但别误会,请把它当成一件好事。利用那些烦人的消息,我们就可以修复那些浪费的重渲染。

4. Create React App

大家都知道 Create React App 是启动开发 React 项目最快的方法(拥有开箱即用的现代功能)。

还有什么能比 npx create-react-app <name> 更简单的呢?

我在 Medium 上的教程(以及 Dev.to)都是用 create-react-app 构建 React 接口界面的,就因为它又快又简单。

我们当中有些人可能不知道如何用 CRA 来创建一个 TypeScript 项目。我们要做的就是在末尾加上 --typescript

npx create-react-app <name> --typescript

这会帮我们省去给 CRA 项目手工添加 TypeScript 的麻烦。

5. React-Lifecycle-Visualizer

React-Lifecycle-Visualizer 是一个 npm 软件包,用于跟踪和可视化任意 React 组件的生命周期方法。

与 Why Did You Render 相似,我们可以选择任何组件来启动生命周期可视化工具:

import React from 'react'
import {
  Log,
  VisualizerProvider,
  traceLifecycle,
} from 'react-lifecycle-visualizer'

class TracedComponent extends React.Component {
  state = {
    loaded: false,
  }

  componentDidMount() {
    this.props.onMount()
  }

  render() {
    return <h2>Traced Component</h2>
  }
}

const EnhancedTracedComponent = traceLifecycle(TracedComponent)

const App = () => (
  <VisualizerProvider>
    <EnhancedTracedComponent />
    <Log />
  </VisualizerProvider>
)

运行结果,如下所示:

但是,其中一个缺点是它目前仅适用于类组件,因此尚不支持 Hook 。

6. Guppy

Guppy 是 React 的一个友好且免费的应用程序管理器和任务运行器,可以在桌面上运行且支持跨平台,大家可以放心使用。

它提供了很多友好的图形界面,为 React 开发人员的一些典型任务项目提供支持。例如创建新项目,执行任务和管理依赖项。并在 2018 年 8 月添加支持 Windows,因此可以放心,它肯定是跨平台的。

以下是 Guppy 使用时的样子:

7. react-testing-library

我一直很喜欢 react-testing-library,因为在编写单元测试时感觉不错。这个包提供了实用的 DOM 测试程序,鼓励良好的测试实践。

此解决方案旨在解决测试实施细节的问题,就像用户可以看到它们一样,而不是测试 React 组件的输入/输出。

测试实施细节并不是确保应用按预期运行的有效方法。当然,我们能够更清楚的了解如何获取组件所需的数据,使用哪种排序方法等。但是,如果我们必须更改实现方式以指向另一个数据库的话,单元测试就会失败,因为这些是耦合逻辑的实现细节。

这是 react-testing-library 解决的一个问题,因为理想情况下,我们只希望我们的用户界面能够正常工作并最终正确显示。只要这些组件能够提供预期的输出,数据如何获取到这些组件实际上并不重要。

以下是使用此库进行测试的示例代码

// Hoist helper functions (but not vars) to reuse between test cases
const renderComponent = ({ count }) =>
  render(
    <StateMock state={{ count }}>
      <StatefulCounter />
    </StateMock>,
  )

it('renders initial count', async () => {
  // Render new instance in every test to prevent leaking state
  const { getByText } = renderComponent({ count: 5 })

  await waitForElement(() => getByText(/clicked 5 times/i))
})

it('increments count', async () => {
  // Render new instance in every test to prevent leaking state
  const { getByText } = renderComponent({ count: 5 })

  fireEvent.click(getByText('+1'))
  await waitForElement(() => getByText(/clicked 6 times/i))
})

8. React Developer Tools

React Developer Tools 是一个扩展插件,它允许在 Chrome 和 Firefox 开发人员工具中查看 React 组件层次结构。

这是 React 开发中最常见的扩展插件,并且是 React 开发人员用来调试其应用程序的最有用的工具之一。

9. Bit

在使用诸如 material-ui 或 semantic-ui-react 之类的组件库时,Bit 是一个很好的替代方案。它可以让我们探索数千个开源组件,并使用它们来构建项目。

有很多不同的 React 组件,可供任何人使用,包括选项卡、按钮、图表、表格、导航条、下拉菜单、加载旋转器、日期选择器、面包屑导航(breadcrumbs)、图标、布局等等。

这些是由其他 React 开发人员上传的,这些开发人员就跟你我一样。

但是,也有一些可用的实用程序,如格式化日期之间的距离。

10. Storybook

如果大家还不了解 Storybook,并且希望能够轻松地构建 UI 组件,我强烈建议你立即使用它。该工具启动了支持热重载的实时开发服务器,让我们可以在其中独立地实时开发 React 组件。

另一个很棒的事情是,我们可以使用现有的开源插件,将我们的开发经验提升到一个全新的水平。例如,利用 Storybook README 包,我们可以在同一页面上创建 README 文档,同时开发供生产使用的 React 组件。这足以作为常规文档页面了:

11. React Sight

大家有没有想过自己的应用程序在流程图中看起来是什么样的?React -sight 可以让整个应用程序以树状图的形式展示层次结构,清楚查看我们的 React 应用程序。它还支持 React Router,Redux 和 React Fibre。

使用此工具,我们可以将鼠标悬停在节点上,这些节点是指向树中与它们直接相关的组件的链接。

如果大家在查看结果时遇到问题,可以在地址栏上输入 chrome:extensions,找到 React Sight
框并单击 Allow access to file URLs 开关,如下所示:

12. React-cosmos

React-cosmos 是用于创建可重复使用 React 组件的开发工具。

它会扫描项目中的组件,并且可以实现以下功能:

  • 用属性、上下文和状态的任意组合下渲染组件
  • 模拟每个外部依赖项(例如 API 响应、localStorage 等)
  • 与正在运行的实例进行交互时,查看应用程序状态的实时变化

13. CodeSandbox

这是本次推荐中最好的可用工具之一,它可以让我们手动使用 React 的速度比眨眼还快(好吧,也许也没那么快)。

这个称为 CodeSandbox的工具是一个在线编辑器,我们从创建原型到 Web 应用程序部署 - 都可以在这个网站实现!

在早期,Codesandbox 仅支持 React,但现在已经扩展到 Vue 和 Angular 等库。他们还支持常见的静态站点生成器(如 gatsby 或 nextjs )创建项目来启动下一个 React Web 项目。

关于 codesandbox,它不仅活跃,还有很多有意思的事情可以讨论。

如果大家需要探索一下人们为方便大家起见正在构建的一些项目,那么单击 explore 就可以轻松访问到大量代码示例,来帮助大家更新下一个项目:

图十一

大家一旦开始编辑项目,就会意识到,实际上要使用的是个功能强大的 VSCode 编辑器。

我很想写一篇完整的文章,介绍我们今天在 codeandbox 上可以使用的所有功能,不过,现在看起来工作已经完成了。

14. React bits

React bits 是 React 模式、技术、技巧和窍门的集合,所有这些都以类似在线文档的格式编写,大家可以在同一个选项卡上快速访问不同的设计模式和技术、反模式、样式、UX 变体以及其他有用的与 React 相关的材料。

他们有一个 GitHub 存储库,目前有 10437 星。

一些示例包括诸如道具代理,在不同场景下处理各种 UX 的组合之类的概念,甚至还提示了每个开发人员应该避免的一些陷阱。

这是他们页面上的样子,如大家在左侧的菜单上看到的那样,有很多信息:)

15. Folderize

Folderize 是一个 VSCode 扩展。它可以让我们将组件文件转换为组件文件夹结构。转换后的 React 组件仍将是一个组件,只是现在已转换为一个目录。

例如,假设我们正在创建一个 React 组件,它把文件作为属性以显示有用的信息,比如它们的元数据。元数据组件的逻辑占用了很多行,因此我们决定将其拆分为一个单独的文件。但是,当我们决定这样做时,我们就有了两个相互关联的文件。

因此,如果我们的目录如下所示:

图十三

我们可能想把 FileView.jsFileMetadata.js 抽象到目录结构中,像 Apples- 那样,特别是如果我们希望添加更多与文件相关的组件,比如 FileScanner.js 。这就是 folderize 可以为我们做的事情,这样它们就可以具有以下类似结构:

import React from 'react'
import FileView from './src/components/FileView'

const App = (props) => <FileView {...props} />

export default App

16. React Starter Projects

React Starter Projects 是一个很棒的依赖库列表,我们可以在一个页面中查看全部项目。因此,如果我们觉得能同时快速查看到大量选项是非常有用的,那么这个很适合我们。

一旦看到喜欢的入门项目后,我们就可以简单克隆存储库,根据开发中的应用需要进行简单修改。但是,并非所有的库都用来克隆存储库,因为其中一些库需要通过安装形式,才能成为项目的依赖项。这样可以更轻松地获取更新并保持项目整洁。

以下是该页面看起来的样子:

17. Highlight Updates

可以说,这是每个开发者工具包里都应该有的重要工具。Highlight Updates 是 React DevTools 的一项扩展功能,可以查看页面中的哪些组件正在不必要地重渲染。

它们会用橙色/红色标出严重的重渲染问题,帮助我们在开发页面时更容易的发现一些性能问题。

除非我们的目标是构建平庸的应用程序,否则为什么不试试这个在我们身边的好东西。

18. React Diff Viewer

React Diff Viewer 是使用 Diff 和 React 制作的简单美观的文本差异查看器。支持多种功能,如:分屏视图,内联视图,单词差异,行高亮显示等。

如果我们想将此功能嵌入记事本(如 Boostnote)和自定义至应用程序(比如主题颜色、故事演示文档组合等),那么,它将非常有用。

图

19. JS.coach

JS.coach 是我经常用来查找 React 相关材料的网站。我不知道为什么提到这个网站的人不多,但在这个页面我发现了几乎所有我需要的信息,它快捷、方便,并不断更新,总是能为我所有的项目提供所需的结果。

最近,他们添加了 React VR 选项卡,这真是太好了!

20. Awesome React

Awesome React 开源库是一个与 React 相关的并非常棒的列表。

这让我可能会忘记其他网站只从这个链接学习 React 。因为可以在此找到大量有用的资源,这些资源肯定会帮助我们构建出色的 React 应用程序!

21. Proton Native

Proton Native 为大家提供了一个 React 环境来构建跨平台的本机桌面应用程序。

它是 Electron 的替代产品,只有一些简洁的功能,包括:

  • 与 React Native 相同的语法
  • 适用于现存的 React 库,例如 Redux
  • 跨平台
  • 原生组件,不再有 Electron
  • 与所有正常的 Node.js 包兼容

有兴趣了解更多吗?请阅读他们的文档

22. Devhints React.js Cheatsheet

一个不错的 React 速查表,尽管它缺少 React Hooks。不用担心,我将为 Reactv16.8 + 创建速查表,请继续关注。

结论

以上就是本次分享的全部工具。

希望大家在这里找到了有价值的信息。

查看原文

耗砸 赞了文章 · 2019-11-05

2019 年,React 开发人员应该掌握的 22 种神奇工具

本文经 Jsmanifest 授权 LeanCloud 翻译转载,原文链接

众所周知,React 是 JavaScript 库,用于构建出色的用户界面。但是,并不是每个人都在使用相同的工具或都知道所有有用的工具,这些工具有助于使 React 开发体验更有趣,更主动。

如果大家还没使用 React ,或者你有对它感兴趣的朋友,当他们问你为什么选择这个库的时候,你该怎么回答呢?除了告诉他们这个库有多棒以外(这应该是首先要说的事),我还想提一下,这些由开源社区创建的工具有助于把开发体验带到一个全新的令人兴奋的水平。

以下是 2019 年大家可以用来构建 React 应用程序的 22 个工具(该列表没有按它们的重要性排序)。

1. webpack-bundle-analyzer

大家有没有想过自己的应用程序哪些包或哪部分占用了全部空间?好了,我们可以用 webpack-bundle-analyzer 来查看,它将帮助我们识别出占用最多空间的输出文件。

它将创建一个实时服务器,并向我们提供捆绑包内容的交互式可视化树状图。借助此工具包,我们可以查看所显示文件的位置,它们的 gzip 大小,解析后的大小及其所属的父子级文件。

有什么好处?我们可以根据看到的图示来优化我们的 React 应用!

这是它的屏幕截图:

图一

我们可以清楚地看到 pdf 软件包在应用程序中占据了最大的空间。它还占据了最大屏幕,这对我们都很有用。

不过,屏幕截图质量非常小。我们还可以输入有用的选项以查看更多详细信息,如 generateStatsFile: true, 并且可以选择生成静态 HTML 文件,保存在开发环境之外的某个地方,以备后用。

2. React-Proto

React-Proto 是面向开发人员和设计人员的原型制作工具。这是一个桌面软件,所以在使用之前,我们需要下载安装该软件。

以下是工具页面样式:

图二

该应用程序允许我们声明属性及其类型,在树状图中查看组件,导入背景图像,将其定义为有状态或无状态,定义其父组件,放大/缩小,以及将原型导出到一个新的或已有的项目中。

该应用程序似乎更适合 Mac 用户,不过,它也支持 Windows。

当我们完成用户界面映射后,可以选择导出到现有项目或新项目中。如果选择导出到现有项目并选择了根目录,它们将被导出到 ./src/components,如下所示:

图三

以下是在示例中我们使用组件之一的例子:

图四

React-Proto 在 GitHub 上获得了 2,000 个星标。

不过,我认为这个应用程序还需要更新,并且还有很多需要做的工作,尤其是 React Hooks 的发布。

除非我们有一张可见的背景图片,不然就不能缩小。换句话说,如果导入一张背景图片,缩小,然后删除这张图片后,图就无法放大了,因为操作按钮已经变灰色,不可使用了。

放大的唯一方法是重新导入背景图片,放大后将其删除。这个缺陷改变了我对这个工具产生的好感,但因为在其他地方看不到此开源文件,所以把它加入了列表中。当然,成为开源软件对这个应用程序来说是件好事,因为这使它有可能成为未来流行的开源存储库列表。

3. Why Did You Render

Why Did You Render 猴子补丁 React 通知我们可以避免重渲染。这不仅非常有用,还可以指导我们对项目进行性能修复,帮助我们了解 React 工作的方式。而且,当我们对 React 工作原理有更多的了解时,也能让我们成为更好的 React 开发人员。

猴子补丁: 这个叫法起源于 Zope 框架,大家在修正 Zope 的 Bug 的时候经常在程序后面追加更新部分,这些被称作是“杂牌军补丁(guerilla patch)”,后来 guerilla 就渐渐的写成了 gorllia(猩猩),再后来就写了monkey(猴子),所以猴子补丁的叫法是这么莫名其妙的得来的。

我们可以通过声明一个额外的静态属性 whyDidYouRender,并将其值设置为 true,把一个侦听器附加到任意自定义组件:

import React from 'react'
import Button from '@material-ui/core/Button'

const Child = (props) => <div {...props} />

const Child2 = ({ children, ...props }) => (
  <div {...props}>
    {children} <Child />
  </div>
)

Child2.whyDidYouRender = true

const App = () => {
  const [state, setState] = React.useState({})

  return (
    <div>
      <Child>{JSON.stringify(state, null, 2)}</Child>
      <div>
        <Button type="button" onClick={() => setState({ hello: 'hi' })}>
          Submit
        </Button>
      </div>
      <Child2>Child #2</Child2>
    </div>
  )
}

export default App

只有这样做之后,我们的控制台才会弹出令人难以置信的烦人警报:

但别误会,请把它当成一件好事。利用那些烦人的消息,我们就可以修复那些浪费的重渲染。

4. Create React App

大家都知道 Create React App 是启动开发 React 项目最快的方法(拥有开箱即用的现代功能)。

还有什么能比 npx create-react-app <name> 更简单的呢?

我在 Medium 上的教程(以及 Dev.to)都是用 create-react-app 构建 React 接口界面的,就因为它又快又简单。

我们当中有些人可能不知道如何用 CRA 来创建一个 TypeScript 项目。我们要做的就是在末尾加上 --typescript

npx create-react-app <name> --typescript

这会帮我们省去给 CRA 项目手工添加 TypeScript 的麻烦。

5. React-Lifecycle-Visualizer

React-Lifecycle-Visualizer 是一个 npm 软件包,用于跟踪和可视化任意 React 组件的生命周期方法。

与 Why Did You Render 相似,我们可以选择任何组件来启动生命周期可视化工具:

import React from 'react'
import {
  Log,
  VisualizerProvider,
  traceLifecycle,
} from 'react-lifecycle-visualizer'

class TracedComponent extends React.Component {
  state = {
    loaded: false,
  }

  componentDidMount() {
    this.props.onMount()
  }

  render() {
    return <h2>Traced Component</h2>
  }
}

const EnhancedTracedComponent = traceLifecycle(TracedComponent)

const App = () => (
  <VisualizerProvider>
    <EnhancedTracedComponent />
    <Log />
  </VisualizerProvider>
)

运行结果,如下所示:

但是,其中一个缺点是它目前仅适用于类组件,因此尚不支持 Hook 。

6. Guppy

Guppy 是 React 的一个友好且免费的应用程序管理器和任务运行器,可以在桌面上运行且支持跨平台,大家可以放心使用。

它提供了很多友好的图形界面,为 React 开发人员的一些典型任务项目提供支持。例如创建新项目,执行任务和管理依赖项。并在 2018 年 8 月添加支持 Windows,因此可以放心,它肯定是跨平台的。

以下是 Guppy 使用时的样子:

7. react-testing-library

我一直很喜欢 react-testing-library,因为在编写单元测试时感觉不错。这个包提供了实用的 DOM 测试程序,鼓励良好的测试实践。

此解决方案旨在解决测试实施细节的问题,就像用户可以看到它们一样,而不是测试 React 组件的输入/输出。

测试实施细节并不是确保应用按预期运行的有效方法。当然,我们能够更清楚的了解如何获取组件所需的数据,使用哪种排序方法等。但是,如果我们必须更改实现方式以指向另一个数据库的话,单元测试就会失败,因为这些是耦合逻辑的实现细节。

这是 react-testing-library 解决的一个问题,因为理想情况下,我们只希望我们的用户界面能够正常工作并最终正确显示。只要这些组件能够提供预期的输出,数据如何获取到这些组件实际上并不重要。

以下是使用此库进行测试的示例代码

// Hoist helper functions (but not vars) to reuse between test cases
const renderComponent = ({ count }) =>
  render(
    <StateMock state={{ count }}>
      <StatefulCounter />
    </StateMock>,
  )

it('renders initial count', async () => {
  // Render new instance in every test to prevent leaking state
  const { getByText } = renderComponent({ count: 5 })

  await waitForElement(() => getByText(/clicked 5 times/i))
})

it('increments count', async () => {
  // Render new instance in every test to prevent leaking state
  const { getByText } = renderComponent({ count: 5 })

  fireEvent.click(getByText('+1'))
  await waitForElement(() => getByText(/clicked 6 times/i))
})

8. React Developer Tools

React Developer Tools 是一个扩展插件,它允许在 Chrome 和 Firefox 开发人员工具中查看 React 组件层次结构。

这是 React 开发中最常见的扩展插件,并且是 React 开发人员用来调试其应用程序的最有用的工具之一。

9. Bit

在使用诸如 material-ui 或 semantic-ui-react 之类的组件库时,Bit 是一个很好的替代方案。它可以让我们探索数千个开源组件,并使用它们来构建项目。

有很多不同的 React 组件,可供任何人使用,包括选项卡、按钮、图表、表格、导航条、下拉菜单、加载旋转器、日期选择器、面包屑导航(breadcrumbs)、图标、布局等等。

这些是由其他 React 开发人员上传的,这些开发人员就跟你我一样。

但是,也有一些可用的实用程序,如格式化日期之间的距离。

10. Storybook

如果大家还不了解 Storybook,并且希望能够轻松地构建 UI 组件,我强烈建议你立即使用它。该工具启动了支持热重载的实时开发服务器,让我们可以在其中独立地实时开发 React 组件。

另一个很棒的事情是,我们可以使用现有的开源插件,将我们的开发经验提升到一个全新的水平。例如,利用 Storybook README 包,我们可以在同一页面上创建 README 文档,同时开发供生产使用的 React 组件。这足以作为常规文档页面了:

11. React Sight

大家有没有想过自己的应用程序在流程图中看起来是什么样的?React -sight 可以让整个应用程序以树状图的形式展示层次结构,清楚查看我们的 React 应用程序。它还支持 React Router,Redux 和 React Fibre。

使用此工具,我们可以将鼠标悬停在节点上,这些节点是指向树中与它们直接相关的组件的链接。

如果大家在查看结果时遇到问题,可以在地址栏上输入 chrome:extensions,找到 React Sight
框并单击 Allow access to file URLs 开关,如下所示:

12. React-cosmos

React-cosmos 是用于创建可重复使用 React 组件的开发工具。

它会扫描项目中的组件,并且可以实现以下功能:

  • 用属性、上下文和状态的任意组合下渲染组件
  • 模拟每个外部依赖项(例如 API 响应、localStorage 等)
  • 与正在运行的实例进行交互时,查看应用程序状态的实时变化

13. CodeSandbox

这是本次推荐中最好的可用工具之一,它可以让我们手动使用 React 的速度比眨眼还快(好吧,也许也没那么快)。

这个称为 CodeSandbox的工具是一个在线编辑器,我们从创建原型到 Web 应用程序部署 - 都可以在这个网站实现!

在早期,Codesandbox 仅支持 React,但现在已经扩展到 Vue 和 Angular 等库。他们还支持常见的静态站点生成器(如 gatsby 或 nextjs )创建项目来启动下一个 React Web 项目。

关于 codesandbox,它不仅活跃,还有很多有意思的事情可以讨论。

如果大家需要探索一下人们为方便大家起见正在构建的一些项目,那么单击 explore 就可以轻松访问到大量代码示例,来帮助大家更新下一个项目:

图十一

大家一旦开始编辑项目,就会意识到,实际上要使用的是个功能强大的 VSCode 编辑器。

我很想写一篇完整的文章,介绍我们今天在 codeandbox 上可以使用的所有功能,不过,现在看起来工作已经完成了。

14. React bits

React bits 是 React 模式、技术、技巧和窍门的集合,所有这些都以类似在线文档的格式编写,大家可以在同一个选项卡上快速访问不同的设计模式和技术、反模式、样式、UX 变体以及其他有用的与 React 相关的材料。

他们有一个 GitHub 存储库,目前有 10437 星。

一些示例包括诸如道具代理,在不同场景下处理各种 UX 的组合之类的概念,甚至还提示了每个开发人员应该避免的一些陷阱。

这是他们页面上的样子,如大家在左侧的菜单上看到的那样,有很多信息:)

15. Folderize

Folderize 是一个 VSCode 扩展。它可以让我们将组件文件转换为组件文件夹结构。转换后的 React 组件仍将是一个组件,只是现在已转换为一个目录。

例如,假设我们正在创建一个 React 组件,它把文件作为属性以显示有用的信息,比如它们的元数据。元数据组件的逻辑占用了很多行,因此我们决定将其拆分为一个单独的文件。但是,当我们决定这样做时,我们就有了两个相互关联的文件。

因此,如果我们的目录如下所示:

图十三

我们可能想把 FileView.jsFileMetadata.js 抽象到目录结构中,像 Apples- 那样,特别是如果我们希望添加更多与文件相关的组件,比如 FileScanner.js 。这就是 folderize 可以为我们做的事情,这样它们就可以具有以下类似结构:

import React from 'react'
import FileView from './src/components/FileView'

const App = (props) => <FileView {...props} />

export default App

16. React Starter Projects

React Starter Projects 是一个很棒的依赖库列表,我们可以在一个页面中查看全部项目。因此,如果我们觉得能同时快速查看到大量选项是非常有用的,那么这个很适合我们。

一旦看到喜欢的入门项目后,我们就可以简单克隆存储库,根据开发中的应用需要进行简单修改。但是,并非所有的库都用来克隆存储库,因为其中一些库需要通过安装形式,才能成为项目的依赖项。这样可以更轻松地获取更新并保持项目整洁。

以下是该页面看起来的样子:

17. Highlight Updates

可以说,这是每个开发者工具包里都应该有的重要工具。Highlight Updates 是 React DevTools 的一项扩展功能,可以查看页面中的哪些组件正在不必要地重渲染。

它们会用橙色/红色标出严重的重渲染问题,帮助我们在开发页面时更容易的发现一些性能问题。

除非我们的目标是构建平庸的应用程序,否则为什么不试试这个在我们身边的好东西。

18. React Diff Viewer

React Diff Viewer 是使用 Diff 和 React 制作的简单美观的文本差异查看器。支持多种功能,如:分屏视图,内联视图,单词差异,行高亮显示等。

如果我们想将此功能嵌入记事本(如 Boostnote)和自定义至应用程序(比如主题颜色、故事演示文档组合等),那么,它将非常有用。

图

19. JS.coach

JS.coach 是我经常用来查找 React 相关材料的网站。我不知道为什么提到这个网站的人不多,但在这个页面我发现了几乎所有我需要的信息,它快捷、方便,并不断更新,总是能为我所有的项目提供所需的结果。

最近,他们添加了 React VR 选项卡,这真是太好了!

20. Awesome React

Awesome React 开源库是一个与 React 相关的并非常棒的列表。

这让我可能会忘记其他网站只从这个链接学习 React 。因为可以在此找到大量有用的资源,这些资源肯定会帮助我们构建出色的 React 应用程序!

21. Proton Native

Proton Native 为大家提供了一个 React 环境来构建跨平台的本机桌面应用程序。

它是 Electron 的替代产品,只有一些简洁的功能,包括:

  • 与 React Native 相同的语法
  • 适用于现存的 React 库,例如 Redux
  • 跨平台
  • 原生组件,不再有 Electron
  • 与所有正常的 Node.js 包兼容

有兴趣了解更多吗?请阅读他们的文档

22. Devhints React.js Cheatsheet

一个不错的 React 速查表,尽管它缺少 React Hooks。不用担心,我将为 Reactv16.8 + 创建速查表,请继续关注。

结论

以上就是本次分享的全部工具。

希望大家在这里找到了有价值的信息。

查看原文

赞 99 收藏 76 评论 2

耗砸 回答了问题 · 2019-09-30

element $msgbox render的checkbox不能双向绑定数据

可以对el-picker做一次封装,然后渲染封装的这个组件

clipboard.png

需要注意在外面要接收里面的值的改变

还要记得全局注册下组件

Vue.component('ElDatePickerBox', ElDatePickerBox)
el-date-picker-box的代码很简单
<template>
    <el-date-picker
        v-model="value"
        placeholder="选择日期"
        type="date">
    </el-date-picker>
</template>

<script>

    export default {
        name: 'el-date-picker-box', // Notice: 写组件的时候需要给一个名字
        directives: {},
        components: {},
        mixins: [],
        data() {
            return {
                value: ''
            }
        },
        props: {},
        computed: {},
        filters: {},
        methods: {},
        watch: {
            value: {
                immediate: true,
                handler(val) {
                    this.$emit('update-date', val)
                }
            }
        },
        beforeCreate() {
        },
        created() {
        },
        beforeMount() {
        },
        mounted() {
        },
        beforeUpdate() {
        },
        updated() {
        },
        activated() {
        },
        deactivated() {
        },
        beforeDestroy() {
        },
        destroyed() {
        },
        errorCaptured() {
        },
    }
</script>

<style lang="scss" scoped>

</style>

关注 3 回答 3

耗砸 关注了用户 · 2019-04-10

撒网要见鱼 @dailc

你才25岁,你可以成为任何你想成为的人。

关注 4969

耗砸 收藏了文章 · 2019-04-10

从浏览器多进程到JS单线程,JS运行机制最全面的一次梳理

前言

见解有限,如有描述不当之处,请帮忙及时指出,如有错误,会及时修正。

----------超长文+多图预警,需要花费不少时间。----------

如果看完本文后,还对进程线程傻傻分不清,不清楚浏览器多进程、浏览器内核多线程、JS单线程、JS运行机制的区别。那么请回复我,一定是我写的还不够清晰,我来改。。。

----------正文开始----------

最近发现有不少介绍JS单线程运行机制的文章,但是发现很多都仅仅是介绍某一部分的知识,而且各个地方的说法还不统一,容易造成困惑。
因此准备梳理这块知识点,结合已有的认知,基于网上的大量参考资料,
从浏览器多进程到JS单线程,将JS引擎的运行机制系统的梳理一遍。

展现形式:由于是属于系统梳理型,就没有由浅入深了,而是从头到尾的梳理知识体系,
重点是将关键节点的知识点串联起来,而不是仅仅剖析某一部分知识。

内容是:从浏览器进程,再到浏览器内核运行,再到JS引擎单线程,再到JS事件循环机制,从头到尾系统的梳理一遍,摆脱碎片化,形成一个知识体系

目标是:看完这篇文章后,对浏览器多进程,JS单线程,JS事件循环机制这些都能有一定理解,
有一个知识体系骨架,而不是似懂非懂的感觉。

另外,本文适合有一定经验的前端人员,新手请规避,避免受到过多的概念冲击。可以先存起来,有了一定理解后再看,也可以分成多批次观看,避免过度疲劳。

大纲

  • 区分进程和线程
  • 浏览器是多进程的

    • 浏览器都包含哪些进程?
    • 浏览器多进程的优势
    • 重点是浏览器内核(渲染进程)
    • Browser进程和浏览器内核(Renderer进程)的通信过程
  • 梳理浏览器内核中线程之间的关系

    • GUI渲染线程与JS引擎线程互斥
    • JS阻塞页面加载
    • WebWorker,JS的多线程?
    • WebWorker与SharedWorker
  • 简单梳理下浏览器渲染流程

    • load事件与DOMContentLoaded事件的先后
    • css加载是否会阻塞dom树渲染?
    • 普通图层和复合图层
  • 从Event Loop谈JS的运行机制

    • 事件循环机制进一步补充
    • 单独说说定时器
    • setTimeout而不是setInterval
  • 事件循环进阶:macrotask与microtask
  • 写在最后的话

区分进程和线程

线程和进程区分不清,是很多新手都会犯的错误,没有关系。这很正常。先看看下面这个形象的比喻:

- 进程是一个工厂,工厂有它的独立资源

- 工厂之间相互独立

- 线程是工厂中的工人,多个工人协作完成任务

- 工厂内有一个或多个工人

- 工人之间共享空间

再完善完善概念:

- 工厂的资源 -> 系统分配的内存(独立的一块内存)

- 工厂之间的相互独立 -> 进程之间相互独立

- 多个工人协作完成任务 -> 多个线程在进程中协作完成任务

- 工厂内有一个或多个工人 -> 一个进程由一个或多个线程组成

- 工人之间共享空间 -> 同一进程下的各个线程之间共享程序的内存空间(包括代码段、数据集、堆等)

然后再巩固下:

如果是windows电脑中,可以打开任务管理器,可以看到有一个后台进程列表。对,那里就是查看进程的地方,而且可以看到每个进程的内存资源信息以及cpu占有率。

所以,应该更容易理解了:进程是cpu资源分配的最小单位(系统会给它分配内存)

最后,再用较为官方的术语描述一遍:

  • 进程是cpu资源分配的最小单位(是能拥有资源和独立运行的最小单位)
  • 线程是cpu调度的最小单位(线程是建立在进程的基础上的一次程序运行单位,一个进程中可以有多个线程)

tips

  • 不同进程之间也可以通信,不过代价较大
  • 现在,一般通用的叫法:单线程与多线程,都是指在一个进程内的单和多。(所以核心还是得属于一个进程才行)

浏览器是多进程的

理解了进程与线程了区别后,接下来对浏览器进行一定程度上的认识:(先看下简化理解)

  • 浏览器是多进程的
  • 浏览器之所以能够运行,是因为系统给它的进程分配了资源(cpu、内存)
  • 简单点理解,每打开一个Tab页,就相当于创建了一个独立的浏览器进程。

关于以上几点的验证,请再第一张图

图中打开了Chrome浏览器的多个标签页,然后可以在Chrome的任务管理器中看到有多个进程(分别是每一个Tab页面有一个独立的进程,以及一个主进程)。
感兴趣的可以自行尝试下,如果再多打开一个Tab页,进程正常会+1以上

注意:在这里浏览器应该也有自己的优化机制,有时候打开多个tab页后,可以在Chrome任务管理器中看到,有些进程被合并了
(所以每一个Tab标签对应一个进程并不一定是绝对的)

浏览器都包含哪些进程?

知道了浏览器是多进程后,再来看看它到底包含哪些进程:(为了简化理解,仅列举主要进程)

  1. Browser进程:浏览器的主进程(负责协调、主控),只有一个。作用有

    • 负责浏览器界面显示,与用户交互。如前进,后退等
    • 负责各个页面的管理,创建和销毁其他进程
    • 将Renderer进程得到的内存中的Bitmap,绘制到用户界面上
    • 网络资源的管理,下载等
  2. 第三方插件进程:每种类型的插件对应一个进程,仅当使用该插件时才创建
  3. GPU进程:最多一个,用于3D绘制等
  4. 浏览器渲染进程(浏览器内核)(Renderer进程,内部是多线程的):默认每个Tab页面一个进程,互不影响。主要作用为

    • 页面渲染,脚本执行,事件处理等

强化记忆:在浏览器中打开一个网页相当于新起了一个进程(进程内有自己的多线程)

当然,浏览器有时会将多个进程合并(譬如打开多个空白标签页后,会发现多个空白标签页被合并成了一个进程),如图

另外,可以通过Chrome的更多工具 -> 任务管理器自行验证

浏览器多进程的优势

相比于单进程浏览器,多进程有如下优点:

  • 避免单个page crash影响整个浏览器
  • 避免第三方插件crash影响整个浏览器
  • 多进程充分利用多核优势
  • 方便使用沙盒模型隔离插件等进程,提高浏览器稳定性

简单点理解:如果浏览器是单进程,那么某个Tab页崩溃了,就影响了整个浏览器,体验有多差;同理如果是单进程,插件崩溃了也会影响整个浏览器;而且多进程还有其它的诸多优势。。。

当然,内存等资源消耗也会更大,有点空间换时间的意思。

重点是浏览器内核(渲染进程)

重点来了,我们可以看到,上面提到了这么多的进程,那么,对于普通的前端操作来说,最终要的是什么呢?答案是渲染进程

可以这样理解,页面的渲染,JS的执行,事件的循环,都在这个进程内进行。接下来重点分析这个进程

请牢记,浏览器的渲染进程是多线程的(这点如果不理解,请回头看进程和线程的区分

终于到了线程这个概念了?,好亲切。那么接下来看看它都包含了哪些线程(列举一些主要常驻线程):

  1. GUI渲染线程

    • 负责渲染浏览器界面,解析HTML,CSS,构建DOM树和RenderObject树,布局和绘制等。
    • 当界面需要重绘(Repaint)或由于某种操作引发回流(reflow)时,该线程就会执行
    • 注意,GUI渲染线程与JS引擎线程是互斥的,当JS引擎执行时GUI线程会被挂起(相当于被冻结了),GUI更新会被保存在一个队列中等到JS引擎空闲时立即被执行。
  2. JS引擎线程

    • 也称为JS内核,负责处理Javascript脚本程序。(例如V8引擎)
    • JS引擎线程负责解析Javascript脚本,运行代码。
    • JS引擎一直等待着任务队列中任务的到来,然后加以处理,一个Tab页(renderer进程)中无论什么时候都只有一个JS线程在运行JS程序
    • 同样注意,GUI渲染线程与JS引擎线程是互斥的,所以如果JS执行的时间过长,这样就会造成页面的渲染不连贯,导致页面渲染加载阻塞。
  3. 事件触发线程

    • 归属于浏览器而不是JS引擎,用来控制事件循环(可以理解,JS引擎自己都忙不过来,需要浏览器另开线程协助)
    • 当JS引擎执行代码块如setTimeOut时(也可来自浏览器内核的其他线程,如鼠标点击、AJAX异步请求等),会将对应任务添加到事件线程中
    • 当对应的事件符合触发条件被触发时,该线程会把事件添加到待处理队列的队尾,等待JS引擎的处理
    • 注意,由于JS的单线程关系,所以这些待处理队列中的事件都得排队等待JS引擎处理(当JS引擎空闲时才会去执行)

  4. 定时触发器线程

    • 传说中的setIntervalsetTimeout所在线程
    • 浏览器定时计数器并不是由JavaScript引擎计数的,(因为JavaScript引擎是单线程的, 如果处于阻塞线程状态就会影响记计时的准确)
    • 因此通过单独线程来计时并触发定时(计时完毕后,添加到事件队列中,等待JS引擎空闲后执行)
    • 注意,W3C在HTML标准中规定,规定要求setTimeout中低于4ms的时间间隔算为4ms。
  5. 异步http请求线程

    • 在XMLHttpRequest在连接后是通过浏览器新开一个线程请求
    • 将检测到状态变更时,如果设置有回调函数,异步线程就产生状态变更事件,将这个回调再放入事件队列中。再由JavaScript引擎执行。

看到这里,如果觉得累了,可以先休息下,这些概念需要被消化,毕竟后续将提到的事件循环机制就是基于事件触发线程的,所以如果仅仅是看某个碎片化知识,
可能会有一种似懂非懂的感觉。要完成的梳理一遍才能快速沉淀,不易遗忘。放张图巩固下吧:

再说一点,为什么JS引擎是单线程的?额,这个问题其实应该没有标准答案,譬如,可能仅仅是因为由于多线程的复杂性,譬如多线程操作一般要加锁,因此最初设计时选择了单线程。。。

Browser进程和浏览器内核(Renderer进程)的通信过程

看到这里,首先,应该对浏览器内的进程和线程都有一定理解了,那么接下来,再谈谈浏览器的Browser进程(控制进程)是如何和内核通信的,
这点也理解后,就可以将这部分的知识串联起来,从头到尾有一个完整的概念。

如果自己打开任务管理器,然后打开一个浏览器,就可以看到:任务管理器中出现了两个进程(一个是主控进程,一个则是打开Tab页的渲染进程)
然后在这前提下,看下整个的过程:(简化了很多)

  • Browser进程收到用户请求,首先需要获取页面内容(譬如通过网络下载资源),随后将该任务通过RendererHost接口传递给Render进程
  • Renderer进程的Renderer接口收到消息,简单解释后,交给渲染线程,然后开始渲染

    • 渲染线程接收请求,加载网页并渲染网页,这其中可能需要Browser进程获取资源和需要GPU进程来帮助渲染
    • 当然可能会有JS线程操作DOM(这样可能会造成回流并重绘)
    • 最后Render进程将结果传递给Browser进程
  • Browser进程接收到结果并将结果绘制出来

这里绘一张简单的图:(很简化)

看完这一整套流程,应该对浏览器的运作有了一定理解了,这样有了知识架构的基础后,后续就方便往上填充内容。

这块再往深处讲的话就涉及到浏览器内核源码解析了,不属于本文范围。

如果这一块要深挖,建议去读一些浏览器内核源码解析文章,或者可以先看看参考下来源中的第一篇文章,写的不错

梳理浏览器内核中线程之间的关系

到了这里,已经对浏览器的运行有了一个整体的概念,接下来,先简单梳理一些概念

GUI渲染线程与JS引擎线程互斥

由于JavaScript是可操纵DOM的,如果在修改这些元素属性同时渲染界面(即JS线程和UI线程同时运行),那么渲染线程前后获得的元素数据就可能不一致了。

因此为了防止渲染出现不可预期的结果,浏览器设置GUI渲染线程与JS引擎为互斥的关系,当JS引擎执行时GUI线程会被挂起,
GUI更新则会被保存在一个队列中等到JS引擎线程空闲时立即被执行。

JS阻塞页面加载

从上述的互斥关系,可以推导出,JS如果执行时间过长就会阻塞页面。

譬如,假设JS引擎正在进行巨量的计算,此时就算GUI有更新,也会被保存到队列中,等待JS引擎空闲后执行。
然后,由于巨量计算,所以JS引擎很可能很久很久后才能空闲,自然会感觉到巨卡无比。

所以,要尽量避免JS执行时间过长,这样就会造成页面的渲染不连贯,导致页面渲染加载阻塞的感觉。

WebWorker,JS的多线程?

前文中有提到JS引擎是单线程的,而且JS执行时间过长会阻塞页面,那么JS就真的对cpu密集型计算无能为力么?

所以,后来HTML5中支持了Web Worker

MDN的官方解释是:

Web Worker为Web内容在后台线程中运行脚本提供了一种简单的方法。线程可以执行任务而不干扰用户界面

一个worker是使用一个构造函数创建的一个对象(e.g. Worker()) 运行一个命名的JavaScript文件 

这个文件包含将在工作线程中运行的代码; workers 运行在另一个全局上下文中,不同于当前的window

因此,使用 window快捷方式获取当前全局的范围 (而不是self) 在一个 Worker 内将返回错误

这样理解下:

  • 创建Worker时,JS引擎向浏览器申请开一个子线程(子线程是浏览器开的,完全受主线程控制,而且不能操作DOM)
  • JS引擎线程与worker线程间通过特定的方式通信(postMessage API,需要通过序列化对象来与线程交互特定的数据)

所以,如果有非常耗时的工作,请单独开一个Worker线程,这样里面不管如何翻天覆地都不会影响JS引擎主线程,
只待计算出结果后,将结果通信给主线程即可,perfect!

而且注意下,JS引擎是单线程的,这一点的本质仍然未改变,Worker可以理解是浏览器给JS引擎开的外挂,专门用来解决那些大量计算问题。

其它,关于Worker的详解就不是本文的范畴了,因此不再赘述。

WebWorker与SharedWorker

既然都到了这里,就再提一下SharedWorker(避免后续将这两个概念搞混)

  • WebWorker只属于某个页面,不会和其他页面的Render进程(浏览器内核进程)共享

    • 所以Chrome在Render进程中(每一个Tab页就是一个render进程)创建一个新的线程来运行Worker中的JavaScript程序。
  • SharedWorker是浏览器所有页面共享的,不能采用与Worker同样的方式实现,因为它不隶属于某个Render进程,可以为多个Render进程共享使用

    • 所以Chrome浏览器为SharedWorker单独创建一个进程来运行JavaScript程序,在浏览器中每个相同的JavaScript只存在一个SharedWorker进程,不管它被创建多少次。

看到这里,应该就很容易明白了,本质上就是进程和线程的区别。SharedWorker由独立的进程管理,WebWorker只是属于render进程下的一个线程

简单梳理下浏览器渲染流程

本来是直接计划开始谈JS运行机制的,但想了想,既然上述都一直在谈浏览器,直接跳到JS可能再突兀,因此,中间再补充下浏览器的渲染流程(简单版本)

为了简化理解,前期工作直接省略成:(要展开的或完全可以写另一篇超长文)

- 浏览器输入url,浏览器主进程接管,开一个下载线程,
然后进行 http请求(略去DNS查询,IP寻址等等操作),然后等待响应,获取内容,
随后将内容通过RendererHost接口转交给Renderer进程

- 浏览器渲染流程开始

浏览器器内核拿到内容后,渲染大概可以划分成以下几个步骤:

  1. 解析html建立dom树
  2. 解析css构建render树(将CSS代码解析成树形的数据结构,然后结合DOM合并成render树)
  3. 布局render树(Layout/reflow),负责各元素尺寸、位置的计算
  4. 绘制render树(paint),绘制页面像素信息
  5. 浏览器会将各层的信息发送给GPU,GPU会将各层合成(composite),显示在屏幕上。

所有详细步骤都已经略去,渲染完毕后就是load事件了,之后就是自己的JS逻辑处理了

既然略去了一些详细的步骤,那么就提一些可能需要注意的细节把。

这里重绘参考来源中的一张图:(参考来源第一篇)

load事件与DOMContentLoaded事件的先后

上面提到,渲染完毕后会触发load事件,那么你能分清楚load事件与DOMContentLoaded事件的先后么?

很简单,知道它们的定义就可以了:

  • 当 DOMContentLoaded 事件触发时,仅当DOM加载完成,不包括样式表,图片。

(譬如如果有async加载的脚本就不一定完成)

  • 当 onload 事件触发时,页面上所有的DOM,样式表,脚本,图片都已经加载完成了。

(渲染完毕了)

所以,顺序是:DOMContentLoaded -> load

css加载是否会阻塞dom树渲染?

这里说的是头部引入css的情况

首先,我们都知道:css是由单独的下载线程异步下载的。

然后再说下几个现象:

  • css加载不会阻塞DOM树解析(异步加载时DOM照常构建)
  • 但会阻塞render树渲染(渲染时需等css加载完毕,因为render树需要css信息)

这可能也是浏览器的一种优化机制。

因为你加载css的时候,可能会修改下面DOM节点的样式,
如果css加载不阻塞render树渲染的话,那么当css加载完之后,
render树可能又得重新重绘或者回流了,这就造成了一些没有必要的损耗。
所以干脆就先把DOM树的结构先解析完,把可以做的工作做完,然后等你css加载完之后,
在根据最终的样式来渲染render树,这种做法性能方面确实会比较好一点。

普通图层和复合图层

渲染步骤中就提到了composite概念。

可以简单的这样理解,浏览器渲染的图层一般包含两大类:普通图层以及复合图层

首先,普通文档流内可以理解为一个复合图层(这里称为默认复合层,里面不管添加多少元素,其实都是在同一个复合图层中)

其次,absolute布局(fixed也一样),虽然可以脱离普通文档流,但它仍然属于默认复合层

然后,可以通过硬件加速的方式,声明一个新的复合图层,它会单独分配资源
(当然也会脱离普通文档流,这样一来,不管这个复合图层中怎么变化,也不会影响默认复合层里的回流重绘)

可以简单理解下:GPU中,各个复合图层是单独绘制的,所以互不影响,这也是为什么某些场景硬件加速效果一级棒

可以Chrome源码调试 -> More Tools -> Rendering -> Layer borders中看到,黄色的就是复合图层信息

如下图。可以验证上述的说法

如何变成复合图层(硬件加速)

将该元素变成一个复合图层,就是传说中的硬件加速技术

  • 最常用的方式:translate3dtranslateZ
  • opacity属性/过渡动画(需要动画执行的过程中才会创建合成层,动画没有开始或结束后元素还会回到之前的状态)
  • will-chang属性(这个比较偏僻),一般配合opacity与translate使用(而且经测试,除了上述可以引发硬件加速的属性外,其它属性并不会变成复合层),

作用是提前告诉浏览器要变化,这样浏览器会开始做一些优化工作(这个最好用完后就释放)

  • <video><iframe><canvas><webgl>等元素
  • 其它,譬如以前的flash插件

absolute和硬件加速的区别

可以看到,absolute虽然可以脱离普通文档流,但是无法脱离默认复合层。
所以,就算absolute中信息改变时不会改变普通文档流中render树,
但是,浏览器最终绘制时,是整个复合层绘制的,所以absolute中信息的改变,仍然会影响整个复合层的绘制。
(浏览器会重绘它,如果复合层中内容多,absolute带来的绘制信息变化过大,资源消耗是非常严重的)

而硬件加速直接就是在另一个复合层了(另起炉灶),所以它的信息改变不会影响默认复合层
(当然了,内部肯定会影响属于自己的复合层),仅仅是引发最后的合成(输出视图)

复合图层的作用?

一般一个元素开启硬件加速后会变成复合图层,可以独立于普通文档流中,改动后可以避免整个页面重绘,提升性能

但是尽量不要大量使用复合图层,否则由于资源消耗过度,页面反而会变的更卡

硬件加速时请使用index

使用硬件加速时,尽可能的使用index,防止浏览器默认给后续的元素创建复合层渲染

具体的原理时这样的:
**webkit CSS3中,如果这个元素添加了硬件加速,并且index层级比较低,
那么在这个元素的后面其它元素(层级比这个元素高的,或者相同的,并且releative或absolute属性相同的),
会默认变为复合层渲染,如果处理不当会极大的影响性能**

简单点理解,其实可以认为是一个隐式合成的概念:如果a是一个复合图层,而且b在a上面,那么b也会被隐式转为一个复合图层,这点需要特别注意

另外,这个问题可以在这个地址看到重现(原作者分析的挺到位的,直接上链接):

http://web.jobbole.com/83575/

从Event Loop谈JS的运行机制

到此时,已经是属于浏览器页面初次渲染完毕后的事情,JS引擎的一些运行机制分析。

注意,这里不谈可执行上下文VOscop chain等概念(这些完全可以整理成另一篇文章了),这里主要是结合Event Loop来谈JS代码是如何执行的。

读这部分的前提是已经知道了JS引擎是单线程,而且这里会用到上文中的几个概念:(如果不是很理解,可以回头温习)

  • JS引擎线程
  • 事件触发线程
  • 定时触发器线程

然后再理解一个概念:

  • JS分为同步任务和异步任务
  • 同步任务都在主线程上执行,形成一个执行栈
  • 主线程之外,事件触发线程管理着一个任务队列,只要异步任务有了运行结果,就在任务队列之中放置一个事件。
  • 一旦执行栈中的所有同步任务执行完毕(此时JS引擎空闲),系统就会读取任务队列,将可运行的异步任务添加到可执行栈中,开始执行。

看图:

看到这里,应该就可以理解了:为什么有时候setTimeout推入的事件不能准时执行?因为可能在它推入到事件列表时,主线程还不空闲,正在执行其它代码,
所以自然有误差。

事件循环机制进一步补充

这里就直接引用一张图片来协助理解:(参考自Philip Roberts的演讲《Help, I'm stuck in an event-loop》)

上图大致描述就是:

  • 主线程运行时会产生执行栈,

栈中的代码调用某些api时,它们会在事件队列中添加各种事件(当满足触发条件后,如ajax请求完毕)

  • 而栈中的代码执行完毕,就会读取事件队列中的事件,去执行那些回调
  • 如此循环
  • 注意,总是要等待栈中的代码执行完毕后才会去读取事件队列中的事件

单独说说定时器

上述事件循环机制的核心是:JS引擎线程和事件触发线程

但事件上,里面还有一些隐藏细节,譬如调用setTimeout后,是如何等待特定时间后才添加到事件队列中的?

是JS引擎检测的么?当然不是了。它是由定时器线程控制(因为JS引擎自己都忙不过来,根本无暇分身)

为什么要单独的定时器线程?因为JavaScript引擎是单线程的, 如果处于阻塞线程状态就会影响记计时的准确,因此很有必要单独开一个线程用来计时。

什么时候会用到定时器线程?当使用setTimeoutsetInterval,它需要定时器线程计时,计时完成后就会将特定的事件推入事件队列中。

譬如:

setTimeout(function(){
    console.log('hello!');
}, 1000);

这段代码的作用是当1000毫秒计时完毕后(由定时器线程计时),将回调函数推入事件队列中,等待主线程执行

setTimeout(function(){
    console.log('hello!');
}, 0);

console.log('begin');

这段代码的效果是最快的时间内将回调函数推入事件队列中,等待主线程执行

注意:

  • 执行结果是:先beginhello!
  • 虽然代码的本意是0毫秒后就推入事件队列,但是W3C在HTML标准中规定,规定要求setTimeout中低于4ms的时间间隔算为4ms。

(不过也有一说是不同浏览器有不同的最小时间设定)

  • 就算不等待4ms,就算假设0毫秒就推入事件队列,也会先执行begin(因为只有可执行栈内空了后才会主动读取事件队列)

setTimeout而不是setInterval

用setTimeout模拟定期计时和直接用setInterval是有区别的。

因为每次setTimeout计时到后就会去执行,然后执行一段时间后才会继续setTimeout,中间就多了误差
(误差多少与代码执行时间有关)

而setInterval则是每次都精确的隔一段时间推入一个事件
(但是,事件的实际执行时间不一定就准确,还有可能是这个事件还没执行完毕,下一个事件就来了)

而且setInterval有一些比较致命的问题就是:

  • 累计效应(上面提到的),如果setInterval代码在(setInterval)再次添加到队列之前还没有完成执行,

就会导致定时器代码连续运行好几次,而之间没有间隔。
就算正常间隔执行,多个setInterval的代码执行时间可能会比预期小(因为代码执行需要一定时间)

  • 譬如像iOS的webview,或者Safari等浏览器中都有一个特点,在滚动的时候是不执行JS的,如果使用了setInterval,会发现在滚动结束后会执行多次由于滚动不执行JS积攒回调,如果回调执行时间过长,就会非常容器造成卡顿问题和一些不可知的错误(这一块后续有补充,setInterval自带的优化,不会重复添加回调)
  • 而且把浏览器最小化显示等操作时,setInterval并不是不执行程序,

它会把setInterval的回调函数放在队列中,等浏览器窗口再次打开时,一瞬间全部执行时

所以,鉴于这么多但问题,目前一般认为的最佳方案是:用setTimeout模拟setInterval,或者特殊场合直接用requestAnimationFrame

补充:JS高程中有提到,JS引擎会对setInterval进行优化,如果当前事件队列中有setInterval的回调,不会重复添加。不过,仍然是有很多问题。。。

事件循环进阶:macrotask与microtask

这段参考了参考来源中的第2篇文章(英文版的),(加了下自己的理解重新描述了下),
强烈推荐有英文基础的同学直接观看原文,作者描述的很清晰,示例也很不错,如下:

https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/

上文中将JS事件循环机制梳理了一遍,在ES5的情况是够用了,但是在ES6盛行的现在,仍然会遇到一些问题,譬如下面这题:

console.log('script start');

setTimeout(function() {
    console.log('setTimeout');
}, 0);

Promise.resolve().then(function() {
    console.log('promise1');
}).then(function() {
    console.log('promise2');
});

console.log('script end');

嗯哼,它的正确执行顺序是这样子的:

script start
script end
promise1
promise2
setTimeout

为什么呢?因为Promise里有了一个一个新的概念:microtask

或者,进一步,JS中分为两种任务类型:macrotaskmicrotask,在ECMAScript中,microtask称为jobs,macrotask可称为task

它们的定义?区别?简单点可以按如下理解:

  • macrotask(又称之为宏任务),可以理解是每次执行栈执行的代码就是一个宏任务(包括每次从事件队列中获取一个事件回调并放到执行栈中执行)

    • 每一个task会从头到尾将这个任务执行完毕,不会执行其它
    • 浏览器为了能够使得JS内部task与DOM任务能够有序的执行,会在一个task执行结束后,在下一个 task 执行开始前,对页面进行重新渲染
(`task->渲染->task->...`)
  • microtask(又称为微任务),可以理解是在当前 task 执行结束后立即执行的任务

    • 也就是说,在当前task任务后,下一个task之前,在渲染之前
    • 所以它的响应速度相比setTimeout(setTimeout是task)会更快,因为无需等渲染
    • 也就是说,在某一个macrotask执行完后,就会将在它执行期间产生的所有microtask都执行完毕(在渲染前)

分别很么样的场景会形成macrotask和microtask呢?

  • macrotask:主代码块,setTimeout,setInterval等(可以看到,事件队列中的每一个事件都是一个macrotask)
  • microtask:Promise,process.nextTick等

__补充:在node环境下,process.nextTick的优先级高于Promise__,也就是可以简单理解为:在宏任务结束后会先执行微任务队列中的nextTickQueue部分,然后才会执行微任务中的Promise部分。

参考:https://segmentfault.com/q/1010000011914016

再根据线程来理解下:

  • macrotask中的事件都是放在一个事件队列中的,而这个队列由事件触发线程维护
  • microtask中的所有微任务都是添加到微任务队列(Job Queues)中,等待当前macrotask执行完毕后执行,而这个队列由JS引擎线程维护

(这点由自己理解+推测得出,因为它是在主线程下无缝执行的)

所以,总结下运行机制:

  • 执行一个宏任务(栈中没有就从事件队列中获取)
  • 执行过程中如果遇到微任务,就将它添加到微任务的任务队列中
  • 宏任务执行完毕后,立即执行当前微任务队列中的所有微任务(依次执行)
  • 当前宏任务执行完毕,开始检查渲染,然后GUI线程接管渲染
  • 渲染完毕后,JS线程继续接管,开始下一个宏任务(从事件队列中获取)

如图:

另外,请注意下Promisepolyfill与官方版本的区别:

  • 官方版本中,是标准的microtask形式
  • polyfill,一般都是通过setTimeout模拟的,所以是macrotask形式
  • 请特别注意这两点区别

注意,有一些浏览器执行结果不一样(因为它们可能把microtask当成macrotask来执行了),
但是为了简单,这里不描述一些不标准的浏览器下的场景(但记住,有些浏览器可能并不标准)

20180126补充:使用MutationObserver实现microtask

MutationObserver可以用来实现microtask
(它属于microtask,优先级小于Promise,
一般是Promise不支持时才会这样做)

它是HTML5中的新特性,作用是:监听一个DOM变动,
当DOM对象树发生任何变动时,Mutation Observer会得到通知

像以前的Vue源码中就是利用它来模拟nextTick的,
具体原理是,创建一个TextNode并监听内容变化,
然后要nextTick的时候去改一下这个节点的文本内容,
如下:(Vue的源码,未修改)

var counter = 1
var observer = new MutationObserver(nextTickHandler)
var textNode = document.createTextNode(String(counter))

observer.observe(textNode, {
    characterData: true
})
timerFunc = () => {
    counter = (counter + 1) % 2
    textNode.data = String(counter)
}

对应Vue源码链接

不过,现在的Vue(2.5+)的nextTick实现移除了MutationObserver的方式(据说是兼容性原因),
取而代之的是使用MessageChannel
(当然,默认情况仍然是Promise,不支持才兼容的)。

MessageChannel属于宏任务,优先级是:MessageChannel->setTimeout
所以Vue(2.5+)内部的nextTick与2.4及之前的实现是不一样的,需要注意下。

这里不展开,可以看下https://juejin.im/post/5a1af88f5188254a701ec230

写在最后的话

看到这里,不知道对JS的运行机制是不是更加理解了,从头到尾梳理,而不是就某一个碎片化知识应该是会更清晰的吧?

同时,也应该注意到了JS根本就没有想象的那么简单,前端的知识也是无穷无尽,层出不穷的概念、N多易忘的知识点、各式各样的框架、
底层原理方面也是可以无限的往下深挖,然后你就会发现,你知道的太少了。。。

另外,本文也打算先告一段落,其它的,如JS词法解析,可执行上下文以及VO等概念就不继续在本文中写了,后续可以考虑另开新的文章。

最后,喜欢的话,就请给个赞吧!

附录

博客

初次发布2018.01.21于我个人博客上面

http://www.dailichun.com/2018/01/21/js_singlethread_eventloop.html

招聘软广

阿里巴巴钉钉商业化团队大量hc,高薪股权。机会好,技术成长空间足,业务也有很大的发挥空间!

还在犹豫什么,来吧!!!

社招(P6~P7)

职责和挑战

  1. 负责钉钉工作台。工作台是帮助企业实现数字化管理和协同的门户,是拥有亿级用户量的产品。如何保障安全、稳定、性能和体验是对我们的一大挑战。
  2. 负责开放能力建设。针对纷繁的业务场景,提供合理的开放方案,既要做到深入用户场景理解并支撑业务发展,满足企业千人千面、千行千面的诉求,又要在技术上保障用户的安全、稳定和体验。需要既要有技术抽象能力、平台架构能力,又要有业务的理解和分析能力。
  3. 开放平台基础建设。保障链路的安全和稳定。同时对如何保障用户体验有持续精进的热情和追求。

职位要求

  1. 精通HTML5、CSS3、JS(ES5/ES6)等前端开发技术
  2. 掌握主流的JS库和开发框架,并深入理解其设计原理,例如React,Vue等
  3. 熟悉模块化、前端编译和构建工具,例如webpack、babel等
  4. (加分项)了解服务端或native移动应用开发,例如nodejs、Java等
  5. 对技术有强追求,有良好的沟通能力和团队协同能力,有优秀的分析问题和解决问题的能力。

前端实习

面向2021毕业的同学

  1. 本科及以上学历,计算机相关专业
  2. 熟练掌握HTML5/CSS3/Javascript等web前端技术
  3. 熟悉至少一种常用框架,例如React、vue等
  4. 关注新事物、新技术,有较强的学习能力,有强烈求知欲和进取心
  5. 有半年以上实际项目经验,大厂加分

image.png

image.png

内推邮箱

lichun.dlc@alibaba-inc.com

简历发我邮箱,必有回应,符合要求直接走内推!!!

一对一服务,有问必答!

也可加我微信了解更多:a546684355

参考资料

查看原文

认证与成就

  • 获得 28 次点赞
  • 获得 17 枚徽章 获得 0 枚金徽章, 获得 5 枚银徽章, 获得 12 枚铜徽章

擅长技能
编辑

开源项目 & 著作
编辑

(゚∀゚ )
暂时没有

注册于 2017-09-15
个人主页被 507 人浏览