Mac配置环境变量的地方

一、/etc/profile （建议不修改这个文件 ）

全局（公有）配置，不管是哪个用户，登录时都会读取该文件。

二、/etc/bashrc （一般在这个文件中添加系统级环境变量）

全局（公有）配置，bash shell执行时，不管是何种方式，都会读取此文件。

三、~/.bash_profile （一般在这个文件中添加用户级环境变量）

每个用户都可使用该文件输入专用于自己使用的shell信息,当用户登录时,该文件仅仅执行一次!
但是有时在.bash_profile 文件中的环境变量并没有起到作用
这时可以查看使用的Mac OS X是什么样的Shell

1
2

➜  ~ echo $SHELL
/bin/zsh

四、当mac上安装了zsh后，修改环境变量就需要在~/.zshrc中修改，比如加入代理：

1
2

export http_prox=http://10.199.75.12:8080
export https_proxy=http://10.199.75.12:8080

如果想要修改立即生效，需要执行

1

source ~/.zshrc

jQuery中each的用法之退出循环和结束本次循环

jQuery中each类似于javascript的for循环

但不同于for循环的是在each里面不能使用break结束循环，也不能使用continue来结束本次循环，想要实现类似的功能就只能用return,

break 用return false

continue 用return ture

link

vue的事件传参

1. Vue的@click=”doXX” 和 @click = “doXX()”有什么区别？

不带括号会传进来一个事件对象，带括号的不会

2. 子组件会将数据自动作为参数传给父组件的回调函数,可是如果我们想在回调函数传其他的参数值怎么传呢？

1

<json-editor @change="onSettingChange(arg，arguments)"></json-editor>

这样子组件传来的参数值可以通过arguments这个数组读取，多余的参数则按照一般的方式传值即可：

1
2
3
4
5
6
7

onSettingChange：function （arg，data）{

    里面的arg是一般的传值，
    
    data[0]里面是子组件传过来的数据

 }

vue中自定义事件回调函数传参 知乎

1. 上官网下载

CSDN
掘金

从层叠的底部开始，共有七种层叠顺序：

1. 背景和边框：形成层叠上下文的元素的背景和边框。
2. 负z-index值：层叠上下文内有着负z-index值的定位子元素，负的越大层叠等级越低；
3. 块级盒：文档流中块级、非定位子元素；
4. 浮动盒：非定位浮动元素；
5. 行内盒：文档流中行内、非定位子元素；
6. z-index: 0：z-index为0或auto的定位元素， 这些元素形成了新的层叠上下文；
7. 正z-index值：z-index 为正的定位元素，正的越大层叠等级越高；

用心前端命名规范探讨

一、命名规则（英文-直译）

1、文件命名

文件夹/文件的命名统一用小写
保证项目有良好的可移植性，可跨平台
相关参考

2、文件引用路径

因为文件命名统一小写，引用也需要注意大小写问题

3、js变量

3.1 变量

命名方式：小驼峰

命名规范：前缀名词

命名建议：语义化

案例

1
2
3
4
5
6
7
8
9
10
11

// 友好

let maxCount = 10; 

let tableTitle = 'LoginTable';

// 不友好

let setCount = 10;

let getTitle = 'LoginTable';

3.2 常量

命名方式：全部大写

命名规范：使用大写字母和下划线来组合命名，下划线用以分割单词

命名建议：语义化

案例

1
2
3

const MAX_COUNT = 10;

const URL = 'http://www.foreverz.com';

3.3 函数

命名方式：小驼峰式命名法。

命名规范：前缀应当为动词。

命名建议：语义化

可以参考如下的动作

1
2
3
4
5
6
7
8

// 是否可阅读
function canRead(): boolean {
  return true;
}
// 获取名称
function getName(): string {
  return this.name;
}

3.4 类、构造函数

命名方式：大驼峰式命名法，首字母大写

命名规范：前缀为名称。

命名建议：语义化

案例

1
2
3
4
5
6
7

class Person {
  public name: string;
  constructor(name) {
    this.name = name;
  }
}
const person = new Person('mevyn');

公共属性和方法：跟变量和函数的命名一样。

私有属性和方法：前缀为_(下划线)，后面跟公共属性和方法一样的命名方式。

案例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

class Person {
  private _name: string;
  constructor() { }
  // 公共方法
  getName() {
    return this._name;
  }
  // 公共方法
  setName(name) {
    this._name = name;
  }
}
const person = new Person();
person.setName('mervyn');
person.getName(); // ->mervyn

3.5 css（class、id）命名规则BEM

（1）class命名使用BEM其实是块（block）、元素（element）、修饰符（modifier）的缩写，利用不同的区块，功能以及样式来给元素命名。这三个部分使用__与–连接（这里用两个而不是一个是为了留下用于块儿的命名）。
命名约定的模式如下：

1
2
3
4
5
6
7

.block{}
.block__element{}
.block--modifier{}

block 代表了更高级别的抽象或组件
block__element 代表 block 的后代，用于形成一个完整的 block 的整体
block--modifier代表 block 的不同状态或不同版本

（2）id一般不参与样式，命名的话使用驼峰，如果是给js调用钩子就需要设置为js_xxxx的方式

二、注释

1.单行注释

1
2

// 这个函数的执行条件，执行结果大概说明
dosomthing()

2.多行注释

1
2
3
4
5

/*
* xxxx  描述较多的时候可以使用多行注释
* xxxx
*/
dosomthing();

3.函数(方法)注释 参考jsdoc

三、组件

组件一般情况下是可以拆成基础/ui部分和业务部分，基础组件一般是承载呈现，基础功能，不和业务耦合部分。
业务组件一般包含业务功能业务特殊数据等等

1 UI组件/基础组件

开发的时候注意可拓展性，支持数据传参进行渲染，支持插槽slot

设置有mixin，mixin中放了基础信息和方法

2 容器组件

和当前业务耦合性比较高，由多个基础组件组成，可承载当前页的业务接口请求和数据(vuex)

3 组件存放位置

（1）ui组件存放在src/components/ 中
包含xxx.vue和 xxmixin.js 和 readme.md

1
2
3

xxx.vue 表示ui部分
xxmixin.js 表示js部分
readme.md 中描述组件的基本信息

4 组件通讯

避免数据的分发源混乱，不建议使用eventBus控制数据，应使用props来和$emit来数据分发和传送

同级组件的通讯一般会有一个中间容器组件作为桥梁

容器组件作为数据的接受和分发点

四、codeReview

1 规则

所有影响到以往流程的功能需求更改发版前都需要codeReview

2 执行者

初级程序员可由中级程序员的执行codeReview
中级程序员可由高级程序员执行codeReview
以此类推

3 反馈

每次codereView都需要有反馈，要对本次codeReview负责

参考链接

• 前端小团队建设
• [前端开发]–分享个人习惯的命名方式
• 一些前端书写规范建议
• 关于团队合作的css命名规范
• 人人网FED-HTML/CSS/JS编码规范-

链接

gulp有一个插件，gulp-util，用来打印日志，看具体什么地方出错了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

/ 合并，压缩文件
    gulp.task('scripts',['copy'], function() {
        gulp.src('./dist/js/page/**/*.js')
            .pipe(sourcemaps.init())
            .pipe(uglify({
                mangle:true,
                compress: true
            }
            ))
            .on('error', function (err) {
                gutil.log(gutil.colors.red('[Error]'), err.toString());
            })
            .pipe(sourcemaps.write('../maps'))
            .pipe(gulp.dest('./dist/js/page'));
    });

1 基于后端MVC的传统架构

由于公司的项目之前是MVC架构，前端项目写在view层，辅以后端的模版嵌套

优点：

• 项目由后端统筹，包括css，img，js等静态文件，布局模版，版本控制，便于后端理解
• 有利于SE0
• 适合PC端
• 适合小型项目快速开发

缺点：

• 不能做到前端模块化，需借助 sea.js 此类模块化js
• 压缩，合并前端资源，需借助 gulp 等node构建工具
• 冗余代码较多

2 前端工程化

以vue-cli搭建SPA的项目为例

优点：

作为目前流行的开发模式，有着下面的优点：

• 模块化开发(js,css)
• 组件化:传统项目更多是封装成插件使用
• 更好的压缩合并前端资源
• 方便使用es6等前沿技术开发
• 适合手机应用开发
• 更好的处理复杂应用

缺点：

• 需掌握的知识更多，对开发有技术要求
• 单页SPA开发，不利于SEO搜索

3 前后端对接的一些注意点：

3.1 请求状态码：

请求状态码需要统一，每个状态码需要明确代表什么意思，方便前端判断。

比如：错误码的定义同HTTP请求状态码一样,对接者能通过系统定义的错误码,快速了解接口返回错误信息，方便排查错误原因。

比如：在需要用户权限的系统中，如果判断该用户未登录或者登录状态丢失，可返回一个指定的状态码，方便前端请求拦截。

3.2 使用工具测试，推荐PostMan

3.3 token验证机制

用户验证机制，推荐用token验证。
关于token验证的过程，请看链接

3.4 遇到涉及安全的字段传递，需考虑签名匹配

4 个人观点：

• PC端项目重SE0,小型项目可采用第一种模式
• 后台项目，手机端项目可采用第二种模式

无论选择哪种模式，前期开发的时候，规范一定要先制定好，最好先写个共同开发准则

参考链接

• 前端开发的历史和趋势-阮一峰
• 为什么要前后端分离？有什么优缺点？
• 前端工程化
• 再谈前后端分离
• 告别是为了彼此变得更好—SPA 前后端彻底分离的探索之路

彻底理解nth-child和nth-of-type的区别

CSS3选择器:nth-child和:nth-of-type之间的差异

• nth-child：按照个数来算。

• nth-of-type： 按照类型来计算，如果是class那么碰到不同类型的，单独一类，符合条件的选中。