simonwoo

// vue constructor
function Vue (options) {
  //...
  this._init(options)
}

Vue.prototype._init = function (options?: Object) {
    const vm: Component = this
    // a uid
    vm._uid = uid++

simonwoo

// 代理模式，将子属性代理到自身上
export function proxy (target: Object, sourceKey: string, key: string) {
  sharedPropertyDefinition.get = function proxyGetter () {
    return this[sourceKey][key]
  }
  sharedPropertyDefinition.set = function proxySetter (val) {
    this[sourceKey][key] = val
  }
  Object.defineProperty(target, key, sharedPropertyDefinition)
}

simonwoo

# Path to your oh-my-zsh installation.
export ZSH=/Users/WU/.oh-my-zsh

# Set name of the theme to load.
# Look in ~/.oh-my-zsh/themes/
# Optionally, if you set this to "random", it'll load a random theme each
# time that oh-my-zsh is loaded.
ZSH_THEME="robbyrussell"

# Uncomment the following line to use case-sensitive completion.

simonwoo

// 定义一个widget基类: 事件处理(观察者模式)，组件生命周期管理
// 模板模式: 在子类中实现具体方法
// UI相关有3个方法组成: renderUI生成相关template, bindUI事件绑定, syncUI样式相关
define(function(){

	function Widget(){
		// this.handlers = {},
		this.boundingBox = null;
	}

simonwoo

跨域

跨域并非浏览器限制了发起跨站请求，而是跨站请求可以正常发起，但是返回结果被浏览器拦截了。

JSONP(JSON With Padding(回调函数+数据))

PS: 回调函数用来响应应该在页面中调用的函数，数据则用来传入要执行的回调函数。

由于浏览器的同源策略，使得在网页端出现了这个“跨域”的问题，然而我们发现，所有的 src 属性并没有受到相关的限制，比如 img / script 等。

a.html
...

simonwoo

graphql共分为两部分: client-side and server-side。 client-side指的是graphql query, for example:

{
  subscribers(publication: "apollo-stack"){
    name
    email
  }
}

simonwoo

本质

Web 内容如何传输，方式是统一协议来形成标准的输入输出，载体是浏览器。数据通道安全需要保证以下两个目标：身份认证和数据不被泄漏和篡改，HTTPS 便是基于此需求产生的协议，在 HTTP 的基础上增加了 TLS 加密协议，通过数据加密、校验数据完整性和身份认证三种机制来保障安全。HTTPS 解决了点到点的安全和身份认证问题，接下来会出现问题的地方就只有 2 个：浏览器和服务器，这个层面上的安全问题并没有 HTTPS 一样简单到可以一次性解决。同源策略、跨站脚本攻击、跨站请求伪造、iframe 沙箱环境等等问题，繁杂至多。

HTTPS

关于传输协议这部分，可以总结:

• 啥地方都要用 HTTPS
• 采用 HSTS 来强制使用 HTTPS
• 别忘了从可信的证书机构中请求可信证书
• 不要乱放你的私钥
• 用合理的配置工具来生成可靠地 HTTPS 配置

simonwoo

function isElementInViewport (el) {
    var rect = el.getBoundingClientRect();
    return (
        rect.top >= 0 &&
        rect.left >= 0 &&
        rect.bottom <= (window.innerHeight || document.documentElement.clientHeight) && /*or $(window).height() */
        rect.right <= (window.innerWidth || document.documentElement.clientWidth) /*or $(window).width() */
    );
}

simonwoo

Best Practices

It’s a very, very, bad idea to attach handlers to the window scroll event.

Depending upon the browser the scroll event can fire a lot and putting code in the scroll callback will slow down any attempts to scroll the page (not a good idea). Any performance degradation in the scroll handler(s) as a result will only compound the performance of scrolling overall. Instead it’s much better to use some form of a timer to check every X milliseconds OR to attach a scroll event and only run your code after a delay (or even after a given number of executions – and then a delay).

Always cache the selector queries that you’re re-using.

It’s not clear why Twitter decided to re-query the DOM every single time the scroll event fired, but this does not appear to be necessary (since scrolling itself didn’t change the DOM). They could’ve saved the result of that single query to a variable and looked it up whenever they wanted to re-use. This would’ve resulted in absolutely no querying overhead (whic

simonwoo

angular.module('localstorage')
  .factory('storageHelper', function ($cacheFactory, $window) {

    'use strict';

    var memoryStorage = $cacheFactory('XXX');
    var localStorage = $window.localStorage;

    return {
      storage: getStorage()