Pjax是什麼
- 伊谢尔伦原創
- 2016-11-22 13:46:182561瀏覽
什麼是pjax?
現在很多網站(facebook, twitter)都支持這樣的一種瀏覽方式， 當你點擊一個站內的鏈接的時候， 不是做頁面跳轉， 而是只是站內頁面刷新。 這樣的使用者體驗， 比起整個頁面都閃一下來說， 好很多。
其中有一個很重要的組成部分， 這些網站的ajax刷新是支持瀏覽器歷史的， 刷新頁面的同時， 瀏覽器地址欄位上面的地址也是會更改， 用瀏覽器的回退功能也能夠回退到上一個頁面。
那如果我們想要實現這樣的功能， 我們要如何做呢？
我發現pjax提供了一個腳本支援這樣的功能。
pjax專案地址在 https://github.com/defunkt/jquery-pjax 。 實際的效果請見： http://pjax.heroku.com/ 沒有勾選pjax的時候， 點選連結是跳轉的。 勾選了之後， 連結都是變成了ajax刷新。
為什麼要用pjax?
pjax有好幾個好處：
用戶體驗提升。頁面跳轉的時候人眼需要對整個頁面作重新識別， 刷新部分頁面的時候， 只需要重新識別其中一塊區域。自從我在自己的網站上面採用了pjax技術後， 不由覺得訪問其他只有頁面跳轉的網站難受了許多。 同時， 由於刷新部分頁面的時候提供了一個loading的提示， 以及在刷新的時候舊頁面還是顯示在瀏覽器中， 用戶能夠容忍更長的頁面加載時間。
大大減少頻寬消耗和伺服器消耗。由於只是刷新部分頁面， 大部分的請求（css/js）都不會重新獲取， 網站帶有用戶登入資訊的外框部分都不需要重新生成了。 雖然我沒有具體統計這部分的消耗， 我估計至少有40%以上的請求， 30%以上的伺服器消耗被節省了。
壞處我覺得也有：
IE6等歷史瀏覽器的支援雖然我沒有實際測試， 但是由於pjax利用到了新的標準， 舊的瀏覽器相容會有問題。 不過pjax本身支援fallback， 當發現瀏覽器不支援該功能的時候， 會回到原始的頁面跳到上面去。
複雜的伺服器端支援伺服器端需要根據過來的請求， 判斷是作全頁面渲染還是部分頁面渲染， 相對來說系統複雜度增大了。 不過對於設計良好的伺服器程式碼， 支援這樣的功能不會有太大的問題。
綜合起來， 由於使用者體驗和資源利用率的提升， 壞處是可以完全彌補的。 我強烈推薦大家使用。
如何使用pjax?
直接看 官方文件 就可以了。
我覺得做技術的人要養成看一手的技術資料的習慣。
有一個rails針對pjax的 gem插件 可以直接使用。 也有 django的支援。
pjax的原理
為了能夠處理問題， 我們需要能夠理解pjax的運作方式。 pjax的程式碼只有一個檔案： https://github.com/defunkt/jquery-pjax/blob/master/jquery.pjax.js
如果有能力， 可以自己去看一遍。 我這裡解釋一下原理。
首先，我們在html裡面指定， 需要做pjax的連結內容是哪些，以及點擊之後需要更新的部分（放在data-pjax屬性裡面）:
$('a[data-pjax]').pjax()
當載入了pjax腳本之後，它會攔截這些連結的事件， 然後包裝成一個ajax請求， 發送給伺服器。
$.fn.pjax = function( container, options ) {
return this.live('click.pjax', function(event){
handleClick(event, container, options)
})
}
function handleClick(event, container, options) {
$.pjax($.extend({}, defaults, options))
...
event.preventDefault()
}
var pjax = $.pjax = function( options ) {
...
pjax.xhr = $.ajax(options)
}這個請求帶有X-PJAX的HEADER標識， 伺服器在收到這樣的請求的時候， 就知道只需要渲染部分頁面返回就可以了。
xhr.setRequestHeader('X-PJAX', 'true') xhr.setRequestHeader('X-PJAX-Container', context.selector)
pjax接受到傳回的請求之後， 更新data-pjax指定的區域， 同時也會更新瀏覽器的位址。
options.success = function(data, status, xhr) {
var container = extractContainer(data, xhr, options)
...
if (container.title) document.title = container.title
context.html(container.contents)
}為了能夠支援瀏覽器的後退， 利用到了history的api， 記錄下來對應的信息，
pjax.state = {
id: options.id || uniqueId(),
url: container.url,
container: context.selector,
fragment: options.fragment,
timeout: options.timeout
}
if (options.push || options.replace) {
window.history.replaceState(pjax.state, container.title, container.url)
}當瀏覽器後退的時候， 攔截事件， 根據記錄的歷史信息， 產生一個新的ajax請求。
$(window).bind('popstate', function(event){
var state = event.state
if (state && state.container) {
var container = $(state.container)
if (container.length) {
...
var options = {
id: state.id,
url: state.url,
container: container,
push: false,
fragment: state.fragment,
timeout: state.timeout,
scrollTo: false
}
if (contents) {
// pjax event is deprecated
$(document).trigger('pjax', [null, options])
container.trigger('pjax:start', [null, options])
// end.pjax event is deprecated
container.trigger('start.pjax', [null, options])
container.html(contents)
pjax.state = state
container.trigger('pjax:end', [null, options])
// end.pjax event is deprecated
container.trigger('end.pjax', [null, options])
} else {
$.pjax(options)
}
...
}
}
}為了支援fallback， 一個是在載入的時候判斷瀏覽器是否支援 history pushstate API：
// Is pjax supported by this browser? $.support.pjax = window.history && window.history.pushState && window.history.replaceState // pushState isn't reliable on iOS until 5. && !navigator.userAgent.match(/((iPod|iPhone|iPad).+\bOS\s+[1-4]|WebApps\/.+CFNetwork)/)
另一個是當發現請求一段時間沒有回复的時候（可以設定參數timeout）， 直接做頁面跳轉。
options.beforeSend = function(xhr, settings) {
if (settings.timeout > 0) {
timeoutTimer = setTimeout(function() {
if (fire('pjax:timeout', [xhr, options]))
xhr.abort('timeout')
}, settings.timeout)
// Clear timeout setting so jquerys internal timeout isn't invoked
settings.timeout = 0結論
既然都看到這裡了， 為什麼不去實際使用一下pjax呢？ 有這麼多好處， 我覺得幾乎所有網站都應該採用pjax。 趕緊用起來吧！