前言

react很容易上手，这是真的！！！毕竟对于ES6的知识点熟知度高的话，开发普通的小应用，react不再话下。可是，你是否考虑过，应用中组件间props传递的问题。比方说，我们需要向一个子子子子组件中传递一个props，一层一层的传递是不是过于丑陋了一些呢！那么，你或许会说用redux吧，做一个全局的store管理，这样就不会有这么多的麻烦了。可是，redux本身就不容易上手，何况你的程序可能并没有需要用到它那么复杂。那么，解决办法只有一个——context。这个东西，说实话，并不好用，或许对于不熟悉的你或许会踩坑，那么今天，我们就来好好聊聊它吧。

正文

context是一个尝试性的API，官方也并不建议去使用它。因为它会使得整个程序并不稳定。

首先，我们来尝试一下context的使用。

我们先来模拟一个列表应用，整个列表应用包含、、、

在不使用context的情况下：

class Button extends React.Component {    //一个Button组件，返回一个根据颜色定义的按钮
  render(){
    return (
      <button style={{'color' : this.props.color}}>      //在button中使用props中的color
        {this.props.children}
      </button>
    );
  }
}

class Message extends React.Component {     //在列表的子项目组件，其中包括Button组件
  
  render(){
    return (
      <div>
        {this.props.text}<Button color={this.props.color}>Delete</Button>    //向Button传递color
      </div>
    );
  }
}


class MessageList extends React.Component {   //列表组件
  render(){
    const children = this.props.message.map((item, index) => 
      <Message text={item} color={this.props.color} key={item}/>    //向Message传递color
    );
    
    return (
      <div>{children}</div>
    );
  }
}

class App extends React.Component {   //app组件
  
  constructor(props){
    super(props);
    
    this.state={
      message: [
        'hello1', 'hello2'
      ],
      color: 'red'
    };
  }
  
  render(){
    return (
      <div>
      <MessageList message={this.state.message} color={this.state.color}/>    //传递state中的color
      </div>
    );
  }
}


ReactDOM.render(<App/>, document.getElementById('root'));

源码地址

从这个例子中，我们要聊的是color这个属性。你会发现color一直从App->MessageList->Message->Button，其中一共穿过了2个组件，当然了，这是我们有意为之。但是，我们传递的方式实在是丑陋。

那么，如果我们对之前的进行改写，使用context来直接跨组件传递，或许会好一点。将之前的代码进行修改

//  Button部分修改

class Button extends React.Component {
  render () {
    return (
      <button style={{color: this.context.color}}>       //此处直接使用context
        {this.props.children}
      </button>
    );
  }
}

Button.contextTypes = {      //增加Button组件中的contextTypes校验
  color: PropTypes.String
};

//App组件部分修改
class App extends React.Component {
  constructor(props){
    super(props);
    
    this.state = {
      messages: [
        'message1', 'message2'
      ],
      color: 'red'
    };
  }
  
  getChildContext(){      //增加一个返回context对象的函数getChildContext
    return {color: 'red'};
  }
  
  render () {
    return (
      <div>
        <MessageList messages={this.state.messages}/>
      </div>
    );
  }
}

App.childContextTypes = {     //这里增加childContextTypes校验
  color: PropTypes.String
};

源码地址

其实就是在App中增加了getChildContext()函数，以及childContextTypes和contextTypes两个context的类型校验——这里需要使用到prop-types。我们可以发现，经过这样子的处理，整个传递流程变成了App->Button，中间少了两层组件。整体看上去的风格简洁，有效。

context使用问题

看过上面的测试用例，我们会发现context其实使用起来挺方便的，那么，为何它只作为尝试性API，官方都不推荐使用呢？

因此，我对上述例子进行了一些改动，从这里我们可以看到context的最大的问题。

首先，我们在App组件中增加一个可以改变color值的按钮

class App extends React.Component {    //修改后的App
  constructor(props){
    super(props);
    
    this.state = {
      messages: [
        'message1', 'message2'
      ],
      color: 'red'
    };
    
    this.changeColor = this.changeColor.bind(this);
  }
  
  getChildContext(){
    return {color: this.state.color};
  }
  
  changeColor(){      //增加一个函数可以改变state中的color值
    this.setState({
      color: 'green'
    });
  }
  
  render () {
    return (
      <div>
        <MessageList messages={this.state.messages}/>
        <button onClick={this.changeColor}>changeColor</button>
      </div>
    );
  }
}

这样我们就可以完成将red转变成green的效果，但是，我们需要去Message组件中添加一个生命周期shouldComponentUpdate，让它的返回值为false，即判断它不更新。

class Message extends React.Component {
  
  shouldComponentUpdate(){
    return false;
  }
  
  render () {
    return (
      <div>
        {this.props.text}<Button>Delete</Button>
      </div>
    );
  }
}

源码地址

这时，你再次点击按钮，你会发现无法改变button的颜色。

原因呢？主要是Message组件处阻断了组件的更新，导致的问题就是虽然context值被修改了，但是更深层次的组件却为更新，这或许是context最大的问题吧。而且context是一个全局的对象，或许存在会污染全局空间，这也是官方不建议使用它的原因。

总结

对于这种深层次的组件状态传递问题，现在的解决办法其实极为有限。

1. 使用redux做一个全局的store管理
2. 使用context进行一个直接传递（慎用）
3. 模拟一个redux类似的行为，在全局空间中保存一个state。
4. 使用props一层一层传递

个人觉得，一般组件超过3层以上的传递，就建议使用redux或者redux模拟。因为一般需要传递3层以上组件的，复杂度已经有点大了

前言

现在的移动端的使用率，已经远远大于PC端了。前端在移动端开发领域也起到了越来越大的用处。但是，移动端复杂的开发环境，往往是一大问题。谷歌开源Android以来，各大手机厂家不断对其内核进行修改，形成自己的版本（包括浏览器方面）。在移动端开发时，我们往往会遇到几个主要的开发环境：Android webview、UI webview（IOS）、微信的X5浏览器内核、UC浏览器等。可能，我们开发时时常会使用chrome来进行调试，但是真实用户使用时，往往只会使用UC或者QQ浏览器。

正文

正是这样子的环境，导致我们的开发成本逐渐地增加，开发问题层出不穷。本篇我将对移动端开发时所遇到的问题进行一个总结，便于之后碰到相同的问题能够轻松地解决。

meta元素基础问题

• 禁止页面缩放

<meta name="viewport" content="width=device-width, initial-scale=1.0, minimum-scale=1.0, maximum-scale=1.0, user-scalable=no"/>

• 禁止电话号码识别

<meta name="format-detection" content="telephone=no" />

• 禁止Android邮箱识别

<meta name="format-detection" content="email=no" />

移动端font-family问题

两个手机系统Android和iOS系统，对于中文来说，都不支持微软雅黑，但是系统自带的字体与微软雅黑的字体差异不大，都是无衬线字体，因此中文可以默认使用系统自带字体。
而英文字体的话，可以使用Helevatic字体，系统都是支持的，设置如下：

font-family: Helevatic;

px或者rem的选择问题

对于那些页面比较简单的设计图来说，使用px就可以了，再加上简单的弹性布局，并不需要使用rem；而对于那些页面复杂，内容繁多的设计图来说，例如，手淘主页，这种是需要使用rem来适配大小机型的。

click 300ms延时问题

开发过移动端的人，总会了解过这300ms的来历（简述为：当手机访问PC网页时，可以双击进行缩放，因此会在第一次点击之后，延迟300ms，看是否会进行第二次点击。）。那么，对于正常的网页来说，这300ms的慢启动，会影响用户体验的。我们可以使用fastclick或者zepto.js的touch模块中的tap事件(touchstart+touchmove+touchend)来替代click事件。或者可以直接使用touchstart来替代click事件。
整个事件执行顺序：touchstart->touchmove->touchend->click

retina高清屏

现在的手机高清屏越来越多了，何为retina屏幕？即那些一个点，显示多个像素的屏幕。最早是由苹果公司开发的。在这种高清屏下， 往往原先显示的正常的图片会被放大，而导致模糊的情况。这种情况下，我们就得让设计师准备多张图，如[email protected]，[email protected]。这样之后，我们可以写一个媒体查询，对图片进行选择。

1px边框问题

前言

现在，我们被称为前端工程师。然而，早年给我们的称呼却是页面仔。或许是职责越来越大，整体的前端井喷式的发展，使我们只关注了js，而疏远了css和html。

其实，我们可能经常在聊组件化，咋地咋地。但是，回过头来思考一下，如果你看到一张设计稿的时候，连布局都不清不楚，谈何组件化呢。所以，我们需要在分清楚组件之前，先来分清楚布局。废话说了这么多，只是想告诉你，布局这个东西真的很重要。本篇内容概括了布局的基础+基本的PC端布局+移动端适配等内容。如果你喜欢我的文章，欢迎评论，欢迎Star~。欢迎关注我的github博客

正文

或许对于你来说，喜欢js的背后，是看不懂css的深层。入门级的css非常简单，但是，精通它却没有想象的容易。我们本篇聊的是布局。前端开发，从拿到设计稿的那一刻，布局的思考就已经开始了。

举个例子，建筑师在设计房屋的时候，需要丈量开发地块的长度，以及每幢房屋相对于其他房屋的位置。

在css布局中，似乎也是这样开始的。我们也会去区分每个元素的尺寸和定位，力争完美的实现整个设计稿。所以，我们的布局应该从定位和尺寸开始聊起

定位

定位的概念就是它允许你定义一个元素相对于其他正常元素的位置，它应该出现在哪里，这里的其他元素可以是父元素，另一个元素甚至是浏览器窗口本身。还有就是浮动了，其实浮动并不完全算是定位，它的特性非常的神奇，以至于它在布局中被人广泛的应用。我们会在后文中专门提及它的。

谈及定位，我们就得从position属性说起。你能准确的说出position的属性值吗？相信你可以完美地说出这么六个属性值：static、relative、absolute、fixed、sticky和inherit。

• static(默认)：元素框正常生成。块级元素生成一个矩形框，作为文档流的一部分；行内元素则会创建一个或多个行框，置于其父元素中。
• relative：元素框相对于之前正常文档流中的位置发生偏移，并且原先的位置仍然被占据。发生偏移的时候，可能会覆盖其他元素。
• absolute：元素框不再占有文档流位置，并且相对于包含块进行偏移(所谓的包含块就是最近一级外层元素position不为static的元素)
• fixed：元素框不再占有文档流位置，并且相对于视窗进行定位
• sticky：(这是css3新增的属性值)粘性定位，官方的介绍比较简单，或许你不能理解。其实，它就相当于relative和fixed混合。最初会被当作是relative，相对于原来的位置进行偏移；一旦超过一定阈值之后，会被当成fixed定位，相对于视口进行定位。demo地址

简单地，介绍一下position的属性值的含义后，在来看一下偏移量top、right、bottom、left四个属性。

不清楚，当初在初学css的时候，会不会与margin这个属性混淆？其实，它们之间是很容易去辨识地。因为这四个属性值，其实是，定位时的偏移量。偏移量不会对static的元素起到作用。而margin，相对应的是盒子模型的外边距，它会对每个元素框起到作用，使得元素框与其他元素之间产生空白。

下面：我们来看一下一些常用定位的偏移

• relative：它的偏移是相对于原先在文档流中的位置，如图：

  

  这里设置了top：100px，left：100px。

• absolute：它的偏移量是相对于最近一级position不是static的祖先元素的

• fixed：它的偏移量是相对于视口的。

其实，这里说描述的内容，应该都是需要理解的。这些相对于布局来说是基础的，同时也是非常重要的。需要注意的是，这里的偏移量其实已经涉及到了接下来要说的尺寸。在做自适应布局设计时，往往希望这些偏移量的单位能够使用百分比，或者相对的单位例如rem等。

尺寸

那之前上面谈到过尺寸的单位——百分比。那么，下面部分我们就围绕着尺寸单位展开。

尺寸，我们就应该从单位聊起，对于px这个单位，做网页的应该在熟悉不过了，因此不多做介绍。

那么，我们可以来介绍一下下面几个单位：

• 百分比：百分比的参照物是父元素，50%相当于父元素width的50%
• rem：这个对于复杂的设计图相当有用，它是html的font-size的大小
• em：它虽然也是一个相对的单位，相对于父元素的font-size，但是，并不常用，主要是计算太麻烦了。

单位只是一个来定义元素大小的相应参考。另一个概念，或许可以用房子来打一个比方，在早年每幢房子都会在房子的外围建一层栅栏，使得整一块地区可以看成房子+内部地块+栅栏+外围地块的模型。而在css中，每个元素也会有盒子模型的概念。

盒子模型：每个元素，都会形成一个矩形块，主要包括四部分：margin(外边距)+border(边框)+padding(内边距)+content(内容)

css中存在两种不同的盒子模型，可以通过box-sizing设置不同的模型。两种盒子模型，主要是width的宽度不同。如图：

这是标准盒子模型，可以看到width的长度等于content的宽度；而当将box-sizing的属性值设置成border-box时，盒子模型的width=border+padding+content的总和。

可以看出，对于不同的模型的宽度是不同的。宽度默认的属性值是auto，这个属性值会使得内部元素的长度自动填充满父元素的width。如图：

但是，height的属性值也是默认的auto，为什么没有像width一样呢？

其实，auto这个属性值表示的是浏览器自动计算。这种自动计算，需要一个基准，一般浏览器都是允许高度滚动的，所以，会导致一个问题——浏览器找不到垂直方向上的基准。

同样地道理也会被应用在margin属性上。相信如果考察居中时，水平居中你可能闭着眼睛都能写出来，但是垂直居中却绕着脑袋想。这是因为如果是块级元素水平居中只要将水平方向上的margin设置成auto就可以了。但是，垂直方向上却没有这么简单，因为你设置成auto时，margin为0。这个问题，还是需要仔细思考一下的。

到此为止，布局最基本的部分我们已经将去大半，还有就是一块浮动。

浮动

浮动，这是一个非常有意思的东西，在布局中被广泛的应用。最初，设计浮动时，其实并不是为了布局的，而是为了实现文字环绕的特效，如图：

但是，浮动并不是仅仅这样而已。何为浮动？浮动应该说是‘自成一派’，类似于ps中的图层一样，浮动的元素会在浮动层上面进行排布，而在原先文档流中的元素位置，会被以某种方式进行删除，但是还是会影响布局。你可能会觉得有疑问，什么叫影响布局？我们可以来举个例子：

首先，我们准备两个颜色块，如图：

之后我们将left的块设置成左浮动，如图：

可以，发现虽然left块因为左浮动，而使得原先元素在文档流中占有的位置被删除，但是，当right块补上原先的位置时，right块中的字体却被挤出来了。这就是所谓的影响布局。

浮动为什么会被使用在布局中呢？因为设置浮动后的元素会形成BFC（使得内部的元素不会被外部所干扰），并且元素的宽度也不再自适应父元素宽度，而是适应自身内容。这样就可以，轻松地实现多栏布局的效果。

浮动的内容还需要介绍一块——清除浮动。可以看到，浮动元素，其实对于布局来说，是特别危险的。因为你可能这一块做过浮动，但未做清除，那么造成高度塌陷的问题。就是上面图示的那种情况。

清除浮动，最常用的方法有两种:

• overflow: 将父元素的overflow，设置成hidden。
• after伪类：对子元素的after伪类进行设置。

这里只是稍微的提上一嘴。下面我们正式来介绍一下网页的布局，本篇最核心的东西。

最初的布局——table

最初的时候，网页简单到可能只有文字和链接。这时候，大家最常用的就是table。因为table可以展示出多个块的排布。

这种布局现在应该不常用了，因为在形色单一时，使用起来方便。但是，现在的网页变得越来越复杂，适配的问题也是越来越多，这种布局已经不再时候了。

主要是div块的出现，可以使得网页进行灵活的排布，使得网页变得繁荣。这时，开发者也开始思索如何去更加清晰地分辨网页的层次。接下来，我们可以看看有哪些比较出名的布局方式。

两栏布局

是否记得，那些一边主体内容，一边目录的网页，如图：

类似于上图的布局，可以定义为两栏布局。

**两栏布局：**一栏定宽，一栏自适应。这样子做的好处是定宽的那一栏可以做广告，自适应的可以作为内容主体。

实现的方式：

1. float + margin：

<body>
  <div class="left">定宽</div>
  <div class="right">自适应</div>
</body>

.left{
  width: 200px;
  height: 600px;
  background: red;
  float: left;
  display: table;
  text-align: center;
  line-height: 600px;
  color: #fff;
}

.right{
  margin-left: 210px;
  height: 600px;
  background: yellow;
  text-align: center;
  line-height: 600px;
}

如图所示：

其他的方法：还可以使用position的absolute，可以使用同样的效果

三栏布局

三栏布局，也是经常会被使用到的一种布局。

它的特点：两边定宽，然后中间的width是auto的，可以自适应内容，再加上margin边距，来进行设定。

三栏布局可以有4种实现方式，每种实现方式都有各自的优缺点。

1.使用左右两栏使用float属性，中间栏使用margin属性进行撑开，注意的是html的结果

<div class="left">左栏</div>
<div class="right">右栏</div>
<div class="middle">中间栏</div>

.left{
  width: 200px;height: 300px; background: red; float: left;    
}
.right{
  width: 150px; height: 300px; background: green; float: right;
}
.middle{
  height: 300px; background: yellow; margin-left: 220px; margin-right: 160px;
}

缺点是：1. 当宽度小于左右两边宽度之和时，右侧栏会被挤下去；2. html的结构不正确

2. 使用position定位实现，即左右两栏使用position进行定位，中间栏使用margin进行定位

<div class="left">左栏</div>
<div class="middle">中间栏</div>
<div class="right">右栏</div>

.left{
    background: red;
    width: 200px;
    height: 300px;
    position: absolute;
    top: 0;
    left: 0;
}
.middle{
    height: 300px;
    margin: 0 220px;
    background: yellow;
}
.right{
    height: 300px;
    width: 200px;
    position: absolute;
    top: 0;
    right: 0;
    background: green;
}

好处是：html结构正常。

缺点时：当父元素有内外边距时，会导致中间栏的位置出现偏差

3. 使用float和BFC配合圣杯布局

将middle的宽度设置为100%，然后将其float设置为left，其中的main块设置margin属性，然后左边栏设置float为left，之后设置margin为-100%，右栏也设置为float：left，之后margin-left为自身大小。

<div class="wrapper">
    <div class="middle">
        <div class="main">中间</div>
    </div>
    <div class="left">
        左栏
    </div>
    <div class="right">
        右栏
    </div>
</div>

.wrapper{
    overflow: hidden;  //清除浮动
}
.middle{
    width: 100%;
    float: left;
}
.middle .main{
    margin: 0 220px;
    background: yellow;
}
.left{
    width: 200px;
    height: 300px;
    float: left;
    background: red;
    margin-left: -100%;
}
.right{
    width: 200px;
    height: 300px;
    float: left;
    background: green;
    margin-left: -200px;
}

缺点是：1. 结构不正确 2. 多了一层标签

4. flex布局

<div class="wrapper">
    <div class="left">左栏</div>
    <div class="middle">中间</div>
    <div class="right">右栏</div>
</div>

.wrapper{
    display: flex;
}
.left{
    width: 200px;
    height: 300px;
    background: red;
}
.middle{
    width: 100%;
    background: yellow;
    marign: 0 20px;
}
.right{
    width: 200px;
    height: 3000px;
    background: green;
}

除了兼容性，一般没有太大的缺陷

三栏布局使用较为广泛，不过也是比较基础的布局方式。对于PC端的网页来说，使用较多，但是移动端，本身宽度的限制，很难做到三栏的方式。因此，移动端盛行的现在，我们应该掌握一些自适应布局技巧和flex等方式。

移动端的时代

或许，手机占用了人们大部分的时间，对于前端工程师来说，不仅需要会h5和大前端的技术，还需要去适配不同的手机屏幕。PC端称王的时代已经过去，现在要求的网页都是需要能够去适配PC和移动端的。

之前，所聊的两栏和三栏布局，一般只能在PC中去使用，在移动端，由于屏幕尺寸有限，很难去做到类似的操作，所以，我们需要来了解新的东西。

1. 媒体查询

如果你需要一张网页能够在PC和移动端都能按照不同的设计稿显示出来，那么你需要做的就是去设置媒体查询。

媒体查询的css标识符是@media，它的媒体类型可以分为：

1. all， 所有媒体
2. braille 盲文触觉设备
3. embossed 盲文打印机
4. print 手持设备
5. projection 打印预览
6. screen 彩屏设备
7. speech ‘听觉’类似的媒体类型
8. tty 不适用像素的设备
9. tv 电视

代码示例：

@media screen {
  p.test {font-family:verdana,sans-serif;font-size:14px;}
}
@media print {
  p.test {font-family:times,serif;font-size:10px;}
}
@media screen,print {
  p.test {font-weight:bold;}
}
/*移动端样式*/
@media only screen and (min-device-width : 320px) and (max-device-width : 480px) {
  /* Styles */
}

媒体查询的主要原理：它像是给整个css样式设置了断点，通过给定的条件去判断，在不同的条件下，显示不同的样式。例如：手机端的尺寸在750px，而PC端则是大于750px的，我们可以将样式写成：

@media screen and (min-width: 750px){
  .media{
    height: 100px;
    background: red;
  }
}

@media (max-width: 750px){
  .media{
    height: 200px;
    background: green;
  }
}

demo地址

效果图：

flex弹性盒子

其实移动端会经常使用到flex布局，因为在简单的页面适配方面，flex可以起到很好的拉伸的效果。我们先看几张图体会一下：

可以从图中看出，这个网页不管屏幕分辨率怎么发生变化，它的高度和位置都不变，而且里面的元素排布也没有发生变化，总是图标信息在左边和薪资状况在右边。

这就是很明显的，flex布局。flex可以在移动端适配比较简单的，元素比较单一的页面。

具体的flex布局内容，在这里不详细说明。flex传送门

rem适配

rem可以说是移动端适配的一个神器。类似于手淘等界面，都是使用的rem进行的适配。这种界面有个特点就是页面元素的复杂度比较高，而使用flex进行布局会导致页面被拉伸，但是上下的高度却没有变化等问题。示例图：

具体的讲解可以看这篇比较好的文章。rem传送门

总结

分析到这里，布局的很多东西都已经非常的清晰了。相信这是一篇值得去收藏的一篇文章。内容可能有点多，所以这里做一个总结：

• 定位
• 尺寸
• 浮动
• 最初的布局——table
• 两栏布局
• 三栏布局
• 移动端的布局

相信你看完这些，在以后，一定可以拿到设计稿的时候，内心大致有个算盘，应该如何区分，如何布局。

最后，如果你对我写的有疑问，可以与我讨论。如果我写的有错误，欢迎指正。你喜欢我的博客，请给我关注Star~呦。大家一起总结一起进步。欢迎关注我的github博客

前言

至上一篇基础常识讲完之后，这次我们将开启新的篇章。本篇我们会来讲述你在操作时需要去增加的监听事件，焦点控制，按钮的状态同步等问题。同时，还需要完成的是当标题栏聚焦时，你需要去控制按钮的禁止点击，例如插入图片按钮等。所以综合而言，本篇还是相对比较重要的。接下来，我们会就上述提到的点进行一一讲述。如果你喜欢我的文章，欢迎评论，欢迎Star~。欢迎关注我的github博客。

正文

首先，我们第一步来讲一下焦点控制的问题。那么，你会认为焦点控制只是简单的使用focus函数聚焦这么简单吗？当然不是。一旦，你这样操作了，你会发现一个问题，你的焦点永远在起始处，往往会造成不良的用户体验。这里我们需要明白的第一点——焦点控制。

焦点

我们知道焦点其实就是一个range。每个range都会又一个collapsed去判断，前后是否重叠。一旦，前后重叠了，这个range就会称为焦点。所以，我们如果想去控制焦点，就必须学会控制range块。

回到上一篇的range介绍，我们知道range具备4个常用属性：startContainer、startOffset、endContainer、endOffset等4个属性。我们只要学会如何去控制这4个属性，我们就能将range块变出任意的样子。

那么，我们可以先从「聚焦功能」说起：

这里，我们所谓的聚焦是可以区分为两种，一种是保证聚焦到尾部，另一种就是聚焦到用户输入的位置。

聚焦尾部

之前，我们已经说过，focus函数使得整个编辑块聚焦，但是它是使得焦点聚焦在起始处，而我们现在需要将整个焦点聚焦到末尾，我们源码中的逻辑可以这样：

• 首先，我们先获取窗口的选区(selection的概念，我们之前也有提到过)
• 然后，我们需要将选取中的所有range块都清除掉(这样可以保证之前无论焦点处于任何的位置，都会先失去)
• 然后，创建一个新的range块，这时range块的所有属性都是默认的
• 最后，将这个range添加到selection中，这时，添加进去之后，range中的属性值并没有被定义，所以，整个range会保持在最后的位置。然后在使用focus函数，使得编辑块获得这个range

我们可以来看一下源码：

focus: function(){   //聚焦
	const _self = this;
	const range = document.createRange();
	range.selectNodeContents(_self.cache.editor);
	range.collapse(false);
	const select = window.getSelection();
	select.removeAllRanges();
	select.addRange(range);
	_self.cache.editor.focus();
}

这里，我们创建了一个range，然后将这个range的节点内容设置为编辑块，之后使用collapse来使得它的先后合并。同时，我们需要去获得选区，将选区中的range都清除掉，再将新创建的range对象添加到选区对象中。最后，使编辑块聚焦。

这时，你去测试一下，你就会发现焦点会自动聚焦到尾部去

聚焦还原

之前，我们也讲述过还有一种焦点控制的方式——聚焦到原先用户输入的位置

那么，我们需要如何去完成这一个功能呢？我们首先需要去保存用户输入的焦点。

我们可以先来看一下源码：

saveRange: function(){
	const _self = this;
	const selection = window.getSelection();
	if(selection.rangeCount > 0){
		const range = selection.getRangeAt(0);
		const { startContainer, startOffset, endContainer, endOffset} = range;
		_self.currentRange = {
			startContainer: startContainer,
			startOffset: startOffset,
			endContainer: endContainer,
			endOffset: endOffset
		};
	}
}

这里的saveRange方法就是我们在源码中用来保存Range的方法。其实，它的原理非常的简单：

1. 从选区中去获得第一个range块。(注意：因为ctrl键可以保证一个选取有多个range块)
2. 然后将range块中的四个属性提取出来startContainer、startOffset、endContainer、endOffset。
3. 最后，将这四个属性保存下来，因为我们之后也会使用到这个内容

既然你看到了保存焦点时的原理，那么，相信还原焦点的原理你应该也已经清楚一点了吧。

接下来，我们就来看一下还原焦点的过程：

• 首先，我们会创建一个range对象
• 然后，选区中所有的range都清除掉
• 之后，我们会将保存下来的四个属性设置进入range对象
• 最后，往选区中添加range

源码：

reduceRange: function(){
	const _self = this;
	const { startContainer, startOffset, endContainer, endOffset} = _self.currentRange;
	const range = document.createRange();
	const selection = window.getSelection();
	selection.removeAllRanges();
	range.setStart(startContainer, startOffset);
	range.setEnd(endContainer, endOffset);
	selection.addRange(range);
}

至此，我们已经将富文本中需要去控制焦点的部分内容分析完了。之后，我们先来看一下按钮的状态同步。

状态同步

何为状态同步？你或许还没有一个比较清晰的概念。那么，我们给定一个场景，来帮助大家理解一下：

最初，你会按下加粗按钮之后，输入部分的内容会加粗；但是，当你这时发现之前有个地方的内容，需要修改，这时你会点击那个部分进行修改。这时问题来了：在没点击之前，你的加粗按钮是高亮显示的，而点击之后，你首先要确定那个位置是否具备加粗，然后去控制按钮的高亮问题。这就是我们之后需要处理的问题——状态同步。

我们可以先简单的阐述一下状态同步的原理：

我们只需要去获得当前焦点处所含有的标签就可以了。因为我们所插入的bold、italic等都是通过execCommand的命令插入的。同样，document也提供了API让我们来获取当前焦点处的标签。我们可以看一下源码中的这个方法：

getEditItem: function(evt = {}){
	const _self = this;
	const { STATE_SCHEME, CHANGE_SCHEME } = _self.schemeCache;
	if(evt.target && evt.target.tagName === 'A'){
		_self.cache.currentLink = evt.target;
		const name = evt.target.innerText;
		const href = evt.target.getAttribute('href');
		window.location.href = CHANGE_SCHEME + encodeURI(name + '@_@' + href);
	}else{
		if(e.which == 8){
			AndroidInterface.staticWords(_self.staticWords());
		}
		const items = [];
		_self.commandSet.forEach((item) => {
			if(document.queryCommandState(item)){
				items.push(item);
			}
		});
		if(document.queryCommandValue('formatBlock')){
			items.push(document.queryCommandValue('formatBlock'));
		}
		window.location.href = STATE_SCHEME + encodeURI(items.join(','));
	}
}

这里的源码内容有点复杂，因为我们还有其他的一些情况需要考虑，所以这里我们可以来提取一部分进行分析：

const items = [];
_self.commandSet.forEach((item) => {
	if(document.queryCommandState(item)){
		items.push(item);
	}
});
if(document.queryCommandValue('formatBlock')){
	items.push(document.queryCommandValue('formatBlock'));
}
window.location.href = STATE_SCHEME + encodeURI(items.join(','));

这个部分就是实际去获取标签的部分，我们可以先来了解两个API：

• queryCommandState: 这个函数返回的boolean类型的值，然后它会去测试当前这个state中是否具备这个标签。

  我们可以做个测试：

  document.execCommand('bold', false, null);
  const state = document.queryCommandState('bold');
  console.log(state);   //true

  这样我们就可以明白上面第一部分操作的原理：

  • 首先，遍历数据集中的命令
  • 如果命令所处的标签存在，则将这个命令放入到items数组中，方便之后的状态同步。

• queryCommandValue：这个函数也是返回boolean类型的值。我们可以直接来做个测试：

  document.execCommand('formatBlock', false, '<h1>');
  const value = document.queryCommandValue('formatBlock');
  console.log(value);  //h1

  这里的不同点就是，无参数命令和有参数命令的区别了。类似于h1标签这种，需要我们自定义标签参数的值，往往就需要使用这部分的测试方式，所以，我们也会将获取到的value放入items集合中

最后，一步就是一个通信的问题了。我们之前一篇中，聊到如果js与webView之间进行交互时，可以通过url劫持的方式来完成。我们将这个URL头进行定义，相对应这种特殊的URL头，webView会做相应的处理。

因为URL中添加参数时，都需要将值进行URL编码。所以，我们需要做一个编码的过程。

那么，至此我们提取出来的代码部分讲完了。我们回过头来再去分析一下原来的代码。

有些特殊情况或许你的考虑到：

• 修改链接
• 删除，回车时的状态同步

首先，来看一下修改链接的，我们并不需要去进行状态的同步。所以，我们需要确定点击时，判断这个节点元素是否是A标签，我们可以看一下源码：

if(evt.target && evt.target.tagName === 'A'){
	_self.cache.currentLink = evt.target;
	const name = evt.target.innerText;
	const href = evt.target.getAttribute('href');
	window.location.href = CHANGE_SCHEME + encodeURI(name + '@_@' + href);
}

因为，我们需要修改链接，所以需要将当前这个链接的节点保留下来，方便之后的修改；同时，我们也需要向webview传递链接的name和url的信息。使用的方式——URL劫持。

之后，我们需要去考虑的是一些键位，比方说回车操作，删除操作。它们本身也不会去通知webview对其进行监听。键位的话，我们可以考虑按键时的键位code来进行特殊键位的判断，如下：

_self.cache.editor.addEventListener('keyup', (evt) => {
	if(evt.which == 37 || evt.which == 39 || evt.which == 13 || evt.which == 8){
		_self.getEditItem(evt);
	}
}, false);

这里我们对删除键、回车键、左尖括号『<』，右尖括号『>』，做了监听，然后当用户按下这几个键时，都会调用getEditItem的方法。

状态同步的问题我们就聊那么多。之后我们来看一下我们设置的监听事件。

设置监听

直接先放上源码来让大家看一下：

bind: function(){
	const _self = this;

	document.addEventListener('selectionchange', _self.saveRange, false);

	_self.cache.title.addEventListener('focus', function(){
		AndroidInterface.setViewEnabled(true);
	}, false);

	_self.cache.title.addEventListener('blur', () => {
		AndroidInterface.setViewEnabled(false);
	}, false);

	_self.cache.editor.addEventListener('blur', () => {
		_self.saveRange();
	}, false);

	_self.cache.editor.addEventListener('click', (evt) => {
		_self.saveRange();
		_self.getEditItem(evt);
	}, false);

	
	_self.cache.editor.addEventListener('keyup', (evt) => {
		if(evt.which == 37 || evt.which == 39 || evt.which == 13 || evt.which == 8){
			_self.getEditItem(evt);
		}
	}, false);

	_self.cache.editor.addEventListener('input', () => {
		AndroidInterface.staticWords(_self.staticWords());
	}, false);
}

直接按照顺序阐述下去吧！！

selectionchange事件，则是检测选区的变化，因为选区发送变化的时候。往往指定是焦点的变化。

每次焦点发生变化时，都需要去保存当前的range，以便于还原焦点。

focus和blur事件，其实就是需要去控制底栏按钮的可用性。因为我们的界面上面有标题栏，标题栏是不允许插入图片、插入链接、字体操作的。所以这里通过对象映射的方式，提醒webView去禁止底栏显示。

同样的，对于编辑块来说，需要监听blur事件，然后保存原来的焦点。

接下来，就是我们之前所说的点击事件的监听了。首先，点击编辑块时，需要你去保存焦点，同时同步这个位置的状态，调用getEditItem方法。

最后，需要去监听一个输入事件，因为我们需要去同步字体的数量，每当用户输入时，我们就要调用staticWords方法来同步字体的数目。

总结

最后，我们本篇文章的内容都已经分析完了。当然，你也可以细细理解我们在这里说做的所有操作，可以说这篇内容解决了我们在开发富文本编辑器时，大部分的问题。同时，也内涵了我们的思考。希望你能喜欢我们这个项目，同时帮助你的进步。

最后，如果你对我写的有疑问，可以与我讨论。如果我写的有错误，欢迎指正。你喜欢我的博客，请给我关注Star~呦。大家一起总结一起进步。欢迎关注我的github博客。同时也希望你关注我们的项目，github项目地址，谢谢支持

前言

在前端开发中，缓存有利于加快网页的加载速度，同时缓存能够被反复利用，所以可以减少流量和带宽的开销。

缓存的分类有很多种，CDN缓存、数据库缓存、代理服务器缓存和浏览器缓存。本篇将来讲解一下Web开发中的浏览器缓存。这个在实际开发环境中往往也会被问到，或者使用到。如何去准确认清楚缓存的概念，是前端必须要去学习的。如果你喜欢我的文章，欢迎评论，欢迎Star~。欢迎关注我的github博客

正文

浏览器的缓存问题，主要指的是http的缓存——即协议层。而h5新增的storage和数据库缓存，那是应用层缓存，并不被计入本篇的分析内容里面。下面我们正式开始来进行缓存的分析。

协议层的缓存，其实，可以被分成强制缓存和对比缓存。

强制缓存

首先，我们先来看一张强制缓存时的时序图，来了解一下强制缓存在不同情况下的请求模式：

从图中，我们不难看出，只有当缓存失效时，才会去服务器获取最新资源的方式，就是强制缓存。而在协议层的字段中，可以造成强制缓存的字段有两个Expires和Cache-Control。

1.0的时候见到我——Expires

最早使用的是Expires字段，该字段表示缓存到期时间，即有效时间+当时服务器的时间，然后将这个时间设置在header中返回给服务器。因此，该时间是一个绝对时间，举例说明：

Expires: Thu, 10 Nov 2017 08:45:11 GMT

图片示例：

在响应消息头中，设置这个字段之后，就可以告诉浏览器，在未过期之前不需要再次请求。

但是，这个字段设置时有缺点：

由于是绝对时间，用户可能会将客户端本地的时间进行修改，而导致浏览器判断缓存失效，重新请求该资源，同时，还导致客户端与服务端的时间不一致，致使缓存失效。

1.1的时候我来了——Cache-Control

已知Expires的缺点之后，在HTTP/1.1中，增加了一个字段Cache-Control，该字段表示资源缓存的最大有效时间，在该时间内，客户端不需要向服务器发送请求

这两者的区别就是前者是绝对时间，而后者是相对时间。我们不妨举个例子来说明一下：

Cache-Control: max-age=2592000

图片示例：

下面列举一下Cache-Control的字段可以带的值：

1. max-age：即最大有效时间，在上面的例子中我们可以看到

2. no-cache：表示没有缓存，即告诉浏览器该资源并没有设置缓存

3. s-maxage：同max-age，但是仅用于共享缓存，如CDN缓存

4. public：多用户共享缓存，默认设置

5. private：不能够多用户共享，HTTP认证之后，字段会自动转换成private。

总结一下，自从http1.1开始，Expires逐渐被Cache-Control取代。Cache-Control是一个相对时间，即使客户端时间发生改变，相对时间也不会随之改变，这样可以保持服务器和客户端的时间一致性。而且Cache-Control的可配置性比较强大。

对比缓存

扯完强制缓存，我们来看看对比缓存。在解释这个之前，是否可以先猜想一下，强制缓存是，缓存在未过有效期时，不需要请求资源。那么，对比缓存的原理又该如何呢？

废话不多说，我们也先从对比缓存的时序图讲起，如图：

对比缓存的过程是，先从缓存中获取对应的数据标识，然后向服务器发送请求，确认数据是否更新，如果更新，则返回新数据和新缓存；反之，则返回304状态码，告知客户端缓存未更新，可继续使用。

这正好弥补了一些强制缓存的缺陷。对比缓存主要应用于一些时常需要动态更新的资源文件。

对比缓存在协议里的字段是Last-Modified和If-Modified-Since。

别人的好伙伴——Last-Modified

Last-Modified：服务器告知客户端，资源最后一次被修改的时间，例如

Last-Modified: Thu, 10 Nov 2015 08:45:11 GMT

If-Modified-Since：再次请求时，请求头中带有该字段，服务器会将If-Modified-Since的值与Last-Modified字段进行对比，如果相等，则表示未修改，响应304；反之，则表示修改了，响应200状态码，返回数据。

这个字段可以和Cache-Control配合使用。

但是他还是有一定缺陷的：

1. 如果资源更新的速度是秒以下单位，那么该缓存是不能被使用的，因为它的时间单位最低是秒。

2. 如果文件是通过服务器动态生成的，那么该方法的更新时间永远是生成的时间，尽管文件可能没有变化，所以起不到缓存的作用。

我来完善它——Etag

由于Last-modified还是存在缺陷的，尽管大多数情况下，会使用它，但当遇到我们上面所说的场景时，我们可能就需要了解一下，我们另一个小伙伴了——Etag。

Etag存储的是文件的特殊标识(一般都是hash生成的)，服务器存储着文件的Etag字段，可以在与每次客户端传送If-no-match的字段进行比较，如果相等，则表示未修改，响应304；反之，则表示已修改，响应200状态码，返回数据。

最后，通过一张原理图，我们来加深一下记忆：

至此为止，两种缓存类型的缓存方式已经阐述完成了，不知你是否已经心中已经有个大致的印象，当别人问起时，你可以对答如流。希望我们一同进步吧，fighting。

浏览器行为引起的不同

最后，我们来聊聊浏览器行为会引起缓存的变化吧。

下面说一下浏览器的行为会产生怎样的请求：

1. 刷新网页 => 如果缓存没有失效，浏览器会直接使用缓存；反之，则向服务器请求数据
2. 手动刷新（F5） => 浏览器会认为缓存失效，在请求服务器时加上Cache-Control: max-age=0字段，然后询问服务器数据是否更新。
3. 强制刷新（Ctrl + F5） => 浏览器会直接忽略缓存，在请求服务器时加上Cache-Control: no-cache字段，然后重新向服务器拉取文件。

移动端的缓存处理

在PC端或许这样子的缓存机制就已经足够了，因为PC端不需要为网络的问题担心。

但是，移动端却不行，任何一个网络请求的增加，对于移动端的加载消耗时间都是比较大的（谁叫移动端的网太差呢，3G、2G）。那么，上述的缓存有什么问题呢？其实，强制缓存是没有太大问题的，因为只要缓存不到期，是不会想服务器发送请求的；但是如果是对比缓存的情况下，304的问题就比较巨大，因为它会造成无用的请求。每次在使用缓存前，都会向服务器发送请求确认，导致网络的延时。

一次完美的缓存必须保证两点：

1. 数据缓存之后，尽量减少服务器的请求
2. 如果资源更新的话，必须使得客户端的资源一起更新。

所以，一般我们会运用的方式是：

在资源文件后面加上表示，如config.f1ec3.js、config.v1.js之类的，然后给资源设置较长的缓存时间，如一年

Cache-Control: max-age=31536000

这样子，就不会造成304的回包现象。
然后一旦资源发生更新时，我们可以改变资源后面的标识符，实现静态资源非覆盖式更新。

总结

本篇大致分析了浏览器缓存部分的分类情况，以及细化分析。主要可分为：

1. 强制缓存

   • Expires字段

   • Cache-Control字段

2. 对比缓存

   • Last-Modefied字段

   • Etag标识

3. 浏览器行为引起的缓存变化

4. 移动端的缓存策略

其实，在讲述移动端的缓存策略时，并没有分析的特别详细，只是大致的讲解了一下目前大家都在使用的缓存策略。可能之后，还会写一篇移动端缓存的细分文章。

最后，如果你对我写的有疑问，可以与我讨论。如果我写的有错误，欢迎指正。你喜欢我的博客，请给我关注Star~呦。大家一起总结一起进步。欢迎关注我的github博客

前言

本篇内容主要是详解图片上传、重传、进度条、遮罩、错误显示、以及图片删除等功能的分析。

前言

本篇记录了我在搭建整个后端开发环境的整体过程。后端开发环境，从框架选型，到单测环境、规范校验、打包等。其实，GitHub上面具备着纵多的脚手架可以快速搭建出一个后端开发的环境。但是，那样操作其实并没有实际的效果，只能满足快速开发而已。如果你喜欢我的文章，欢迎评论，欢迎Star~。欢迎关注我的github博客

正文

首先，我们需要确定开发环境主体的框架，我的选择时koa2，虽然需要去满足nodeJS大于7.6.0以上，但是其利用了ES7中的async/await，实在是令人满意。最大的优势就是服务器上的nodeJS版本是我们所控制的。如果你不清楚如何控制nodeJS版本的话，可以安装nvm来进行node版本的切换。

搭建项目目录

开始创建一个空项目文件夹，命名为koa-scaffold:

mkdir koa-scaffold

然后进入新创建的文件目录中：

cd koa-scaffold

然后，我们可以初始化package.json文件

npm init -y

同时，我们还需要去创建一些空文件目录，统一整体的开发目录：

mkdir -p server/{routes,db,controllers,models,services} test

最后，安装koa2:

npm install --save koa

数据库

这里所使用的数据库是MongoDB，不过听说它的模糊查询并(qi)不(shi)优(la)秀(ji)。但是，考虑到操作方便，而且作为前端的开发者，接触到MongoDB这种NoSQL型数据库是迟早的事情。所以，我们会选择mongoose这个数据库连接库，如果你使用的是其他的数据库的话，那么我推荐knex.js。(有兴趣了解可以自行Google)

安装mongoose：

npm install --save mongoose

然后，我们进行一下测试，在test目录下建立一个dbtest.js文件：

const mongoose = require('mongoose');

mongoose.connect('mongodb://localhose/test');

const db = mongoose.connection;

db.on('error', (err) => {
  console.log('connection error: ' + err);
});

db.on('open', () => {
  console.log('connection success!');
});

通过这段代码，然后运行一下dbtest.js。之后，我们会发现我们的本地MongoDB中多了test数据库名。

测试

这里的测试选择了mocha和chai，不需要追求原因。因为就目前前端的测试框架良莠不齐，种类繁多，但是可以说前端工程师，却很少做单测之类的事情。所以，测试框架可以根据自己的喜好来决定。

这里选用了一下一套测试框架：

Mocha: 它是一个Javascript测试框架。你可以使用它来自动化测试你的代码

Chai：这是Javascript的一个断言库。

ChaiHTTP：这是Chai的一个插件

安装过程：

npm install mocha chai chai-http --save-dev

然后，在package.json中配置script字段:

"script": {
	"test": "mocha"
}

这里需要大家熟悉mocha+chai的用法，具体可上官网查看

结尾

本篇文章大致分析了一下，我们需要在搭建一个后端集成环境时的选择方向。
参考文章An Introduction to Building TDD RESTful APIs with Koa 2, Mocha and Chai

如果你对我写的有疑问，可以评论，如我写的有错误，欢迎指正。你喜欢我的博客，请给我关注Star~呦。大家一起总结一起进步。欢迎关注我的github博客

前言

最近由于适应新环境，更博也少了。不过想在本周总结一下cookie的东西。虽然开头起了一个非常垮的标题，但是相信内容一定不会垮，满满的干货。

前言

国庆假期已过一半，来篇干货压压惊。

ES6，并不是一个新鲜的东西，ES7、ES8已经赶脚了。但是，东西不在于新，而在于总结。每个学前端的人，身边也必定有本阮老师的《ES6标准入门》或者翻译的《深入理解ECMAScript6》。本篇主要是对ES6的一些常用知识点进行一个总结。如果你喜欢我的文章，欢迎评论，欢迎Star~。欢迎关注我的github博客

正文

我们会更具之前的罗列的内容进行一个深入的分析。

变量的新定义——let和const

在ES6没有被普及时，我们会用的变量定义的方法是var。其实，var对于一个刚刚接触js的人说，或许并不觉得怪异。但是，对于一个开发者而言，或许会在内心抨击它。因为它就是javascript的败笔之一，在其他语言看来的一个怪胎。那我们就来看看怪在何处呢？

1. 可以重复定义。不知道你的代码里面会不会出现这样子的代码，举例：

   var a = 10;
   var a = 11;

   或许，你会看到这样子的写法觉得没啥，那么你很厉(wei)害(xian)。其实，这样子的坏处不言而喻。在大型的工程化开发中，你定义一个a，我定义一个a，还有千千万万个你和我，这时，技术总监就该着急了。所以，这是var的第一点令人讨厌的地方，但是如果你会说不是有严格模式嘛。的确，严格模式做了一定的规范，但是我们不加以讨论。毕竟，这时ES6的地盘(^-^)。

2. 可随意修改。何为可随意修改？并不是指变量，而是指常量。举例：

   var PI = 3.1415926
   PI = 4.1415926

   从例子中，我们可以看到，PI是一个我们经常会使用的常量，是公认的不可变动的。但在javascript中并不是如此。那天，如果你的PI被你们公司新晋的实习生改了，可能你找错误都得找半天，但这可不是实习生的锅，也许，他并不知道这里是个常量。不过，这种情况也是玩笑话(^_^)。

3. 没有块级作用域。如果你连块级作用域都不知道的话，赶紧收藏一下^_^，回头再来看哈～，举例：

   if(true){
       var i = 10;
   }
   console.log(i);  //10

   相信，这变量不存在块级作用域给我们带来过不少麻烦吧。不知道啥时候，又得在循环中套一层闭包呢。而且，在非js开发者来说，可能觉得是个特(xiao)点(hua)。

所以，let和const就来拯救var了，如何一个拯救法呢？

1. 在同一个块级作用域中，不允许重复定义。那之前的例子来使用一下的话，你会发现浏览器报错了，如图：

   

2. const定义的变量不允许二次修改。还原一下之前的例子，如图：

   

   是不是再也不用担心之前的实习生啦，呦！！！

3. let和const定义的变量会形成块级作用域。直接上图，看看：

   

4. 它们定义的变量不存在变量提升，以及存在暂时性死区

   这个问题，我想举个例子可以更加方便的说明。首先，我们来看一题简单的笔试题：

   var a = 10;
   function hello(){
       console.log(a);
     	var a = 11;
     	console.log(a);
   }
   hello();

   我想这个答案不言而喻，是undefined和11。原因：就是第一个console时，下面定义的变量a被提升了，所以a变成了undefined，第二个的话，就比较好理解。这个例子，我想会给初学者带来不小的麻烦，和当初的我一样哈。

   使用let和const就会不一样，它们并不存在变量提升，如图：

   

函数的变化——箭头函数，剩余参数，参数默认值

何为箭头函数，我们先上例子：

export const addToCart = productId => (dispatch, getState) => {
  if (getState().products.byId[productId].inventory > 0) {
    dispatch(addToCartUnsafe(productId))
  }
}

这是，我从redux例子中摘取的一个片段，第一感觉就是『代码风格简洁』，整体代码规范很好，毕竟是示例代码么。但是会让人难以理解。因此，为了避免以后看不懂的尴尬，还是来好好聊聊这个神奇的东西吧。

其实，这个东西类似于python的lambda。但是，它的确特别适合js这门语言，就一个字「酷」。它的几个规则：

• 变量如果只有一个的时候，可以省略()
• 如果是只有一句返回语句时，可以直接省略{return }这一部分
• 因为它本身叫做arrow，所以每次都必须带上=>符号

如果你一开始不会写，那就必须得多练习，这样才能在以后的工作中真正谋求便利。

当然咯，它有好处，但是在使用的时候，也得注意它的禁区。注意事项：

1. 箭头函数不能作为构造函数。如图：

   

2. 箭头函数没有它自己的this值，箭头函数内的this值继承自外围作用域。如图：

   

3. 箭头函数没有arguments。这个我们直接测试一下就可以了，如图：

   

啥？没有arguments，那我如果正好要用到呢？这可咋办呢？下面再来说个有意思的改动——剩余参数。

什么叫剩余参数？别着急，看个例子就懂了。

const restParam = function(a, ...args){
    console.log(args);
};
restParam(1, 2, 3, 4);   //[2, 3, 4]

这里你会发现这个args变量似乎包含了之后输入的所有参数，除了a以外。所以，这就是所谓的剩余参数。其中，运用到了一个…这个符号。其实这个符号的用处非常的多，ES6中可以将它称为扩展符。那么，我们来看看在箭头函数中的运用。

当然，在使用剩余参数时，需要注意一个问题，就是剩余参数设置的位置。我们先来看张图：

所以，在使用剩余参数时，需要注意的是，将这部分放在所有参数的最后位置。其实，ES6还带来了另一个参数的变动——默认参数。或许，我们可以先看一下默认参数这个问题，我们之前是怎么处理的。场景：一般在设置延迟的时候，都会有一个时间的默认值，防止用户在没有设置的情况下使用，看看下面的例子：

function defaultParam(time){
    let wait = time || 1000;
  	setTimeout(() => {
        //...
    }, wait);
}

这种写法应该非常的常见，使用的也比较广泛。但是，使用ES6的语法的话，就会变成这样子，例子：

function defaultParam(time = 1000){
    setTimeout(() => {
        //...
    }, time);
}

看上去这样子的写法，会使得函数更加的简洁明了。

数组——解构赋值、二进制数组

说到解构赋值呢？大家千万别误解为这是数组的特性。不是的，对象也能够满足。只是觉得放在这边来写会比较好而已

解构赋值这个新特性，说实话是真的好用。我们可以先来看一个复杂一点的例子：

let [a, b , {name, age}, ...args ] = [1, 2, {name: 'zimo', age: 24}, 3, 4];
console.log(a, b, name, age, args); //1, 2, 'zimo', 24, [3, 4]

你会发现例子中，有一个特点——对仗工整。

这是解构赋值时，必须要去满足的条件——想要解构的部分，内容保持一致。这样才能保证完美解构。对于解构而言，左右两边的内容长度不一致，不会出问题。比如，当你右边内容多一点的时候，其实没啥事，你只需要保证你左边的结构有一部分是你想要的，举例：

let [a, b, c] = [1, 2, 3, 4, 5];
console.log(a, b, c); //1, 2, 3

这种叫做部分解构，左边也是一样的，对于多处来的部分，会变成undefined。举例：

let [a,b,c] = [1, 2];
console.log(a, b, c);  //1 2 undefined

解构赋值在使用过程中，也是有需要注意的部分：

1. 必须保证有赋值的过程。看个例子：

   

   你可以看到图中的例子，单独先声明了a和b，但是没有赋值的过程，会报错。

2. 左边内容部分的结构必须与右边保持一致。如图：

   

   这里两边的结构没有一致，如果是foo,bar的话，是可以正常解构的。但是这个例子的意图可能是想去解构foo中的值，但是写法上有一定的问题。

其实，解构也有没多种玩法：

1. 默认值的使用。由于之前说过的部分解构的情况出现，所以我们在解构时，可以使用默认值的形式。

   let [a, b = 10] = [1];
   console.log(a, b);  //1, 10

   在这个例子中b原先是undefined，但是设置了默认值的情况下，undefined的变量会被赋上默认值

2. 函数变量中使用解构。对于一个函数而言，它的参数也可能会是数组或对象，这是我们就可以使用解构赋值的方式

   function destructuring({name, age}){
       console.log(name, age);
   }
   destructuring({name: 'zimo', age: 21}); // zimo 21

解构赋值现在被使用的频率也是非常之大，好好掌握一下也是有必要的。

之后的话，我们可以聊一下二进制数组的概念。

何为二进制数组？其实，我们可以先来了解一下javascript的数组。熟悉js的人都知道，其实js的数组的性能并不高，它的本质是一个对象。之所以现在你看到数组在使用时速度还可以，是因为js的引擎在处理时，做了不同的优化。拿v8引擎举例的话，对于内部元素类型相同的数组在编译运行的时候，会使用c编译器。如果对于内部元素类型不同的时候，它会先将数组分离开来，然后再进行编译。具体可以查看深入 JavaScript 数组：进化与性能

所以，我们可以直接了解一下二进制数组的使用。二进制数组可以由Int8Array、Int16Array、Int32Array等形式组成，在整数方面，可用性较强。

const buffer = new Buffer(100000000);
const arr = new Int8Array(buffer);
console.time('test time');
for(let i = 0; i < arr.length; i++){
    arr[i] = i;
}
console.timeEnd('test time');

其实，现在二进制数组使用的频率并不多，ES6也仅仅是提出，后续还会对数组这一块进行一个更加详细的完善。

字符串——模版字符串、startsWith、endsWidth

在ES6中，对字符串也做了一定的改进。先来聊聊我们的新朋友——模版字符串。其实，在语言中，字符串有多种表示方式：单引号、双引号和倒引号。在javascript中，双引号和单引号都是一样的，这点与一些静态语言不一样。但是，往往有时候，对于字符串的拼接会使得开发者厌烦。如何解决呢？

ES6带来了解决方案——模版字符串。何为模版字符串呢？由倒引号包裹``，然后使用${}来包裹变量。我们可以来实践一下

const name="zimo";
const str = `My name is ${name}`;
console.log(str);  //My name is zimo

这样，我们就可以非常方便的在其中添加变量了。或许，你会觉得这样的拼接，使用普通的方式也可以非常好的完成。但是，在开发过程中，我们或许会碰到更佳复杂的情况，比如说，我们现在要去创建一个DOM元素，以及它的内部元素。这种情况，通常还会带有表达式。

const width = 100;
const height = 200;
const src = "http://www.example.com/example.png";
const html = `<div class="block" width="${0.5 * width}px" height="${height}"><img src="${src}" /></div>`;

往往这样子的元素在手动拼接的过程中，总是会出错，因此，使用模版字符串是一种既「高效」又「简洁」的方式。

有了模版字符串，你可以解决非常棘手的问题。那么，标题中带有的startsWith和endsWith又是起到什么作用呢？可能你会使用正则表达式，那么你就有可能不会使用到这两个API。

按照惯例，还是需要来介绍一下这两个API的。

startsWith：返回值为boolean型，然后去匹配字符串开头的部分，举个例子：

const str = "start in the head";
console.log(str.startsWith('start'));  //true
console.log(str.startsWith('head'));  //false

其实，这也是可以使用正则表达式来达到这一目的。还原上例：

const str = "start in the head";
console.log(/^start/.test(str));   //true
console.log(/^head/.test(str));   //false

其实，两者方式的区别基本上没有，但是正则表达式的功能更佳的完善。这个API仅仅在一些场景下起到一定的便捷。比方说，我们需要去匹配一个URL的协议头是什么时，我们往往需要用到这种方式。例子：

const url = "http://www.example.com";
if(url.startsWith('http')){
    console.log('this is http');
}else if(url.startsWith('https')){
    console.log('this is https');
}else if(url.startsWith('ws')){
    console.log('this is websocket');
}    //this is http

同理，endWith也是一样的效果。

endsWith：返回值是boolean类型，然后去匹配字符串的结尾。举个例子：

const str = "something in the end";
console.log(str.endsWith('end'));   //true
console.log(str.endsWith('something'));  //false

同样的，它也可以使用正则表达式来实现：

const str = "something in the end";
console.log(/end$/.test(str));   //true
console.log(/something$/.test(str));   //false

这种情况的使用场景是，往往我们需要为上传的文件准备图标，那么我们就可以根据后缀来确定图标。

const filename = "upload.jpg";
if(filename.endsWith('.jpg')){
    console.log('this is jpg file');
}else if(filename.endsWith('.png')){
    console.log('this is png file');
}else if(filename.endsWith('.webp')){
    console.log('this is webp file');
}   //this is jpg file

同时，字符串还增加了许许多多的东西，有兴趣的，可以自己去翻书本详细的了解

Iterator和for...of

Iterator的概念是迭代器。在ES6中，终于正式的添加了这个属性。迭代器，主要是一个集合类元素的遍历机制。何为集合类元素？最常见的就是数组，还有对象。迭代器可以帮助开发者完成遍历集合的过程。最开始javascript并没有设置接口，来自定义迭代器，但是从ES6开始，我们可以自定义迭代器了。在自定义迭代器之前，我们要清楚迭代器的作用有哪些：

• 为各种数据结构提供一个统一的、简便的访问接口
• 使得数据结构的成员能够按某种次序排列
• 在ES6中，迭代器主要供我们之后要讲述的for...of服务

迭代器，往往就是一个指针对象，不断调用，然后不断地指向下一个对象的过程，直到结束。ES6中，我们可以创建一个指针对象，然后调用next的函数，使得指针对象向下移动。同时，next函数会返回value和done，确定是否到达末尾。

同时，ES6还提供了Iterator接口——Symbol.iterator。首先，我们来看一下具备原生接口的集合类——数组，类数组对象、Set和Map。这样我们就可以直接调用它的接口来进行循环：

let arr = ['my', 'name', 'is', 'iterator'];
let iter = arr[Symbol.iterator]();
console.log(iter.next());   //{ value: 'my', done: false}
console.log(iter.next());   //{ value: 'name', done: false}
console.log(iter.next());   //{ value: 'is', done: false}

同时，定义iterator接口的数据结构可以轻松的使用for...of进行值的遍历

let arr = ['I', 'has', 'iterator'];
for(let item of arr){
    console.log(item);
}   //'I', 'has', 'iterator'

但是，如果没有定义iterator接口的数据结构就没有办法使用这种方式进行遍历，如图：

这时，我们又该如何呢？其实，针对一些可迭代的数据结构，我们是可以自定义迭代器的，例如：

let iteratorObj = {
    0: 'a',
  	1: 'b',
  	2: 'c',
  	length: 3,
 	[Symbol.iterator]: Array.prototype[Symbol.iterator]
}
for(let item of iteratorObj){
    console.log(item);
}  // 'a', 'b', 'c'

迭代器是一个非常实用的东西，不妨你也可以试试，同时去改善你的代码。

Generator和Promise

其实，这两个是比较难以理解的东西。如果只是粗浅的了解一下，还是有许多的新东西的。在ES6中，引入了generator和promise两个概念。可能在这之前，你已经使用过了，通过其他的类库实现的。那么，其实ES6中的新概念也是差不多的，只是标准化了而已。

generator，叫做生成器。可以说与iterator有点相似，同样是通过next函数，来一步步往下执行的。同时，它的定义时，所使用的是function*的标识符。还具备yield这个操作符，可以实现逐步逐步向下执行。我们来看个例子：

function* generator(){
  yield 1;
  yield 2;
  yield 3;
};

let generate = generator();

console.log(generate.next());  //{value: 1, done: false}
console.log(generate.next());  //{value: 2, done: false}
console.log(generate.next());  //{value: 3, done: true}
console.log(generate.next());  //{value: undefined, done: true}

这样子看起来，似乎就是迭代器的步骤。其实，iterator的接口，可以定义成这样子的形式。但是，generator的作用不仅仅如此。它就像一个状态机，可以在上一个状态到下一个状态之间进行切换。而一旦遇到yield部分，则可以表示当前是可以步骤的暂停。需要等到调用next方法才能进行下一步骤。同时，我们还可以使用上一步的结果值，进行下一步的运算。示例：

function* generator(){
  yield 1;
  let value = yield 2;
  yield 3 + value;
};

let generate = generator();

let value1 = generate.next();
let value2 = generate.next();
let value3 = generate.next(value2.value);
console.log(value1);  //{value: 1, done: false}
console.log(value2);  //{value: 2, done: false}
console.log(value3);  //{value: 5, done: true}

这样的话，就可以将value作为你第三步的参数值，进行使用。

之前说过，generator的next是需要自己调用的。但是，我们如何使它自己自动调用呢。我们可以使用for...of来自动调用next，就像迭代器一样。示例：

function* generator(){
  yield 1;
  yield 2;
  yield 3;
};
for(let value of generator()){
  console.log(value);
}   //1, 2, 3

其实，之前所讲的只是generator的基本使用。generator主要被使用在异步编程领域。因为我们之前所讲的特性，非常适合在异步编程中使用。当然了，我们也需要去提一下promise这个异步编程的功臣。

Promise，翻译过来叫做承诺。我们可以理解为一种约定。大家都知道异步编程的时候，我们一般会使用到回调函数这个东西。但是，回调函数会导致的问题，也非常的明显。示例：

callback1(function(data){
    //...
  	callback2(function(data1){
        const prevData = data;
      	//...
      	callback3(function(){
            //...
          	callback4(function(){
                //...
            });
        });
    });
});

回调函数，写多了之后我们会发现，这个倒金字塔会越来越深，而我们会越来越难以管理。

这时，或许promise会起到一定的作用。试想一下，为什么这几个回调函数都能在另一个回调函数之外进行？主要原因：

1. 每个回调函数，都会无法确定另一个回调函数会在何时会被调用，因为这个控制权不在当前这个程序之中。
2. 每个回调函数，都或多或少的依赖于上一个回调函数执行的时间和数据

基于这两点，我们就会发现，一旦你需要这样去编写代码，就必须保证你的上一个回调函数在下一个回调函数之前进行。我们还可以发现，它们之间缺乏一种约定，就是一旦上一个发生了，无论是正确还是错误，都会通知对应的回调函数的约定。

Promise，或许就是起到了这样的一种作用。它具备三种状态：pending、resolved、rejected。它们之间分别对应：正在进行、已解决、已拒绝等三种结果。一个回调函数会开始从pending状态，它会向resolved和rejected的两者之一进行转换。而且这种转换是不可变的，即一旦你从pending状态转变到resolved状态，就不可以再变到rejected状态去了。

然后，promise会有一个then函数，可以向下传递之前回调函数返回的结果值。我们可以写个promise示例：

new Promise((resolved, rejected) => {
  resolved(1);
}).then(data => {
  console.log(data);
}, err => {
  console.log(err);
}).catch(err => {
  console.log(err);
});  // 1

其实，只需要记住这样子的一种形式，就可以写好promise。Promise是一个比较容易书写的东西。因为它的形式比较单一，而且现在有许多封装的比较好的异步请求库，都带有Promise的属性，例如axios。

Promise，还带有其他的一些API，上面我们也使用到了一个。

• catch：用于指定发生错误时的回调函数。主要是我们之前说过Promise有个不可变的特性，所以，一旦这一个过程中发生错误，但是状态无法转变，只能在下一个流程中去捕获这个错误。因此，为了预防最后一个流程发生错误，需要在最后使用catch去捕获最后一个流程中的错误。
• all：用于将多个Promise实例包装成一个新的Promise实例。
  • 这个函数需要其中所有的Promise实例都变成Fulfilled时，才会将结果包装成一个数组传递给下一个Promise。
  • 如果其中有一个Promise实例变成Rejected时，就会将第一个Rejected的结果传递给下一个Promise
• race：也是用于将多个Promise实例包装成一个新的Promise实例。但是这个函数有所不同
  • 如果这个函数中，有一个Promise变成Fulfilled时，它就会将结果传递给下一个Promise
• resolve：它会将一个当前对象转化为Promise对象
• reject：返回一个出错的Promise对象

Promise可以和之前所讲的Generator一起使用，我们可以看一下使用场景：

通过Generator函数来管理流程，遇到异步操作，就使用Promise进行处理。

function usePromise(){
  return new Promise(resolve => {
    resolve('my name is promise');
  });
}

function* generator(){
  try{
    let item = yield usePromise();
    console.log(item);
  }catch(err){
    console.log(err);
  }
}

let generate = generator();
generate.next().value.then(data => {
  console.log(data);
}, err => {
  console.log(err);
}).catch(err => {
  console.log(err);
});   //my name is promise

或许，你还可以写出更加复杂的程序。

Class和extends

最后要聊的一个主题就是class。相信抱怨javascript没有类的特性数不胜数。同时，还需要去了解js的类继承式概念。那么，ES6也带来了我们最欢迎的class module部分。我们就不介绍之前我们是如果去构建对象的了(好像是构造函数)。

那么，我们可以来看一下，ES6给我带来的新变化：

class Animal{
  constructor(name){
      this.name = name;
  }

  sayName(){
      return this.name;
  }
}

const animal = new Animal('dog');
console.log(animal.sayName());  // 'dog'

似乎这样子的形式比之前的构造函数的方式强对了。我们可以理解一下这个结构：

• 其内部的constructor：指向的就是整个类的constructor
• 其内部的函数：这些函数的定义在类的原型上面

因此，上面那个其实可以写成原先的：

function Animal(name){
    this.name = name;
}
Animal.prototype.sayName = function(){
    return this.name;
}

其实，就是class在ES6中得到了封装，可以使得现在的方式更加的优美。

之后，我们简单了解一下继承这个概念吧。

任何的东西，都是需要继承的。因为我们不可能都是从头去写这个类。往往是在原有类的基础之上，对它进行完善。在ES6之前，我们可能对构造函数完成的是组合式继承。示例：

function Animal(name){
  this.name = name;
}
Animal.prototype.sayName = function(){
  return this.name;
}
function Dog(name, barking){
  Animal.call(this, name);
  this.barking = barking;
}
Dog.prototype = new Animal();
Dog.prototype.constructor = Dog;
Dog.prototype.makeBarking = function(){
  return this.barking;
}
const dog = new Dog('zimo', '汪汪汪');
console.log(dog.makeBarking());   //汪汪汪
console.log(dog.sayName());  //zimo

这样子的组合式继承书写起来，比较麻烦，需要重新去对每个元素设置，然后还要重新定义新类的原型。那么，我们可以来看一下ES6对于继承的封装：

class Animal{
    constructor(name){
        this.name = name;
    }
  
  	sayName(){
        return this.name;
    }
}
class Dog extends Animal{
    constructor(name, barking){
        super(name);
      	this.barking = barking;
    }
  	
  	makeBarking(){
        return this.barking;
    }
}

这样子，就可以轻松的完成之前的组合式继承步骤了。如果你对extends的封装感兴趣的话，不妨看一下这篇文章javascript之模拟类继承

总结

在这里ES6的内容只是总结了部分，大致可以分为这么几个部分：

• 变量定义——let和const
• 函数的变化——箭头函数、剩余参数
• 数组的变动——解构，展开符
• 字符串——模版字符串、startsWith、endsWith
• Iterator和for...of
• Generator和Promise
• Class和extends

希望，你可以从这些内容中对ES6多一些了解，同时，如果你还想深入ES6进行了解的话，最直接的方式就是看书。希望你的代码写的越来越优雅。

如果你对我写的有疑问，可以评论，如我写的有错误，欢迎指正。你喜欢我的博客，请给我关注Star~呦。大家一起总结一起进步。欢迎关注我的github博客

前言

最近，公司在做系统，选型时选择了vue作为前端开发的部分。做了一个demo，随便总结一下vue的一些使用内容。其实，从react映射到vue，一点也不容易。总是会有多多少少的**转变不过来。不过大体上手还是挺快的。这样一来，算是集齐神龙了。三个框架都用了一遍。用来用去还是觉得react顺手一点。

前言

今天刷了一下网易往年的编程笔试题，之后我将做个总结。其实，对于一个前端开发的人来说，算法是一个可有可无的东西。因为你或许一辈子都不需要接触这个东西，至于界面打交道。但是，你的职业水平也会止步于此。我是一个热衷于算法的少年，由于需要模拟控制台的输入与输出，而js的实现又非常的拙劣，所以，我会选择python。一门与js一样神奇的语言。

第一题

题目：小易有一个圆心在坐标原点的圆，小易知道圆的半径的平方。小易认为在圆上的点而且横纵坐标都是整数的点是优雅的，小易现在想寻找一个算法计算出优雅的点的个数，请你来帮帮他。
例如：半径的平方如果为25
优雅的点就有：(+/-3, +/-4), (+/-4, +/-3), (0, +/-5) (+/-5, 0)，一共12个点。

输入描述:
输入为一个整数，即为圆半径的平方,范围在32位int范围内。
输出描述:
输出为一个整数，即为优雅的点的个数
输入例子1:
25
输出例子1:
12

理解：其实这道题我是这么考虑的类似与坐标轴上的四个象限，只需要去考虑其中的一个象限，但是象限的端点处只能取其中之一，如图：

然后就可以写py代码了：只要在这条曲线上的点，然后在总和中乘以4倍，即是返回值

代码部分

from math import sqrt

def main():
    inputN = int(raw_input())
    sum = 0
    i = 1
    while i * i <= inputN:
        tem = sqrt(inputN - i * i)
        if int(tem) == tem:
            sum += 1
        i += 1
    print sum * 4

if __name__ == '__main__':
    main()

第二题

题目：小易来到了一条石板路前，每块石板上从1挨着编号为：1、2、3.......
这条石板路要根据特殊的规则才能前进：对于小易当前所在的编号为K的 石板，小易单次只能往前跳K的一个约数(不含1和K)步，即跳到K+X(X为K的一个非1和本身的约数)的位置。 小易当前处在编号为N的石板，他想跳到编号恰好为M的石板去，小易想知道最少需要跳跃几次可以到达。
例如：
N = 4，M = 24：
4->6->8->12->18->24
于是小易最少需要跳跃5次，就可以从4号石板跳到24号石板

输入描述:
输入为一行，有两个整数N，M，以空格隔开。
(4 ≤ N ≤ 100000)
(N ≤ M ≤ 100000)
输出描述:
输出小易最少需要跳跃的步数,如果不能到达输出-1
输入例子1:
4 24
输出例子1:
5

理解：这一题其实是一题动态规划类的算法题，其实只要保证走x时，i+x是最小的，那么最后N，M之间的步数也会是最小的。下面我们来看一副图片理解一下：

看着图解之后，我们再来写一些这个动态规划的代码理解一下，py代码：

def factor(number):
    res = []
    i = 2
    while i * i <= number:
        if number % i == 0:
            res.append(i)
            if number / i != i:
                res.append(number / i)
        i += 1
    return res

def main():
    arr = raw_input().split(' ')
    N = int(arr[0])
    M = int(arr[1])
    dp = []
    for i in range(0, M+1):
        dp.append(9999999)      #fill array
    dp[N] = 0
    for i in range(N, M):
        if dp[i] == 9999999:
            dp[i] = 0        #9999999 mean can not to reach, set 0 mean to reduce space
            continue
        temp = factor(i)
        for  item in temp:
            sum = item + i
            if sum <= M:
                dp[sum] = min(dp[sum], dp[i]+1)    # get min dept
    if dp[M] == 0:
        print -1
    else:
        print dp[M]


if __name__ == '__main__':
    main()

总结

算法题还是比较好玩的，即使是前端开发的人也应该时常练习，时常刷一下leetcode和oj平台

前言

在网页中，我们常常会遇到布局这么一个概念。而对于一种相同的布局，可以使用不同的css来完成，这也是css有趣的地方。今天我们要讨论地布局就是最常见的三栏布局（也是面试中面试官喜欢问的话题）。

正文

其实，三栏布局可以有4种实现方式，每种实现方式都有各自的优缺点。

1.使用左右两栏使用float属性，中间栏使用margin属性进行撑开，注意的是html的结果

<div class="left">左栏</div>
<div class="right">右栏</div>
<div class="middle">中间栏</div>

.left{
  width: 200px;height: 300px; background: yellow; float: left;    
}
.right{
  width: 150px; height: 300px; background: green; float: right;
}
.middle{
  height: 300px; background: red; margin-left: 220px; margin-right: 160px;
}

缺点是：1. 当宽度小于左右两边宽度之和时，右侧栏会被挤下去；2. html的结构不正确

2. 使用position定位实现，即左右两栏使用position进行定位，中间栏使用margin进行定位

<div class="left">左栏</div>
<div class="middle">中间栏</div>
<div class="right">右栏</div>

.left{
    background: yellow;
    width: 200px;
    height: 300px;
    position: absolute;
    top: 0;
    left: 0;
}
.middle{
    height: 300px;
    margin: 0 220px;
    background: red;
}
.right{
    height: 300px;
    width: 200px;
    position: absolute;
    top: 0;
    right: 0;
    background: green;
}

好处是：html结构正常。

缺点时：当父元素有内外边距时，会导致中间栏的位置出现偏差

3. 使用float和BFC配合圣杯布局

将middle的宽度设置为100%，然后将其float设置为left，其中的main块设置margin属性，然后左边栏设置float为left，之后设置margin为-100%，右栏也设置为float：left，之后margin-left为自身大小。

<div class="wrapper">
    <div class="middle">
        <div class="main">中间</div>
    </div>
    <div class="left">
        左栏
    </div>
    <div class="right">
        右栏
    </div>
</div>

.wrapper{
    overflow: hidden;  //清除浮动
}
.middle{
    width: 100%;
    float: left;
}
.middle .main{
    margin: 0 220px;
    background: red;
}
.left{
    width: 200px;
    height: 300px;
    float: left;
    background: green;
    margin-left: -100%;
}
.right{
    width: 200px;
    height: 300px;
    float: left;
    background: yellow;
    margin-left: -200px;
}

缺点是：1. 结构不正确 2. 多了一层标签

4. flex布局

<div class="wrapper">
    <div class="left">左栏</div>
    <div class="middle">中间</div>
    <div class="right">右栏</div>
</div>

.wrapper{
    display: flex;
}
.left{
    width: 200px;
    height: 300px;
    background: green;
}
.middle{
    width: 100%;
    background: red;
    marign: 0 20px;
}
.right{
    width: 200px;
    height: 3000px;
    background: yellow;
}

除了兼容性，一般没有太大的缺陷

总结

一般现在使用较多的都是flex布局，这种布局是真的好用，哈哈

前言

这篇文章是翻译了yslow 35rules的一部分，因为本人重来没有做过这方面的优化，因此，来自原文的翻译可以更加清晰的来解释这个问题。

正文

1. CSS expressions
   CSS expressions are a powerful (and dangerous) way to set CSS properties dynamically. They were supported in Internet Explorer starting with version 5, but were deprecated starting with IE8. As an example, the background color could be set to alternate every hour using CSS expressions:

   使用css表达式去设置css动态属性是一种有力的(却又危险的)行为。它们在IE5浏览器开始被支持，但在IE8开始被启用。举个例子：背景颜色的值可以通过css表达式来计算每小时的值，将其赋值给背景颜色：

   background-color: expression( (new Date()).getHours()%2 ? "#B8D4FF" : "#F08A00" );

   As shown here, the expression method accepts a JavaScript expression. The CSS property is set to the result of evaluating the JavaScript expression. The expression method is ignored by other browsers, so it is useful for setting properties in Internet Explorer needed to create a consistent experience across browsers.

   这里展示的例子中，表达式可以接受一个javascript表达式。css属性通过计算javascript表达式来进行设置。表达式被其他浏览器忽略，因此在IE浏览器中设置属性以在浏览器之间创建一致的体验是非常有用的。

   The problem with expressions is that they are evaluated more frequently than most people expect. Not only are they evaluated when the page is rendered and resized, but also when the page is scrolled and even when the user moves the mouse over the page. Adding a counter to the CSS expression allows us to keep track of when and how often a CSS expression is evaluated. Moving the mouse around the page can easily generate more than 10,000 evaluations.

   表达式的问题是它们被计算的过于频繁超过了大多数人的期望。不仅当页面被重绘和重排时它们被重新计算，而且当页面滚动，甚至当用户移动鼠标经过页面时，它们也会被重新计算。使用css表达式增加一个计算器，将会导致无论何时何种方式css表达式都会被重新计算。移动鼠标划过页面的行为可以轻松地使得表达式被重新计算超过10000次。

   One way to reduce the number of times your CSS expression is evaluated is to use one-time expressions, where the first time the expression is evaluated it sets the style property to an explicit value, which replaces the CSS expression. If the style property must be set dynamically throughout the life of the page, using event handlers instead of CSS expressions is an alternative approach. If you must use CSS expressions, remember that they may be evaluated thousands of times and could affect the performance of your page.

   减少你的css表达式重复计算次数的方式是去使用一次表达式，那么在第一次的时候，表达式将会被计算，作为一个普通的css表达式的替换的值，来设置css样式属性。如果这个样式属性一定要在整个页面周期中被动态调整的话，可以使用事件处理来代替css表达式的使用。如果你一定要使用css表达式的话，请记住它们有可能被重新计算成千上万次，并且可能影响你的页面性能。

总结

css表达式这个东西，其实说到底js可以来实现的，还是js实现起来轻松方便

前言

前端框架的变迁，体系架构的完善，使得我们只知道框架，却不明白它背后的道理。我们应该抱着一颗好奇心，在探索框架模式的变迁过程中，体会前人的一些理解和思考

本篇将讲述的是前端框架变化过程中的一些思考，前端框架模式的变化：从无到有，从MVC(Flux或者Redux)->MVP->MVVM。这段变化的过程，会让人不断琢磨，每次的变化，都是一次大的进步。现在在前端的框架都是MVVM的模式，还有像Flux和Redux之类的MVC变种——独特的单向数据流框架。如果你喜欢我的文章，欢迎评论，欢迎Star~。欢迎关注我的github博客

正文

其实，这些框架模式我们平时都会有所接触。它遵循着将整体应用的功能块进行分离的原则，对开发者开发软件进行一定的规范，以保持系统的稳定以及可维护性。

讲述前端框架变迁的过程中，我们可以通过梳理最近几十年的前端发展时间线，来深入分析前端的从无到有，从有到优的过程。

最初的时代

最初的时代，应该是web1.0时代吧。当时，开发者们并没有前端的概念。开发一个应用，或许只要5个人的小团队，就能够很快的配置出可运行的环境。而开发的语言使用的也是最初的JSP、ASP和PHP。拿JSP举例的话，当时系统的整体架构图可能是这样子的：

记得在学校的时候，最早搭建系统就是使用的这种架构。

这种架构的好处是简单快捷。使用Eclipse+tomcat就可以之间把程序跑起来，以及jsp的强大功能，足够满足小应用的开发。

但是，同样缺点也非常明显：

1. 业务体系增大，调试困难：随着业务体系的增大，后台service也会逐步膨胀，大致需要建设一个开发服务器进行存放，这会导致一个问题就是前端无法在本地进行调试，每次进行修改之后，都必须上传到开发服务器进行测试（况且开发服务器可能本身就不稳定）。

2. JSP代码难以维护：或许人少的时候，学JSP挺简单的。但是，一旦团队人数增多，JSP内参杂的业务逻辑也会逐渐增加，这会导致的是JSP本身难以维护。

为了让开发更加的便捷，代码变得更加的可维护，同时使得前后端的职责加以分离。这时，我们或许会考虑改变一下开发模式，将后端MVC化，而前端的展示则以模板的形式进行嵌套。典型的框架就是Spring、Structs。整体的框架，如图所示：

使用这样子的架构，复杂度被降低了，职责也会比较清晰。这个时代被称为后端的MVC时代。这个时候，前后端开始形成了一定的分离。前端只需要在本地编写好相应的页面，然后交给后端开发的人，让他们可以根据模板进行一个嵌套。这是前端只完成了后端开发中的view层内容。淘宝的早期使用的就是这种模式。现在仍有小部分创业型的公司会使用这种方式进行开发，主要是节约用人成本。

但是，同样的这种模式存在着一些：

1. 前端页面开发效率不高：其实，早期的时候根本也没啥前端开发工程师，有的只是页面仔。更多公司可能也有后端的人使用js在写页面的。因此，问题就暴露了出来，前端所做出来的页面需要放到后端环境去运行，使得前端开发的效率并不是特别之高，因为对于后端环境的依赖程度比较大。

2. 前后端职责不清：由于前端并未做太多的工作，以至于后端的开发体量比较庞大。就拿路由管理来举例子，本来路由管理可以由前端开发的人员来进行开发和管理。但是，使用这种架构时，后端需要去维护一个庞大的路由表，增加了后端的开发量。

前端的第一个春天

有个东西带来了前端的第一个春天——AJAX。自从Gmail的出现，ajax技术开始风靡全球。许多公司和开发者都不断地利用它做实验。有了ajax之后，前后端的职责就更加的清晰了。因为前端可以通过Ajax与后端进行数据交互，因此，整体的架构图也变化成了下面这幅图：

通过ajax与后台服务器进行数据的交换，前端开发的人员，只需要开发自己页面这部分的内容，数据可由后台进行提供。而且ajax可以使得页面实现部分刷新，极大的减少了之前需要反复开发的页面。这时，才开始有前端工程师开始慢慢从事前端。同时前端的类库也慢慢的开始发展，最著名的就是jQuery了。

但其实，这样子的架构中还是存在一定的问题——前端缺乏一种可行的开发模式。整体的内容都杂糅在一起，一旦应用增大，就会导致难以维护了。举个例子，当图书少的时候，我们就算随意放置，整理起来都比较方便；但是，一旦具有像图书馆一样多的图书时，必须有一种统一的管理方式。同样的，前后端分离之后，前端的开发业务逐渐增多，责任也愈加的巨大，开发者急需一种比较好的框架来规范整个应用。因此，前端的MVC也随之而来。

前后端分离后的架构演变——MVC、MVP和MVVM

MVC

前端的MVC应该与后端类似，具备着View、Controller和Model。

Model：负责保存应用数据，与后端数据进行同步

Controller：负责业务逻辑，根据用户行为对Model数据进行修改

View：负责视图展示，将model中的数据可视化出来。

理论上，他们三者形成了一个如图所示的模型：

这样的模型，在理论上是可行的。但往往在实际开发中，并不会这样去操作。因为开发的过程需要灵活，而这种模式并不满足灵活的条件。例如，一个小小的事件操作，都必须经过这样的一个流程，那么开发就不再便捷了。

在实际场景中，我们往往会看到另一种模式，如图：

这种模式在开发中更加的灵活，backbone.js框架就是这种的模式。

但是，这种灵活，也会导致一些严重的问题：

1. 数据流混乱。或许，你还不一定能够很好的理解，何为数据流混乱。那么，我们来看一副图：

这幅图中，特别是model和view这一块的数据交互，感觉看起来像是连连看，非常的混乱，而且维护起来非常麻烦。这就是灵活开发带来的后遗症。拿backbone举个例子，backbone将Model的set和on方法暴露出来，方便外部对其进行直接操作。

2. View比较庞大，而Controller比较单薄：由于很多的开发者都会在view中写一些逻辑代码，逐渐的就导致view中的内容越来越庞大，而controller变得越来越单薄。

既然有缺陷，就会有变革。前端的变化中，好像少了MVP的这种模式，或许是因为Angular早早地将MVVM的框架模式带入了前端，这也许就是Google工程师的智慧吧。那我们还是需要来了解一下MVP这种模式，虽然前端开发并不常用，但是在安卓等native开发时，开发者都会考虑到它的。

MVP

MVP与MVC很接近，P指的是Presenter，presenter可以理解为一个中间人，它负责着View和Model之间的数据流动，防止View和Model之间直接交流。我们可以看一下图示：

我们可以通过看到，presenter负责和Model进行双向交互，还和View进行双向交互。这种交互方式，相对于MVC来说少了一些灵活，VIew变成了被动视图，并且本身变得很小。虽然它分离了View和Model。但是应用逐渐变大之后，缺陷也会随之暴露。

缺陷：

由于大部分逻辑都需要presenter去进行管理，从而导致presenter的体积增大，难以维护。如果需要去解决这个问题，或许可以从MVVM的**中找到答案。

MVVM

首先，何为MVVM呢？MVVM可以分解成(Model-View-VIewModel)。ViewModel可以理解为在presenter基础上的进阶版。废话不多说，先上图例：

在这里View是ViewModel的外在显示，和ViewModel的数据是同步的。一旦View中的数据发生变化，会自动同步到ViewModel，然后ViewModel可以将变化的数据传给Model；反过来也是一样的，Model中的数据一旦发生改变，就会将值传给ViewModel，而ViewModel也会同步更新到view中。现在的框架实现这样的形式，各有各的不同。主要的三个框架angular2、vue、react都是实现了这样子的模式。

这种的好处就是View和Model之间被分离开来。view不知道model的存在，viewmodel和model也觉察不到view。事实上，model也完全忽略viewmodel和view的存在。这是一个非常松散耦合的设计。

但它也不是所用地方都适用的，例如，后端开发是适用的。因为网络资源成本过高，开发成本过高导致的。

Flux或者Redux

讨论完上面的三种框架，我们再来看一下Flux。之前，我们在讨论MVC的时候，提及过MVC最主要的缺点就是数据流混乱，难以管理。但是，Facebook却在这个基础上对MVC做出了改变，那就是——单向数据流。只要将数据流进行规范，那么原来的模式还是大有可为的。

我们可以来看一下，Flux框架的图示：

从图中，我们可以看到形成了一条Action到Dispatcher，再到Store，之后是View的，一条单向数据流。在这里Dispatcher会严格限行我们操作数据的行为，而Store也不会暴露setter接口，让其随意被修改。最终，这样的一套框架在大多数场景下，比MVC更加完美。（细节部分我们不做探究，有兴趣可以研究一下Redux源码，也就近千行代码）。

总结

我们依据前端发展为时间线，整理了前端整体框架的从无到有，从有到优的过程。

1. 最初的时代——web1.0
2. 前端的春天——Ajax
3. 前端的框架——MVC、MVP、MVVM
4. MVC 的变种——FLux

希望这些能够帮你理解现在的前端，理解框架之间的卓越点。同时也希望大家一起进步，一起成长。

如果你对我写的有疑问，可以评论，如我写的有错误，欢迎指正。你喜欢我的博客，请给我关注Star~呦。大家一起总结一起进步。欢迎关注我的github博客

前言

在面试过程中，不免会被问到网页优化的问题。对于一个网页的好坏，取决于访问速度的快慢。往往1秒钟的差距，会流失大量的潜在客户。所以，优化网页是前端开发人员的必备技能。优化的问题也一致探讨，最著名的则是Yahoo的35军规，它总结了网页在大部分情况下如何去进行优化措施。但往往规则靠死记硬背是不现实的，只有动手实践才能真真的掌握。

正文

往往在真实的生产环境中，前端花费大部分的时间去加载资源，下载资源。所以，加快网页加载速度最为有效的方法是减少http请求。

1. 减少css标签、javascript标签

以前，我们经常可以在网站后台看到如下的场景：

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta http-equiv="X-UA-Compatible" content="ie=edge">
    <link rel="stylesheet" href="example1.css">
    <link rel="stylesheet" href="example2.css">
    <link rel="stylesheet" href="example3.css">
    <link rel="stylesheet" href="example4.css">
    <link rel="stylesheet" href="example5.css">
    <title>example</title>
</head>
<body>
     // ...dom内容
    <script src="example1.js"></script>
    <script src="example2.js"></script>
    <script src="example3.js"></script>
    <script src="example4.js"></script>
    <script src="example5.js"></script>
</body>
</html>

在这样的情况下，往往页面的加载速度会降低，一般页面大概适合2-3个script文件进行加载，所以，我们第一步要做的就是，将这么多的资源文件适当的合并起来，css文件也是如此。

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta http-equiv="X-UA-Compatible" content="ie=edge">
    <link rel="stylesheet" href="bundle.css">
    <title>example</title>
</head>
<body>
//...
    <script src="bundle1.js"></script>
    <script src="bundle2.js"></script>
</body>
</html>

在现在的工业化开发中，都往往会用到打包工具，像webpack、gulp等，对文件进行打包，分块，部分加载等。因此，这一类的问题造成的影响正在逐步的降低。

2. 图片资源的加载

往往在大型项目的开发中，对于图片资源的处理是一件很费力的事情，我们单从减少http请求的角度来，看待图片请求的问题，最简单的方法往往是使用雪碧图的方式。如图：

在写css样式时，会使用background-image和background-position去加载各种背景图片资源。但是，如果将这些资源进行合并是能减少整体网页的请求次数，加载网页性能的。

3. 使用base64的图片资源

首先，有人会疑问何为base64的图片资源。通常，图片在网络传输中，都是以base64加密的方式进行传输的。因此，我们为了减少不必要的网络请求，我们可以将一下图片进行base64加密，然后直接放到img标签的src中,或者图片背景资源的url中。

<img src="data:image/gif;base64,R0lGODlhHAAmAKIHAKqqqsvLy0hISObm5vf394uLiwAAAP///yH5B…EoqQqJKAIBaQOVKHAXr3t7txgBjboSvB8EpLoFZywOAo3LFE5lYs/QW9LT1TRk1V7S2xYJADs="

    注：这种情况的使用，往往是在图片比较小的情况下，如果图片较大的话，往往会增加整体资源的体积，而使得下载资源时间增长。

4. 使用image map(感觉不常用，本人没使用过)
   有些在线的网站可以将图片制作成map，然后在html中使用，如图：

<img src="image.png" alt="Website map" usemap="#mapname" />
<map name="mapname">
  <area shape="rect" coords="9,372,66,397" href="http://en.wikipedia.org/" alt="Wikipedia" title="Wikipedia" >
</map>

这种图片处理的方式，也与雪碧图的原理差不多，可以减少对图片资源的请求

总结

在优化网站性能的方式有很多种，这只是第一篇——减少http请求的方式。

前言

富文本编辑器，是写文章的利器。对于一个网站来说，好的富文本编辑器更是锦上添花

本篇为移动端富文本实践篇的前言篇，文章主要介绍了现状，项目起因，以及接下来篇章的主要内容概要。如果你对这个话题，或者这个项目感兴趣，不妨先访问一下github项目。如果你看了之后，表示喜欢，那么，请动动你的小手点一下Star，表示对我们的支持。同时，如果你对项目的使用有任何疑问，或者建议，可以在issues里面给我们提出你宝贵的意见。我们也将不断丰富与完善整个项目，打造出一个优质的富文本项目。github项目地址

正文

每个项目都有初衷，也同样会有目标。本来实践篇的文章都是上来就是干，直接丢代码。但是，本篇只分析一下，在项目初期的考量。只有清楚现有的项目中的不足，才能够优化它们的不足，打造出一款优质的项目。那么，我们首先要来清楚一下富文本编辑器的现状。

现状概述：

现在市面上，好的富文本编辑器都得数不胜数。强大如ueditor，功能齐全，被广泛运用；小如Pell，整体大小才不到1kb，风格单一，简约。但是这些富文本编辑器大多数是针对PC端的，移动端的却有点少，而且不精。项目不多的原因，就是移动端其实在这方面需求并不多，而且这一方面的产品少。唯一只有简书和知乎等产品上的富文本编辑器，小而精，风格统一，简约。尤其是，像简书的移动端富文本编辑器，体验良好，在图片等处理上面，下了很大的功夫。可是，由于是其公司产品，并未有开源的。现在移动端的流量逐渐增加，文章的产出不断增加，移动端的富文本编辑器需求也会不断增加。或许，某个晚上，你就会躺在床上，使用手机码字，写心得和感悟呢。

项目初衷：

在今年的五月份，我们一起接手了一个外包项目。其中，就需要使用到移动端的富文本编辑器，主要是让用户来描述自己的需求。可是，在github上面，真正移动端的富文本编辑器并没有太多，而且大多都没有图片处理的部分。自从那一次项目之后，我们粗涉富文本编辑器，里面的坑是一个接着一个。后来，我与我安卓的朋友萌生了一个自己开发一个类似于简书等优质的移动端富文本应用的想法。这个项目的目的是打造一个功能基本齐全的，可配置不同主题风格的富文本编辑器。

目前，整个项目已被放到github网站上面，版本属于v1.0版，后续还会进行不断的优化。github项目地址

内容概要：

或许，真正做富文本开发的人员并不多，网上也并未找到比较详尽的开发方案等，大多数时候都是自己摸着石头过河。同时，也总结了一下自己在开发过程中的一些经验，下面的文章是接下来篇幅内容的一个概要：

1. 移动端富文本实践篇(一)：富文本开发之前的一些基础知识普及，以及实践中的大致应用。

2. 移动端富文本实践篇(二): 本篇的内容，主要是讲述一些dom元素的事件的监听情况，以及一些安全措施

3. 移动端富文本实践篇(三)：本篇内容主要是讲一下文章中文字部分的处理，如'bold'、'italic'、'blockqueto'、'h1'等，以及分割行的插入和链接的插入和修改等模块的代码分析。

总结

本节并没有太多的干货，更多的是我们做项目的初衷。现在github社区上面，开源项目千千万万，我们更应该明确项目的目标与初衷，才能在一众项目中脱颖而出。相信，并且希望我们能够一同学习，一同进步。

最后，如果你对我写的有疑问，可以与我讨论。如果我写的有错误，欢迎指正。你喜欢我的博客，请给我关注Star~呦。大家一起总结一起进步。欢迎关注我的github博客。同时也希望你关注我们的项目，github项目地址，谢谢支持

前言

上篇写到：
在网页性能优化的过程中，我们可以通过在服务器配置cdn或者缓存来达到优化性能的作用。
cdn有些专门的网站提供这类的服务，而缓存在整个过程中起到很大的作用，相信我们之后还能了解这个东西的用处。

正文

这篇文章主要了解一下压缩文件，以及一些写法上的规范来优化网页的性能。

1. gzip压缩

   gzip压缩是http协议上的gzip压缩编码技术。首先，我们应该要清楚的是压缩可以达到怎样的目的。比如说纯文本内容进行压缩之后，大小可以缩小大概40%左右。大小减小了最直接的就是传输的速度将会加快，以及流量将会减少。尤其是对于大流量类网站来说，压缩文件内容大小，减少流量是很有必要的(毕竟省钱嘛！)，另一方面，压缩过的内容将减少存储空间。

   那一般gzip压缩需要如何实现呢？一般会在www服务器上配置服务，然后将压缩过的文件传输到客户端，由客户端进行内容的显示。比方说nginx服务器就可以进行gzip配置，默认会压缩text/html的文件进行压缩，当然了，对于图片资源也是可以进行压缩的，这需要进行一下配置。

   //first to open gzip service
   gzip on
   gzip_http_version 1.0;
   gzip_disable "MSIE [1-6].";
   gzip_types text/plain application/x-javascript text/css text/javascript application/x-httpd-php image/jpeg image/gif image/png;

   需要注意的是：

   1. gzip_http_version默认是1.1的，即只有http/1.1的协议才能进行gzip压缩。如果使用了proxy_pass进行反向代理，那么nginx和后端的upstream server之间是用HTTP/1.0协议通信的。如果使用nginx通过反向代理做Cache Server，前端的nginx没有开启gzip，且后端的nginx上未设置gzip_http_version为1.0，那么Cache的url将不会被gzip压缩。
   2. IE6对于部分的gzip压缩文件由兼容性的问题(其实，这个可以不谈，因为IE6感觉都不用了)。

   在HTTP1.1中使用gzip的方式：
   .
   请求头：

   Accept-Encoding: gzip, deflate

   响应头：

   Content-Encoding: gzip

2. css、script标签位置规范的问题
   如何正确的使用css标签和script标签？css标签应该放在head标签内，而script标签应该放在body标签的末尾。

   <html>
       <head>
           <title>citerion</title>
           <link href="./test.css" ref="stylesheet"/>
       </head>
       <body>
            <!--dom内容-->
            <script src="./test.js"></script>
       </body>
   </html>

   在搞清楚为什么这两个标签要这么去放置之前，我们先来了解一下网页文件的渲染过程：

   • 处理html标签构成DOM树
   • 处理css标签构成CSSOM树
   • 处理js文件，对于DOM树的样式进行重新计算
   • 将DOM树和CSSOM树进行合并成渲染树
   • 根据渲染树，计算每个节点的布局
   • 最后将渲染树绘制在浏览器界面上

   
   这里有还有两个点需要搞清楚的是：

   1. css在解析过程中是不会阻塞DOM树的处理的。但是，一旦将css文件放到html尾部的时候，整个情况就变了。在html文件的末尾，DOM树几乎已经处理完成了，但是，这个时候刚刚解析到css的标签，需要下载css文件，以及构建CSSOM树，这些都是需要时间的。如果在头部时，DOM树和CSSOM树可以一起处理；反之，在尾部，需要等待CSSOM的处理，整个DOM渲染的进程会被阻塞(这样做是为了避免渲染树的重新排版)，这样就会导致性能的下降。
   2. js文件又是另外的一种情况。js文件在处理过程中，会阻塞DOM的处理。如果将js放在头部，那么将会影响DOM的处理，而CSSOM的渲染完成之后，也将会影响整个DOM构建的时间。如果放在尾部，就可以节省之前阻塞的部分时间，这样可以进行网页的优化。

总结

该篇总结了优化网页的两种方法：1. gzip压缩 2. css文件放在头部、js文件放在尾部

前言

在上一篇文章中，我们以及聊过了减少http请求的四个方法:

1. 减少css和JavaScript
2. 雪碧图
3. image base64
4. image map

正文

今天，我们来了解一下服务器相关方面，我们可以做的优化

首先，我们必须知道一个神器——CDN。它在现在的网站中发挥着无尽的作用。CDN（Content Delivery Network）,即基于内容的分布式分发网络，它帮助现在大多数网站进行静态资源的部署。正如，军规中提到的网络请求中，有80%-90%的响应时间是在资源下载中度过的，而CDN的机制可以帮助我们更快的获取到这些静态的资源。

首先，我们需要清楚为什么需要CDN这个东西，仅仅只是帮助网站提高加载速度么！其实，不仅仅如此，试想一下一些大型的网站（全国、甚至是全世界），访问的基数非常之大，静态资源的访问频繁，会使得主站服务器吃不消，即使给单个端口增至最大的带宽，也无法满足需求。因此，CDN在这里扮演者重要的角色。

CDN的网络结构大概是中心节点加上边缘节点组成的。这就相当于每个人访问网站时，如果网站部署了CDN，那么就会向最近的CDN服务器请求静态资源，而不是想传统的网站一样，只会去访问主站服务器。使用CDN时，还可以对内容进行缓存，以加快网站的访问速度。

例子：

当我们看到网页的资源是如下表示的，就表示它使用了CDN来进行静态资源的分发

<link crossorigin="anonymous" href="https://assets-cdn.github.com/assets/frameworks-77c3b874f32e71b14cded5a120f42f5c7288fa52e0a37f2d5919fbd8bcfca63c.css" integrity="sha256-d8O4dPMucbFM3tWhIPQvXHKI+lLgo38tWRn72Lz8pjw=" media="all" rel="stylesheet">

大致了解了CDN，我们再来哔哔缓存。一直以来，我都一度认为缓存是一个好东西，毕竟，很多时候只要做了这个处理，都可以得到良好的收益。

例如，你总是会频繁的访问一个网站，你可能会不断重复的去请求和下载同一个资源N次。这是相当不可取的。一旦，服务器做了缓存，那么，网站就会告诉你，这个东西你还能继续使用。在响应头中设置expires或者cache-control的属性，来设置相应资源文件的响应时间。这样，在你第一次访问完一个网站之后，当你再一次访问时，往往会收到304的响应状态码，因为资源的缓存还未到期。如果你有个资源万年不变，你就可以将expires的有效时间设置为10000年（当然是不可以的，expires是有最大值的哈）。

Expires: Thu, 15 Apr 2020 20:00:00 GMT

一旦你设置了这个值，浏览器将认为资源不会更新。但是，突然你又想更新一下资源你又要怎么办呢。那就在资源后面加上hash值或者版本号，example-2c3fde.js类似。

总结

在服务器上做优化，会使得整体网站的访问速度提升很多

前言

今年是2017年，也是我大学以来最为繁忙的一年，可能是因为大三了吧。由于实习，每天留给我整理博客的时间减少了。我不想自己每天在无知（不知道一天干了点什么的状态）度过，并且将博客移步到了github上面。因为心中有个梦想，希望自己能够在今年完成一项star的收集任务。对于我而言，工业级的架构谈不上，系统化的层级实现不了，nb的类库写不出来，也只能在这里为每位看官留下一笔好的财富（喜欢的话，给我加star哦）。

前端疲劳

今天先来讲一讲我眼中认为的前端疲劳，其实，每天的我都是这样的感觉（累）——并不是心累，而是眼睛累。我真的感觉每天都能在medium上面看到和学到很多的东西，但是，看完之后，就忘记了。

这几年的前端处于井喷的状态，三足鼎立（angular5-beta、react、vue）、打包工具（webpack3和rollup）、（typescript、JavaScript、es6、es7和最近的es8）、性能优化、自动化测试、h5技术、RN、PWA、（css、less、sass、stylus）。看着这么多的东西，第一感觉就是厉害（6666！），但是还是得学，面试得问，项目得用。

如何解决javascript疲劳

其实，每个人都会说，前端你必须得掌握html、css、JavaScript（这三个是基础）。但是，谁都知道，谁都明白，让人的感觉就是白讲。其实，我想表达的是一个方向。接触前端到现在，其实，很多时候前端不一定会都使用框架。回想一下，自己当初学习前端那份初衷在哪里——为了去实现设计师交付给你的那份设计稿，同时也为了交付给用户一个体验良好的产品。其实，前端还有很多其他的东西可以玩，像canvas、svg、webGL、three.js。就像是阿里这样的大公司，还是需要那些做活动界面的前端，或许他们并不会框架，但是他们对于css的掌握，页面的性能，动画的了解一定是一级棒的。每个人找准自己的方向，才是对前端的真正发展。

曾经有个面试官是这么问我的：

  你是喜欢css还是js？
  
  我回答了js。（结果他在之后的面试中问了大部分的问题，而css的部分只是简略了解了一下而已）

我似乎有些佩服这位面试官，因为他懂得区分侧重点。似乎道理也是这么一个道理，平时都在用js、用框架的人，对于css的了解会很深吗？了解css的继承和模块吗？

往往应对疲劳的方法就是，找准自己的侧重点，然后开始进行深入的学习，才能成为真正的工程师。

前言

继续上一篇的话题，我们来看看算法复杂度在O(n*log2n)的算法。

正文

这篇开头我们就来分析一下最受欢迎的快速排序

快速排序

快速排序，从它的名字就应该知道它很快，时间复杂度很低，性能很好。它将排序算法的时间复杂度降低到O(nlogn)

思路：

首先，我们需要找到一个基数，然后将比基数小的值放在基数的左边，将比基数大的值放在基数的右边，之后进行递归那两组已经归类好的数组。

图例：

原图片太大，放一张小图，并且附上原图片地址，有兴趣的可以看一下：

原图片地址

代码实现：

const arr = [30, 32, 6, 24, 37, 32, 45, 21, 38, 23, 47];

function quickSort(arr){
  if(arr.length <= 1){
    return arr;
  }
  let temp = arr[0];
  const left = [];
  const right = [];
  for(var i = 1; i < arr.length; i++){
    if(arr[i] > temp){
      right.push(arr[i]);
    }else{
      left.push(arr[i]);
    }
  }
  return quickSort(left).concat([temp], quickSort(right));
}

console.log(quickSort(arr));

代码地址

性能：

• 时间复杂度：平均时间复杂度O(nlogn)，只有在特殊情况下会是O(n^2)，不过这种情况非常少
• 空间复杂度：辅助空间是logn，所以空间复杂度为O(logn)

归并排序

归并排序，即将数组分成不同部分，然后注意排序之后，进行合并

思路：

首先，将相邻的两个数进行排序，形成n/2对，然后在每两对进行合并，不断重复，直至排序完。

图例：

代码实现：

//迭代版本
const arr = [3,44,38,5,47,15,36,26,27,2,46,4,19,50,48]

function mergeSort(arr){
  const len = arr.length;
  
  for(let seg = 1; seg < len; seg += seg){
    let arrB = [];
    for(let start = 0; start < len; start += 2*seg){
      let row = start, mid = Math.min(start+seg, len), heig = Math.min(start + 2*seg, len);
      let start1 = start, end1 = mid;
      let start2 = mid, end2 = heig;
      while(start1 < end1 && start2 < end2){
        arr[start1] < arr[start2] ? arrB.push(arr[start1++]) : arrB.push(arr[start2++]);
      }
      while(start1 < end1){
        arrB.push(arr[start1++]);
      }
      while(start2 < end2){
        arrB.push(arr[start2++]);
      }
    }
    arr = arrB;
  }

  return arr;
}

console.log(mergeSort(arr));

代码地址

//递归版
const arr = [3,44,38,5,47,15,36,26,27,2,46,4,19,50,48];

function mergeSort(arr, seg = 1){
  const len = arr.length;
  if(seg > len){
    return arr;
  }
  const arrB = [];
  for(var start = 0; start < len; start += 2*seg){
    let low = start, mid = Math.min(start+seg, len), heig = Math.min(start+2*seg, len);
    let start1 = low, end1 = mid;
    let start2 = mid, end2 = heig;
    while(start1 < end1 && start2 < end2){
      arr[start1] < arr[start2] ? arrB.push(arr[start1++]) : arrB.push(arr[start2++]);
    }
    while(start1 < end1){
      arrB.push(arr[start1++]);
    }
    while(start2 < end2){
      arrB.push(arr[start2++]);
    }
  }
  return mergeSort(arrB, seg * 2);
}

console.log(mergeSort(arr));

代码地址

性能：

• 时间复杂度：平均时间复杂度是O(nlogn)
• 空间复杂度：辅助空间为n，空间复杂度为O(n)

基数排序

基数排序，就是将数的每一位进行一次排序，最终返回一个正常顺序的数组。

思路：

首先，比较个位的数字大小，将数组的顺序变成按个位依次递增的，之后再比较十位，再比较百位的，直至最后一位。

图例：

代码实现：

const arr = [3221, 1, 10, 9680, 577, 9420, 7, 5622, 4793, 2030, 3138, 82, 2599, 743, 4127, 10000];

function radixSort(arr){
  let maxNum = Math.max(...arr);
  let dis = 0;
  const len = arr.length;
  const count = new Array(10);
  const tmp = new Array(len);
  while(maxNum >=1){
    maxNum /= 10;
    dis++;
  }
  for(let i = 1, radix = 1; i <= dis; i++){
    for(let j = 0; j < 10; j++){
      count[j] = 0;
    }
    for(let j = 0; j < len; j++){
      let k = parseInt(arr[j] / radix) % 10;
      count[k]++;
    }
    for(let j = 1; j < 10; j++){
      count[j] += count[j - 1];
    }
    for(let j = len - 1; j >= 0 ; j--){
      let k = parseInt(arr[j] / radix) % 10;
      tmp[count[k] - 1] = arr[j];
      count[k]--;
    }
    for(let j = 0; j < len; j++){
      arr[j] = tmp[j]; 
    }
    radix *= 10;
  }
  return arr;
}

console.log(radixSort(arr));

项目代码

性能：

• 时间复杂度：平均时间复杂度O(k*n)，最坏的情况是O(n^2)

总结

我们一共实现了6种排序算法，对于前端开发来说，熟悉前面4种是必须的。特别是快排，基本面试必考题。本篇的内容总结分为六部分：

• 冒泡排序
• 选择排序
• 插入排序
• 快速排序
• 归并排序
• 基数排序

排序算法，是算法的基础部分，需要明白它的原理，总结下来排序可以分为比较排序和统计排序两种方式，本篇前5种均为比较排序，基数排序属于统计排序的一种。希望看完的你，能够去动手敲敲代码，理解一下

如果你对我写的有疑问，可以评论，如我写的有错误，欢迎指正。你喜欢我的博客，请给我关注Star~呦。大家一起总结一起进步。欢迎关注我的github博客

前言

本篇讲述的是react的生命周期的管理的知识点整理。大体的内容都来自于《深入react技术栈》的生命周期部分。不得不说，这是我看过讲解react源码的最好的一本教科书。生命周期的机制在现在大部分框架中都存在，并且这种机制有着它独有的好处。

正文

首先，我们来了解一下生命周期是什么，表现出怎样的特质。从react的角度，react的生命周期钩子主要有：componentWillMount、render、componentDidMount、componentWillReceiveProps、shouldComponentUpdate、componentWillUpdate、componentDidUpdate、componentWillUnmount这样8个。每个生命周期对应着各自的状态，整个生命周期的运作更像是状态机的运作——在不同的阶段，运行不同的方法。

而react就是通过这样子的方式实现了“生命周期——状态——组件”的过程(通过setState方法实现)。

整个react的组件的生命周期可以分成几种情况去执行：

1. 组件第一次渲染：getDefaultProps -> getInitialState -> componentWillMount -> render -> componentDidMount
2. 卸载组件：componentWillUnmount
3. 组件第二次渲染：getInitialState -> componentWillMount -> render -> componentDidMount
4. 组件props发生改变：componentWillReceiveProps -> shouldComponentUpdate -> componentWillUpdate -> render -> componentDidUpdate
5. 组件state发生改变(props并未改变)：shouldComponentUpdate -> componentWillUpdate -> render -> componentDidUpdate

如图所示：

那么，react的生命周期又是通过什么来管理的呢？其实，react的生命周期主要分为三个阶段MOUNTING、RECEIVE_PROPS和UNMOUNTING。在源码中，这三个阶段分别对应着三个函数，分别为mountComponent、updateComponent和unmountComponent。

详细了解这三个阶段之前，可以先来看一下上述执行情况中第一次渲染的时候，这时候组件刚好被生成，react是通过createClass方法来创建自定义组件的。而getDefaultProps方法只执行一次，它是由构造函数来管理的，用来设置初始化defaultProps的。

然后我们再来深入了解这三个阶段分别管理的函数：

阶段一：MOUNTING

mountComponent 负责管理生命周期中的getInitialState、componentWillMount、render和componentDidMount。

通过mountComponent挂载组件，初始化序号、标记等参数，判断是否为无状态组件，并进行对应的组件初始化工作，比如初始化props、context等参数。利用getInitialState获取初始化state、初始化更新队列和更新状态。

注：在componentWillMount中调用setState方法，是不会触发re-render的，而会进行state合并。由于inst.state = this._processPendingState(inst.props, inst.context)是在componentWillMount之后执行的，因此componentWillMount中的this.state并不是最新的，最新的可在render中获取。

mountComponent还有一个特点：通过递归渲染内容，即由父组件开始componentWillMount开始，接着子组件的componentWillMount，之后是子组件的componentDidMount，最后才会到父组件的componentDidMount调用。

执行顺序图：

阶段二：RECEIVE_PROPS

updateComponent负责管理生命周期中的componentWillReciveProps、shouldComponentUpdate、componentWillUpdate、render和componentDidUpdate。

通过updateComponent来更新组件，如果前后元素不一致，说明需要更新。

此时，如果组件中存在componentWillReciveProps的话，则执行，但是在这个生命周期中调用setState函数并不会触发re-render，只会进行state的合并。同样的，state的最新状态并不能在componentWillReceiveProps、shouldComponentUpdate和componentWillUpdate中通过this.state得到。因为只有当触发了inst.state = nextState这个语句时，才会更新最新的状态，因此，也只能在render和componentDidUpdate这两个环节取得。

注：setState函数并不能在shouldComponentUpdate和componentWillUpdate中进行使用。因为会产生死循环，使得内存爆炸。大致的原理在接下来的setState机制中会详细解释。

和mountComponent的流程差不多，updateComponent也是递归渲染的。

执行流程如图：

阶段三： UNMOUNTING

这个阶段主要管理的生命周期是componentWillUnmount。

执行componentWillUnmount时，会重置相关参数、更新队列以及更新状态。并且这里使用setState方法是不会造成组件的re-render的。

setState的更新机制

在react中，或许被使用最频繁的就是setState这个API了。或许，你有没有思考过，为什么需要这样一个API呢？既然state是一个对象，为何不直接修改对象中的值呢！这样做不是更加方便吗？在react中，基本是禁止这样子做的。1. 直接修改state不会引起组件的更新 2. 或许这样子做了，会导致后面的组件状态被覆盖。

那么说回setState的更新问题？react有一个公式UI = f(state)，这个公式表示只需要改变状态，就可以改变UI界面。试想一下，如果频繁地使用setState，react会频繁的去进行重渲染吗？很显然，这是不被允许发生的。这样的结果会导致react的性能急剧下降。首先来看一个例子：

componentDidMount(){
    this.setState({count: this.state.count + 1});
    console.log(this.state.count);
    this.setState({count: this.state.count + 1});
    console.log(this.state.count);
    this.setState({count: this.state.count + 1});
    console.log(this.state.count);
  }

这个例子最后的输出结果都是0， 0， 0。或许，与你试想的1，2，3的结果有很大的不同。这是因为setState的更新机制导致的。在同一个生命周期中，setState会将每一次的操作都放到一个状态队列中，最后对这个状态队列进行一个合并操作。这也就是setState的批量更新——即setState的更新是异步的。

那么，问题来了，有的时候，你必须得这么去做，业务的要求，又该如何呢？那就通过函数的形式，就像Redux一样，具备reducer这种类型的函数，setState本身也推荐使用函数的方式。

this.setState((prevState, props) => {
      count: prevState.count + 1
});

这是比较流行的写法，可以充分的解决异步更新带来的状态不统一的问题。其实这是一种函数式的编程方式，setState接受一个函数，而函数会返回一个新的对象。这样的话，当你需要连续更新时，就可以写一个合并函数，在里面进行操作。

再来看一下另一个例子：

class Counter extends React.Component {
  constructor(props){
    super(props);
    
    this.state = {
      count: 0
    };
  }
  
  componentDidMount(){
    this.setState({count: this.state.count + 1});
    console.log(this.state.count);
    this.setState({count: this.state.count + 1});
    console.log(this.state.count);
    setTimeout(() => {
      this.setState({count: this.state.count + 1});
      console.log(this.state.count);
      this.setState({count: this.state.count + 1});
      console.log(this.state.count);
    }, 0)
  }
  
  render(){
    return (
      <div>{this.state.count}</div>
    );
  }
}

这里的输出结果是0、0、2、3。

前面两个0的输出，看懂上面的机制之后，就可以很明白了。那么，后面两个输出又发生了什么呢？为什么会是2，3，而不是2，2呢。

首先，来看一下setState调用栈的逻辑判断：

这里有个判断的过程，会去判断是否处于批量更新的模式，如果是，则进行批量更新，只render一遍；如果不是，这每次都render。这个判断的源码中涉及到了事务的概念。

setState调用死循环

在上面生命周期阶段调用时，谈及到shouldComponentUpdate和componentWillUpdate方法时，说过在其中调用setState的方法会造成死循环。原因是因为调用setState，会执行enqueueSetState方法，并对partialState以及_pendingstateQueue更新队列进行合并操作，最终通过enqueueUpdate执行state更新。

而performUpdateIfNecessary方法会获取_pendingElement、_pendingStateQueue、_pendingForceUpdate，并调用receiveComponent和updateComponent方法进行组件更新。

在shouldComponentUpdate或componentWillUpdate方法中调用时，this._pendingStateQueue != null，则performUpdateIfNecessary方法就会调用updateComponent方法进行组件更新。这样就形成了死循环。

总结

这里总结了大部分的react的生命周期的内容，大部分的内容也是来自于《深入浅出react技术栈》。只是书上还有一部分源码没有贴出来。这篇文章也算是对自己看完这部分内容的总结吧

前言

在前端工程师面试中js部分一般会分成四个部分进行询问：

1. 基础部分(包括ES6的新特性)
2. 框架部分(主要是angular、react和vue)的不同点，一些内部原理的解析
3. nodejs部分(往往会涉及到koa和express的内容，源码，还有node的基础知识)
4. 其他类库和工具的原理(webpack、babel、zepto等)。

本人打算从这么四个方面对于收集到的面试题进行总结，也是对于接下来的面试的一种补充。基本上，现在的大厂，都是三轮面试（一轮基础面，二轮项目+技术面，三轮hr面）。其实，很多时候，书看的太多，反而记忆是混淆的，因此，由面试题开始进行总结是非常有用的途径。内容分为四篇，也将包括上述的4点。

正文

1. 闭包是什么？闭包的用处。

闭包是内部函数对外部函数作用域的引用。而在函数外部引用函数内部变量，可以通过闭包实现。闭包的用处往往是在模块封装的时候。可以将模块内部公有部分暴露出来。(闭包是基础性的问题，这里只是简要的阐述了一下它的概念) 闭包详解(阮一峰)

2. 原型以及原型链

js与常用的编程语言不一样，他是靠原型继承的，并不是类。使用造零件的方式进行类比，通过类继承的方式就是通过一个模型盒铸件，而原型的方式，则是从另一个零件克隆一份，在这基础上进行修改。而那份被克隆的零件就是原型 原型及原型链详解。原型链就是它们之间产生的联系，往往可以通过画图来阐述：

3. 垃圾回收机制和内存泄漏

js引擎有自己的一套垃圾回收的机制，主要的回收机制有两种标记清除和循环引用。标记清除，即是在局部变量在使用过程中打上标记，一旦离开了执行环境，标记将会被清除，这是垃圾回收器将会知道，该变量已经不使用，可回收。而循环引用是在较早版本的IE浏览器中被使用，即初始化的变量引用数为0，一旦被赋值给另一个变量，引用就加1；而另一个变量一旦被赋予其他值，则该值的引用数减一。垃圾回收器会去判断该变量的引用数是否为0，为0，则会被回收掉。这个机制会存在循环引用的问题，即两个变量相互引用。垃圾回收

内存泄漏的问题。可以罗列为：

1. 无意识的变量使用

function func(){
   i = 2;
}

这种方式在严格模式下是不生效的。
2. 闭包导致的问题

其实，闭包导致的内存泄漏主要是在IE引用dom元素的时候。IE中的部分dom元素并非原生的，而是COM。这时使用，往往会导致循环引用，而导致内存泄漏。还有就是无意识的使用闭包导致的问题。1. 在函数内部添加时间时，会造成dom元素的引用，而导致内存泄漏；2. 在删除dom时，在之前不小心添加了事件等情况内存泄漏

4. 柯里化

js的柯里化就是将函数的部分参数分成多次进行调用。例子：

function func(a, b, c){
  //
}

function fun(a){
   return function(b){
      return function(c){
      }
   }
}

//箭头函数表达方式

const func = (a) => (b) => (c) => {
 ...
};

柯里化是函数式编程必备的一种简化函数参数的方式。柯里化

5. 异步

面试之中主要会问你何为异步？其实，js是一门单线程的语言，正常的方式是整个程序按照顺序一步一步的执行下去，这就是所谓的同步模式，但是往往js中会有许多的任务耗时比较长(比如说ajax请求)等，如果按照同步的方式，往往会导致浏览器的无响应。这时，就需要通过异步的形式。异步模式：js的任务往往具备一个或多个回调函数，在执行的过程中，后一个任务无需前一个任务执行返回结果，而是继续执行，之后前一个任务可以调用回调函数，将结果返回回来。异步

6. setTimeout和setInterval的区别，以及setTimeout的原理，setInterval会造成什么问题

首先，我们来应该了解一下setTimeout的原理。浏览器是一个事件为主体的事物。总是有一个队列在不停的循环。当使用setTimeout时，浏览器会创建一个定时器，然后将函数中的回调函数放入handle队列里面。然后浏览器会不停的循环整个handle，一旦handle中的内容满足条件，就会调用其中的回调函数。setTimeout的满足条件就是它后面的设置的时间差。

setTimeout和setInterval之间的区别主要是setTimeout是一个延迟函数，只执行一次，而setInterval会间隔一定的时间反复的执行。setTimeout和setInterval的区别

setInterval的原理，其实与之前的setTimeout的原理有点类似。只是在每个Event Loop之后，都会去检测是否满足条件，如果满足条件的话，就执行回调函数，如果不满足，放入下一轮的event loop中。主要的问题就是，如果一个setInterval中的回调函数不能够被执行，会引起系统阻塞的问题，之后的所有的定时器都会积累起来，之后就会直接执行，没有时间间隔。setInterval机制;

function interval(func, wait){
    var interv = function(){
         func.call(null);
         setTimeout(interv, wait);
   };
   setTimeout(interv, wait);
}

interval(() => {
    console.log(1);
}, 1000);      //1 1 1 

7. postmessage和iframe怎么结合使用

postmessage是html5新出的一个API，可以解决多窗口、页面与新标签、窗口和iframe之间的消息通信的跨域问题。使用方法就是postmessage(data, origin)，其中data指的就是需要传递的数据，origin指的是具体的数据源地址(包括协议+域名+端口)。然后window对message事件进行监听。postMessage解决跨域

8. js模板引擎

js模版引擎，其实就是预处理器，将一些字符串去匹配数据，然后将数据插入到固定的html模版之中。js的模版引擎主要是使用正则表达式去过滤一些字符串，然后将里面的每个语句片段都放到固定的数组之中，然后在对数组进行解析，之后拼成一个固定的js代码，将内容返回出来。著名的模版引擎ejs。js模版引擎原理解析

9. WebSocket？长轮询和短轮询

webSocket是一种网络通信协议，基于TCP/IP的另一种通信协议(还有一种是http协议)。它与http的主要区别就是，http是单向通信的，客户端可以向服务器发送请求，但是，服务端如果有消息，无法向客户端推送。在没有websock之前，都是通过http定期发送请求的方式——轮询。轮询的效率是相对较低的。websock协议

之后的长轮询和短轮询呢？这个问题还得更实际的场景相结合起来。首先，我们在写电商网站的时候，商品的库存是实时变化的，这时，你要和服务器同步这个变化，才能够使得信息正确。那么，最简单的方式就是我们写一个ajax请求，不断的去给服务器请求，同步这个数据。而服务器每次接收到请求就返回一次信息。这就是所谓的短轮询，这种方式其实非常的消耗服务器的资源，试想服务器每次接收到请求就要去查询数据库，获取信息，而往往库存是没有这么快改变的。那么，或许长轮询可以更加方便地解决这个问题。我们可以写一个ajax请求，同时给这个请求设置超时机制，一旦超时之后，再次重新发送。而服务器每次接收到这个请求，只需要将之挂起，等检测到库存变化时，在响应这个请求，这样就有效的降低了轮询的次数。同样的问题，服务器的资源还是会有所损耗，毕竟一个请求相当于一个线程。对于大型的电商网站来说，这不是一种好的解决方式。长轮询、短轮询、长链接、短链接

10. cookie、LocalStorage 和 SessionStorage 的概念以及它们之间的区别

首先，cookie是我们比较熟悉的，是浏览器与服务器之间数据传递的方式，之前通常也会用来做一些数据的缓存，例如：用户的用户名等。但是cookie在做数据缓存的时候往往有缺点：

1. cookie数据最多只能缓存4kb，大于4kb的cookie会被浏览器默认弃用
2. cookie在做数据缓存时，往往会将数据发送给服务器，但是，有的时候这些数据并不需要发送给服务器
3. cookie在每个域中的数量是有限的，往往超过一定数量，那么之前的cookie将被抛弃
   html5新特性中就带来了相应的客户端storage，就是localStorage和sessionStorage。localStorage是本地存储，数据不会发送给服务器，同时它的缓存大小大约在5M左右，数据是永久存储的，除非手动删除。sessionStorage则是会话存储，大部分的特性和localStorage一样，但是，sessionStorage中的内容会在浏览器或者页面关闭之后被清除掉。cookie、LocalStorage和SessionStorage

11. 浏览器事件代理的原理

其实，事件代理和事件委托是同一个概念。举个例子说明或许会更加形象。场景是：DOM结构为一个列表，而你需要在点击每个li标签时，在控制台输出它的内容。这时，你或许会在每个li上面添加点击事件，然后输出每个li的内容。但是，往往这样子做，会使得整个应用的性能降低，而且使得添加过程繁琐，不灵活。我们可以使用事件代理的方式，在整个列表的ul上面去添加点击事件，然后在内部使用target(真实点击元素)来使其输出它的内容。这样，我们就可以只写一个事件，而完成多个li之间的内容输出。事件代理的原理是使用了事件冒泡的特性。但是，有时候有些事件没有冒泡机制，如focus，blurs等，就不能使用事件代理，还有些类似于mouseover等事件，会导致实时的触发，也不宜使用事件代理事件代理

12. 前端安全 XSS，CSRF ？避免方法？

XSS，被称为跨站脚本攻击，主要分为三种反射型、存储型和DOM型。反射型主要是一些恶意链接的发送，存储型主要出现在评论等，可以插入到服务器数据库中，这种攻击比较持久；DOM型非常的少见。XSS主要是盗取用户的cookie等数据。CSRF，被称为跨站伪造请求攻击，主要与xss相结合XSS和CSRF

13. 前端性能优化的方法

14. 同源和跨域

15. 面向对象和继承

16. object.create的实现原理

17. object的深拷贝和浅拷贝

18. 面向切面编程和函数式编程

**19. **

前言

前段时间，在投票系统中实现了h5的瀑布流加载，demo地址。整体的demo实现效果上可分成三个部分：瀑布流+下拉刷新+上拉加载。下面就具体来分析一下如何实现的。

正文

首先，瀑布流的实现方式只要有三种：

1. 在获取内容时，计算出内容的高度，然后使用定位的方式来形成瀑布流（这种方式目前比较常用，但是需要实时计算，性能不是特别高）。

2. 获得页面的宽度，然后根据页面的宽度计算列数，在进行固定列表的插入（我是用的就是这一种）

3. 使用css3的列布局，由于兼容性问题需要使用前缀（-moz，-webkit）

由于本人使用的是第二种方式，因此，我就详细分析一下第二种方式。

由于设计图是640px的，且整体分成两列，所以，对于列数这个概念，我们可以设定为2，当然了，如果你是PC端的，并不确定列数，你也可以通过window.innerWidth来获取整体的宽度，然后相对于每列的宽度做一个除法。

分析一下整体的html内容部分，主要分为外层的ul，对应的li，以及li里面的内容。

<ul class="container">
        <li class="list">
      <div class="list-item item1">
        
      </div>
      <div class="list-item">
        
      </div>
    </li>
    <li class="list">
      <div class="list-item">
        
      </div>
      <div class="list-item">
        
      </div>
    </li>
</ul>

然后设置css的样式时，将ul的布局设置为flex布局。

.container{
  display: flex;
  list-style: none;
  padding: 0;
}

.list{
  flex: 1;
  margin: 10px; 
}

.list-item{
  width: 100%;
  height: 200px;
  margin-top: 20px;
  background: red;
}

.item1{
  height: 100px;
}

这样大致的效果图如下：

之后，我们来写div块的模板函数，方便之后获取数据的插入tepl()

templ: function(data){
            const block = doc.createElement('div');
            block.className = 'list-item';
            const value = `
                <img src="${data.image}" alt="person-image">
                <div class="name">${data.name}</div>
                <div class="info">
                    <span class="id">编号： ${data.id}</span>
                    <span class="vote"><span class="count">${data.vote}</span>票</span>
                </div>
                <div class="desc">
                        ${data.desc}
                </div>
                <div class="btn-group">
                    <button class="btn detail" data-value="${data.id}">候选详情</button>
                    <button class="btn vote" data-value="${data.id}">为TA投票</button>
                </div>`;
            block.innerHTML = value;
            return block;
        }