[ReactJS] tips of Writting JSX with CoffeeScript

由於一開始我沒有認真看 JSX (而且也很懶得看)就開始使用 coffeescript 來寫 React 了,所以一直沒有去搞懂 JSX 到底要怎麼寫,直到最近才開始認真使用 JSX 來開發,詳看上集。關於 jsx 的 tip 其實官方有介紹一些技巧與注意事項:可以參考 React Tips Introduction

因為自己習慣用 coffee 的關係,所以會遇到一些小問題,這篇文章主要紀錄一下用 coffee 寫 react 需要注意的地方與心得,本篇文章的程式碼也都是 coffeescript。

browserify

強烈建議一定要使用 browserify ,官方寫的 todomvc-flux就是用 browserify 來打包程式的,用了 browserify 之後就可以用 coffeeifyreactify 來 compile 程式了。

關於 browserify 的設定可以參考我的專案設定 https://github.com/blackbing/htccs-webapp/blob/master/gulp/tasks/browserify.coffee

jsx header

若程式之中有需要做 reactify 的程式要在第一行加上這行,讓 reactify 認得要 parse jsx 語法。

`/** @jsx React.DOM */`

jsx component

jsx 特有的語法就是用 element tag name 來當語法,例如:

var HelloMessage = React.createClass({
  render: function() {
    return <div>Hello {this.props.name}</div>;

  }
});

用 coffee 來撰寫時就會用到``來轉成 javascript 再交給 reactify 來處理。

HelloMessage = React.createClass(
  render: ()->
    return `<div>Hello {this.props.name}</div>`
  }

this and @

coffee 用 @ 代表 this,但小心不要在 jsx 語法裡頭用 @,因為被 ``包住的部分會被當成 javascript 來處理,coffeeify不會去處理這部分。舉例來說。

HelloMessage = React.createClass(
  onClick: ->
    alert 'onClick'
  render: ()->
    `<div onClick={@onClick}>Hello {@props.name}</div>`
  }

如此@onClick 就會變成 undefined。應該要改成 this.onClick 來處理。像這樣:

HelloMessage = React.createClass(
  onClick: ->
    alert 'onClick'
  render: ()->
    `<div onClick={this.onClick}>Hello {this.props.name}</div>`
  }

every component need a root parent

每一個 component 都需要一個 parent 來包住,例如你不能這樣寫 jsx:

HelloMessage = React.createClass(
  render: ()->
    `<div>Hello foo</div>
    <div>Hello bar</div>
    <div>Hello foobar</div>`
  }

而是要用一個 element 包住:

HelloMessage = React.createClass(
  render: ()->
    `<div>
      <div>Hello foo</div>
      <div>Hello bar</div>
      <div>Hello foobar</div>
    </div>`
  }

由於這可能會影響 HTML 的結構,需要跟 Designer 確定一些實做細節。

Empty text node will wrap by <span>

例如

`<th>type{foo}</th>`

會變成這樣

這可能會跟原本預期的不太一樣,為了避免樣式問題,可能要跟 Designer 確認避免產生空的文字節點。

Sperate component if there's any logic control

用了 jsx 之後會發現遇到邏輯部分的程式會不太好寫。例如用 js/coffee 來寫的話會像是這樣。

HelloMessage = React.createClass(
  render: ()->
    R.div className="form-component"
     if type is 'image'
       R.img src:data.src
     else if type is 'input'
       if inputType is 'text'
         R.input type:"text"
       else if inputType is 'radio'
         R.input type:"radio"
    #...(skip)

而用 jsx 要在一個 render function 做這些判斷會看起來很可怕。建議盡量拆 component,拆 component 是不用錢的。由於 component 都是單一物件的設計,所以盡可能的將一個 component 的邏輯簡化。如上例,可以將裡頭的 if-else 判斷拆出去 FormItem,像這樣:

FormItem = React.createClass
  render: ->
    data = @props.data
    if data.type is 'image'
       `<img src={data.src} />`
    else if data.type is 'input'
      if data.inputType is 'text'
        `<input type="text" value={data.value} />`
      else if data.inputType is 'radio'
        `<input type="radio" value={data.value} />`
        
HelloMessage = React.createClass(
  render: ()->
    `<div className="form-component"
      <FormItem data={data} />
     </div>`
    #...(skip)

這是一個很簡單的技巧也可以將 component 快速的拆開,不要嘗試在一個 component 裡頭包入太複雜的邏輯判斷。另一個好處是可以針對單一個 component 來做 unit-test。

false in jsx

false 在 jsx 裡頭有些不同的意義,在 http://facebook.github.io/react/tips/false-in-jsx.html 有說明,不過因為很重要所以要講三次

其中最重要的是 false element

`<div>{false}</div>`

這樣會變成 <div></div>,成為一個空的節點。在做一些邏輯判斷時還蠻好用的。

Never modify DOM by yourself

如果你開始使用 React 了,請戒掉用 jquery 操作 DOM 的「壞習慣」。真的,一開始會很不習慣,例如addClass('loading')太方便了,但是摻雜使用的後果就是很難 debug。建議要做任何 DOM 的操作都交給 state/props 來決定。

如果有其他使用 React 的小技巧也歡迎分享喔~

[ReactJS] jsx or coffee style

JSX

在寫 ReactJS 時,官方建議使用 jsx 這樣的語法來處理 html,這有點像是 template engine,不知道什麼是 jsx 的同學可以在 jsx compiler 玩玩看。jsx 其實不是必要的東西,如果你開心的話也可以直接用 React.DOM.div來撰寫,實際在使用時,對 jsx 充滿了疑惑,要做一些邏輯性的操作(例如 if-else, foo-loop)等等,相對的有點麻煩。

後來看到了一篇文章,推薦用 coffeescript 的特性來直接撰寫 React component:React, JSX, and CoffeeScript。文章提到用 coffeescript 的特性來操作 component 會更加的得心應手,於是我也動手把 component 直接改成 coffee style。寫出來的程式大概長成這樣:

  R.div id: 'list-view', className: 'view tab-pane fade in active',
    if listType is 'foo'
        R.div className: 'back', '←'
            R.p className: 'alert alert-warning',
            R.i className: 'fa fa-exclamation-circle'
    if listType is 'bar'
        R.span null, 'Hello world'
    else
        R.span null, 'Magic!'

優點

利用縮排來 beautify 程式
R = React.DOM
R.p null,
    R.a href:'foo', 'bar'  # note omitted comma here
    R.a href:'foo2', rel:'nofollow', 'second link'

利用 foo-loop 來產生 template

R.ol null,
  for result in @results
    R.li key:result.id, result.text

相比之下用 jsx 就囉唆許多:http://facebook.github.io/react/docs/multiple-components.html

寫 if-else 像是在喝水的簡單

  if not @state.editing
    R.div null,
      @props.text
      ' ' 
      R.span className:'link-button mini-button', onClick:@edit, 'change'
  else
    R.div style:{position:'relative'},
      R.input
        style:{position:'absolute', top:-16, left:-7}
        type:'text', ref:'text', defaultValue:@props.text
        onKeyUp:@onKey, onBlur:@finishEdit

相比之下 jsx 的 if-else 限制很多:http://facebook.github.io/react/tips/if-else-in-JSX.html

缺點

但是一直到最近我放棄了,所以我來說說 coffee style 的缺點。

無法使用在太複雜的 DOM 結構

其實可想而知,若DOM結構複雜的話,這樣做會搞死自己,雖然我們自以為對 javascript/coffee 非常熟稔,但人眼終究敵不過 template 的複雜度。這是一段我曾經寫的 component 的程式,坦白說這個結構沒有很複雜,但我看第二次的時候我自己都想殺了我自己,大家可以笑笑:

R.fieldset(className:"form-group #{ex_className}",
  R.legend( {className:"scheduler-border"}, item.name),
  R.div( {className:"table-responsive"},
    R.table( {className:"table table-hover"},
      R.tbody(null,
        for d_items, key in  item.dynamic_item
          console.log d_items
          R.tr(null,
            for i of  d_items
              d_item = d_items[i]
              if d_item.type is 'dropdown'
                R.td(null,  DropdownItem(item:d_item))
              else
                R.td(null,  TextItem( item: d_item))
            R.td(null,
              R.button( {type:"button",className:"btn btn-default btn-sm",
              onClick: do(key)=>
                => @removeItem(key)
              },
                R.i( {className:"glyphicon glyphicon-remove"})
              )
            )
          )
      )
    ),
    R.div(null,
      R.button( {
        type:"button"
        className:"btn btn-info btn-xs extend form-add"
        onClick: @addItem
      },
      R.i( {className:"glyphicon glyphicon-plus"})
      )
    )
  )
)
難以維護

由於 coffee 終究是 javascript,用 coffee 來寫基本上就只是在寫程式,一開始我對於可以使用 underscore 之類的 library 來寫 react component 感到很興奮,最後發現這根本沒辦法維護。比方說,我們可以這樣用

React.DOM.div null, foo.bar.map( (r)-> fruit[r]).join(', ')

看起來很簡單,而且寫起來很乾淨,但是當 template 摻雜著太多的邏輯,可就不好玩了,因為你很難控制團隊中大家會怎麼去使用這些東西,其實 template 應該還是回歸單純,只能接收 data,顯示 data。邏輯等等的東西應該都不要跟 template 有太多瓜葛。

結論

在經過一段時間的實做之後,我認為這些缺點非常致命,因此我不建議使用 coffee 來寫 react component,雖然說官方也提到 jsx 不是必要,但若是團隊合作的專案之中,建議還是乖乖的使用 jsx 來處理 template,盡量將邏輯與 template 分開。

下次會分享一些使用 jsx 的小技巧。

[expressjs] request proxy

api proxy

最近使用 expressjs 要將 api proxy 到另外一個 domain 的 api server 上。查了一下最簡單的做法是用 request 來處理。

var API_HOST = 'xxx.com';
app.use('/proxy', function(req, res) {
  var request_params, url;
  url = 'http://' + API_HOST + req.url;
  request_params = {
    followAllRedirects: true,  //redirect if 301~400
    body: JSON.stringify(req.body) //POST/PUT/DELETE data 
  };
  return req.pipe(request(url, request_params)).pipe(res);
});

看起來很簡單不過為了要解決 api server 會做 301/302 redirect 的動作,追了sourcecode才知道有這個 followAllRedirects 的設定,特此記錄一下。

reference:

[PhantomJS] Function.prototype.bind

PhantomJS 1.9.7 (Mac OS X) ERROR

使用 reactjs 來寫 test case 時,用 PhantomJS 執行時就遇到這個 error,奇怪的是用其他的 browser 來執行就沒有問題。

TypeError: 'undefined' is not a function (evaluating 'RegExp.prototype.test.bind(
      /^(data|aria)-[a-z_][a-z\d_.\-]*$/
    )')

查了一下追到這個 issue Function.prototype.bind is undefined,看起來是 PhantomJS 的內核沒有支援 Function.prototype.bind。於是再找到 MDN 的 Function.prototype.bind,在載入 reactJS 之前先將這個 polyfill 加進去就可以解決了。

karma.conf.js
files: [
    'test/polyfill/*.js',
    'app/bower_components/react/react-with-addons.js',
    '.tmp/test/spec/*.js'
]
phantom_bind_polyfill.js(2014/8/3 updated)

use react official polyfill

(function() {

var Ap = Array.prototype;
var slice = Ap.slice;
var Fp = Function.prototype;

if (!Fp.bind) {
  // PhantomJS doesn't support Function.prototype.bind natively, so
  // polyfill it whenever this module is required.
  Fp.bind = function(context) {
    var func = this;
    var args = slice.call(arguments, 1);

    function bound() {
      var invokedAsConstructor = func.prototype && (this instanceof func);
      return func.apply(
        // Ignore the context parameter when invoking the bound function
        // as a constructor. Note that this includes not only constructor
        // invocations using the new keyword but also calls to base class
        // constructors such as BaseClass.call(this, ...) or super(...).
        !invokedAsConstructor && context || this,
        args.concat(slice.call(arguments))
      );
    }

    // The bound function must share the .prototype of the unbound
    // function so that any object created by one constructor will count
    // as an instance of both constructors.
    bound.prototype = func.prototype;

    return bound;
  };
}

})();

[gulp] No need to use karma-browserify

天大的 bug

前幾天才寫了一篇 browserify and karma test 的環境設定,結果今天就踩到天大的 bug:Requiring files that require other files will cause failure.,問題是發生在你的 require dependency 太深的話就會發生 error。我自己遇到是在四層以上就會遇到一模一樣的 error message。

底下有人(gah-boh)留言:"I ended up not using karma-browserify. I tried karma-browserifast and ran into another issue with it. ",然後也提供了他的解法。

var gulp = require('gulp');
var source = require('vinyl-source-stream');
var browserify = require('browserify');
var karma = require('gulp-karma');
var reactify = require('reactify');
var glob = require('glob');

gulp.task('browserify-test', function() {
    var testFiles = glob.sync('./assets/tests/**/*.js');
    var bundleStream = browserify(testFiles).transform(reactify).bundle({debug: true});
    return bundleStream
        .pipe(source('bundle-tests.js'))
        .pipe(gulp.dest('assets'));
});

browserify your test case

我才發現根本就不需要用到 karma-browserify 來處理 (而且也不需要 gulp-karma(https://github.com/karma-runner/gulp-karma)),直接用 browserify 把所有的 test script 產生出來就好了。

以下是我的 task 設定

gulp.task "browserify:test", (callback)->
  bundleApp = map( (contents, filename)->
    fname = get_name(filename)
    browserify(
      entries: [filename]
      extensions: ['.coffee']
    )
    .bundle({debug: true})
    .on('error', $.util.log )
    .pipe(source("#{fname}.js"))
    .pipe gulp.dest(compiledPath + "/test/spec")
  )

  gulp.src('test/spec/**/*.coffee')
  .pipe(bundleApp)

然後 test task 照舊但是要在 browserify:test 做完之後在執行即可

gulp.task "test", ['browserify:test'], (callback)->
  appRoot = "#{__dirname}/../../"
  karmaCommand = appRoot + './node_modules/karma/bin/karma'
  karmaConfig = appRoot + 'test/karma.conf.js'
  exec("#{karmaCommand} start #{karmaConfig}", (err, stdout, stderr)->
    $.util.log stdout
    $.util.log stderr
    callback(err)
  )

結論

我一開始把 browerify 和 karma 的整合想得太複雜了,其實只要把 test case 都經過 browserify compile 之後就可以 run karma 了。我又繞了一大圈,真想殺了我自己。

browserify and karma test

[2014/07/10 update] No need to use karma-browserify

browserify

browserify 真的是個很棒的東西,可以用 require 輕易的把程式模組化,由於可以很輕易的拆成模組,就可以針對模組來寫 test case。之前在玩 AngularJS 時注意到 karma,可以真的run browser engine 來跑 unit test 甚至是 end to end test。原本我以為很簡單可以將 karma test 整進專案,但因為 project 用到 coffee,網路上找到的方式找不太到目前用到的需求(gulp + browserify + coffee + karma test)。所以研究了一下,給有需要的人做參考。

package.json

會用到的 library,比較特別的是 karma-browserify,這個是 karma 的 plugin,用在 karma 的 preprocessors,將 test 的程式做 browserify。

+    "karma": "^0.12.16",
+    "karma-browserify": "^0.2.1",
+    "karma-jasmine": "^0.1.5",
+    "karma-phantomjs-launcher": "^0.1.4",

gulp test task

task 沒什麼特別的,其實只是執行 karma start karma.conf.js,只是把執行的 script 用 gulp task 包起來而已。

gulp = require("gulp")
exec = exec = require('child_process').exec

$ = require("gulp-load-plugins")()

gulp.task "test", (callback)->
  karmaCommand = './node_modules/karma/bin/karma'
  karmaConfig = 'karma.conf.js'
  exec("#{karmaCommand} start #{karmaConfig}", (err, stdout, stderr)->
    $.util.log stdout
    $.util.log stderr
    callback(err)
  )

karma.conf

karma 的設定主要是參考 karma-browserify,也可以直接參考我的設定 karma.conf.js

unit-testing

都設定好之後就可以開始寫測試了,最棒的部分就是可以單獨測試某個 module。例如:

auth = require("../app/scripts/service/auth")
describe "service/auth", ->
  it "should be login", ->
    expect(auth.login()).toEqual('login')
  it "should be logout", ->
    expect(auth.logout()).toEqual('logout')

如此就可以把跟 UI 沒關係的 module 抓出來單獨做 unit-testing,而環境設定好之後我想 end to end testing 應該對 karma 來說都是可以相對簡單的事情了,然後要跑什麼 test report 應該就都可以了,喔耶!

也可以直接參考我的 repository:
https://github.com/blackbing/htccs-webapp/tree/develop

[node-webkit] video mp4 format support

node-webkit 不支援 mp4/mp3 format

最近在玩 node-webkit 遇到一個問題,就是 video 不支援 mp4,原本在瀏覽器開發的好好的,丟到 node-webkit 執行就會死掉。追了一下原來有這個 issue,而且還寫了 wiki Support mp3 and h264 in video and audio tag。大意是說因為 License 的關係,node-webkit 並不會把這些有專利的影音格式支援 build 進去,若您的應用程式需要支援這些有專利的影音格式,可以用以下的解決方式,但風險自負。

詳細看了一下 wiki,最簡單的方式是將 libffmpegsumo.so 取代至 build 出來的專案中。但一定要跟 node-webkit 的 chromium 版本相同,若你自己的 chrome 是最新版的並不保證支援。

於是我在 build 完再把 libffmpegsumo 複製過去取代,重新開啟之後發現影片出現了,但是沒有聲音,WTF。
而在 windows 上的症頭是程式無回應。WTF。
不過這也是 wiki 上寫的並不保證支援最新版本的 chrome。

WebM format

突然想到,這麼麻煩解 mp4 的問題幹嘛,就轉成支援的格式就好了,於是我突然想到可以用 WebM的格式,而且大部分瀏覽器都已經 support 了。所以我就先把 mp4 轉成 webm,沒想到最大的 benefit 就是檔案大小,從原本的 13M 降低成 2.8M,真是嚇死我了,因為當初想要用 node-webkit 包起來有個主要原因就是影片的檔案大小問題,想說可以跑在本機執行的話會比較順暢。不過 anyway,加上一個 source 之後就可以在 node-webkit 上順利執行了,也不用在 build process 中加入奇怪的取代 lib 的動作,非常的好。

<video>
    <source src="video.webm" type="video/webm">
    <source src="video.mp4" type="video/mp4">
</video>

小結

在想解決問題的方法時,不一定要執著在問題的本身,有時候回頭去思考問題或者轉個方向,搞不好就很快的迎刃而解了。想當初我為了要解決播放 mp4 的問題,花了很多時間搜尋 node-webkit mp4 的問題(目光含淚),但其實以我的需求根本不需要直接去解決這個問題。以上。

[javascript] 利用 Deferred 處理順序性任務

Javascript 的世界裡頭充滿了 callback,從其他語言進入 Javascript 的世界常會頭昏,甚至會有點排斥這樣的特性。本篇文章介紹 Deferred 物件的基礎用法,避免程式在做順序任務的處理時難以維護,在模組化的程式設計中,是很重要也很常用到的技巧。

Callback function

假設我們有一個 query 的 function,也許是 ajax,也許是 sql query,總之它接受命令做完回傳 callback

var query = function(task, callback) {
    //do something
  return callback(task + ' finished');
};

因此我們可以很簡單的呼叫 query,例如

query('task1', function(msg) {
  console.log(msg); //task1 finished 
}

但假設我們要依序執行 query 的話,例如 task1 -> task2 -> task3,很自然地就會寫成這樣:

// nested way
query('task1', function(msg) {
  console.log(msg); //task1 finished 
  return query('task2', function(msg) {
    console.log(msg); //task2 finished 
    return query('task3', function(msg) {
      return console.log(msg); //task3 finished 
    });
  });
});

function call function

這樣的問題就是巢狀的 function 裡頭要做的事情越來越複雜,就會將 function 寫成一大包,到最後很難維護。所以很直覺的就將要做的事情拆成 function來處理,例如:

//funciton call function
var task1 = function() {
  query('task1', function(msg) {
    console.log('function ' + msg); //function task1 finished 
    return task2();
  });
};
var task2 = function() {
  query('task2', function(msg) {
    console.log('function ' + msg); //function task2 finished 
    return task3();
  });
};
var task3 = function() {
  query('task3', function(msg) {
    return console.log('function ' + msg);  //function task3 finished 
  });
};
task1();

把 function 拆開看起來就不會有巢狀越寫越深的問題了,但是會遇到問題是:

  1. 若你的 function 散落各處,就會很難 trace 程式碼。
  2. function 與 function 之間的依賴性。越複雜的依賴性會讓程式日後難以維護。

那麼如何利用 Deferred 物件?

首先我們用 Deferred 方式把 query 包起來

var query_dfr = function(task) {
  var _dfr;
  _dfr = $.Deferred();
  query(task, function(msg) {
    return _dfr.resolve(msg);
  });
  return _dfr.promise();
};

接著我們就可以這樣呼叫

query_dfr('task1').done(function(msg){
    console.log('Deferred ' + msg); //Deferred task1 finished 
})

看起來沒什麼了不起,那接著來寫順序的任務吧:

query_dfr('task1').done(function(msg) {
  console.log('Deferred ' + msg);
  query_dfr('task2').done(function(msg) {
    console.log('Deferred ' + msg);
    query_dfr('task3').done(function(msg) {
      console.log('Deferred ' + msg);
    });
  });
})

XDXDXD,翻白眼翻到外太空,當然不是這樣的,這樣還是在寫巢狀的程式。

Deferred and pipe

我們需要用pipe來串聯我們的任務:

query_dfr('task1').pipe(function(msg) {
  console.log('Deferred ' + msg);
  return query_dfr('task2');
}).pipe(function(msg) {
  console.log('Deferred ' + msg);
  return query_dfr('task3');
}).pipe(function(msg) {
  return console.log('Deferred ' + msg);
});

這樣看起來就精簡多了,而且也很容易看懂 task 之間的順序關係。

Library

在瀏覽器環境中,可以直接使用 jQuery Deferred,若你不需要 jQuery,可以用 stand alone Deferred

另外在 node 環境中,可以使用 node-deferred

Reference

本範例程式碼:https://gist.github.com/blackbing/a9dad5c141f51b65b650

不只 pipe,Deferred 還有很多其他的用法,有興趣深入了解的話可以參考:

[ReactJS] Dynamic Selection

ReactJS

ReactJS 是 Facebook 提出的 interface library,專注在 'view' 的更新,避免直接操作 DOM 物件。第一次看到 ReactJS 時,其實我看到 React.DOM.div 我就暈了,以前用document.create('div') ,然後appendChild等等。發現這樣操作 DOM 物件效能很差,後來改用 innerHTML 來更新 DOM,現在又說要用這種方式來寫(眼神死)。

Z>B?

但用了之後才發現驚為天人。以往在做較複雜的 UI 時,會針對不同狀態重新 render 整個畫面,而且 rerender 最簡單,不用去管現在到底是怎樣的狀態。但若資料量龐大的時候,rerender 的成本就非常高,因此在做效能優化時,必須針對「改變」的元素做操作。ReactJS 提出了一個 diff algorithm,將 data 與 DOM element mapping 之後去檢查 data 的改變才更新 DOM element,讓開發者可以專注在 data 的變化,而不需要直接操作 DOM element,也可以將邏輯與 UI 呈現分開。總之是 Z>B。

快速上手

其實 ReactJS 相當簡單,因為這個 library 只專注在 view 的更新,官方文件也蠻清楚的:http://facebook.github.io/react/docs/getting-started.html

階層選單

寫了一個小範例用 ReactJS 實作階層選單,來感覺一下有什麼差別。

49471a6e7bb694044b250100016aad8d.gif
http://jsbin.com/fuziz/19/edit

onChange event

在 select element 的 change evnet 處理 2nd 選單的更新,最大的差別在於只要把資料丟進去就會根據 data 的改變做 refresh。

$component.find('#company').on('change', (event)->
  $target = $(event.target)
  id = $target.find('option:selected').attr('value')
  product = {}
  
  if products[id]
    product = products[id]
  Component.update('product', 'dropdown', product)
)

小結

data binding 的機制其實跟 angularJS 很像,但 ReactJS 只針對 data 與 view 的更新,很適合在專案中抽離 template engine 來提升效能,看起來雖然不會少寫多少程式,但至少不用再針對 DOM element 直接操作,也降低 bug 的產生。現在就很不喜歡寫 $('element').find('a').css('color', '#CCC').trigger('blabla')這樣的程式。

[javascript] 跨瀏覽器的屬性判斷

今天在抓蟲的時候發現一個很容易出錯的地方。當我們在宣告變數時,常常會因為不同的 browser 有不同的 API 定義,然後用以下的寫法來判斷宣告哪一個屬性,例如:

var fullscreenElement = document.mozFullScreenElement || document.webkitFullscreenElement || document.fullscreenElement;

||來檢查要用哪一個 attribute。

不過要小心 javascript 的值當成條件時的判斷。

例如:

var sLeft = window.screenLeft || window.screenX; //firefox use screenX
console.log(sLeft); 

這段程式希望 screenLeft 會回傳 window.screenLeft ,而在 firefox 會回傳 window.screenX。reference: Window screenLeft and screenTop Properties

但是如果 screenLeft 剛好等於 0 的時候,就會進入||之後的條件了,接著就 gg 了。

因此建議在值的判斷還是正統一點用 hasOwnPropertytypeof 來判斷會比較精準。

var sLeft = window.screenLeft;
if( !window.hasOwnProperty('screenLeft')) sLeft = window.screenX;