我已淪爲IE狗!!!前端
從9月份一開始,新項目正式啓動,產品以客戶端的形式發佈,目前用的是.NET的WebBrowser內嵌網頁的形式開發,對於後端來講,一切都是那麼天然、簡單;可對於前端來講,完全將我帶入到了IE的黑洞,自此萬劫不復!說實話,我心裏無比鄙視這個WebBrowser,由於windows綁定了IE,WebBrowser默認使用IE內核,按理說如今win7及以上系統居多,因此這個內核怎麼也是IE9+居多才對啊,可惡的是,衆多系統都是重裝的非正版閹割後的系統,可惡的是,WebBrowser在這些系統哪怕是裝的win七、IE11都調的是IE7,可惡的是程序對其不可控!可惡的是這個調用的IE7與瀏覽器的IE7還不太同樣,我叫它非7非8,有時我在IE7瀏覽器裏看到一個樣子,到了黑殼子裏彈出檢測結果是IE7,樣子竟然和瀏覽器上不同,徹底(想罵人。。。)不在套路上!並且沒有控制檯,任意一個異常,不管是否影響程序,都會彈出一個討人厭的腳本錯誤的提示框!因爲我在瀏覽器上調試和開發的,因此一開始並不知道會有這些問題,即使當時我兼容到了IE7,到了殼子裏面又是一番烏七八糟的問題!當時天天下班回家躺在牀上,我都在懷疑本身的前端之路是否是走進了一條死衚衕,徹底看不到光,說好的炫酷呢,說好的大前端呢?尼瑪這都什麼鬼?node
欣慰的是後端同窗在積極研究怎麼切換到webkit的殼子,基於一些不可預知的問題,以及項目催的太緊,到目前爲止,我依然每天面對着IE7891011。。。。。不要攔我。。。讓我哭會兒。。。webpack
話說仍是要作個堅強的孩子!本身選擇的路,再苦再累也要咬牙走完呀;一方面,兼容問題是前端不可避免的問題;另外一方面,既然眼下沒有更好的方案,只有靠本身一步步走穩腳下的路了;git
皇天不負苦心人,終於讓我磨出了一個ErrorInspector模塊!github
基於以上可惡的讓人懷疑人生的問題,首先解決如下問題:web
一、兼容到IE7;ajax
二、異常的反饋與追蹤(支持跨域);windows
三、屏蔽掉那個討人厭的腳本錯誤提示框;後端
四、要跨終端,好比那個醜的不要的IE殼子,不可調試;跨域
五、錯誤實時上報並通知和展現;
六、一併追蹤與後端交互的錯誤,好比:500、404,把Jquery的ajax拉進來;
七、包裝try_catch,多用try_catch;
因爲要兼容到IE7,那麼基礎庫用Jquery確定最好了,加上本身平時造的一些模塊和組件以及Jquery的插件,基本夠開發用了;可憐的我再次與牛逼的React、Angular擦肩而過了;如今以Nodejs的模塊化方式開發,用webpack打包合併,目前感受還湊合;
最初的想法是,經過window.onerror和try_catch捕獲並上報錯誤到一個獨立的錯誤收集站點,不須要後端配合,本身用Express造一個簡單的站點就是,經過H5的webSocket和Node的Socket.io實時響應上報的錯誤,若是已打開瀏覽器端無需刷新便可收到通知,或者直接發送郵件提示,達到跨終端實時追蹤上報;若是能夠的話,在Web上能夠作更多工做,好比,圖形化分析和展現,常見錯誤的解決方法的預測和提示,若是是線上收集站點還能夠對錯誤極其解決方法作分類收集,供瀏覽者參考;總之,face to error,just do it !
由於問題最終上報到我這,因此就不存在瀏覽器兼容問題了,固然選最好的谷歌了,BSIE!!!;沒作太多優化,初版錯誤反饋展現的頁面大概是這個傻樣子:
固然,圖片裏是測試的結果,每條展開有更多錯誤的詳情,包括錯誤引起的文件地址、行號、錯誤類型、瀏覽器版本、時間、所在頁面、觸發節點等;實際發現,window.onerror捕獲的錯誤並不老是很詳細,最好是多用包裝好的try_catch去主動上報,纔會比較容易定位錯誤源,多用try_catch是個好習慣;由於不免存在跨域的問題,默認使用new Image的方式GET數據,固然,這不是必須的,支持自定義上報地址和上報方法;至於屏蔽掉那個討人厭的腳本錯誤提示框,其實很簡單,在window.onerror最後return true就是的,可是在谷歌裏就會屏蔽掉控制檯輸出的內容,最好在線上環境使用,畢竟本地開發還得在控制檯裏調試;
因爲Jquery的Ajax使用特別靈活,因此作好全局去捕獲Ajax與後端交互的錯誤;看看Jquery的Ajax常見用法:
// 以GET爲例 $.ajax({ url:'', success:function(data){}, error:function(){} }); $.get(url,data,function(data){}); $.get(url,data).success(function(data){}).error(function(){}); $.get(url,data).then(function(data){},function(err){}); // ...
這麼多種用法,每次都去捕獲error事件,而後在裏面上報,確定是至關不靠譜的;Jquery是很好用的,能夠經過設置全局的error事件來捕獲上面各類方式下的錯誤,爽不爽?好比這樣:
$.ajaxSetup({ timeout:setAjax.$.timeout, error: function(xhr){ setTimeout(function () { util.getArgType(setAjax.$.onError)=='function'?setAjax.$.onError(xhr):alert(xhr.status+','+xhr.statusText); }, 1); } });
不過這種錯誤通常後端的可能性大些,前端常見的就是這裏的參數沒傳好,引起的後端錯誤,固然能夠選擇屏蔽不上報,或簡單的提示個服務器異常就好了;
ErrorInspector的用法:
一、最好放在各大library的後面,你寫的JS前面,由於框架自己通常不會引起錯誤,主要是監控本身寫的代碼可能存在的未預知的異常;
二、初始化配置:
ErrorInspector.Config={ url:'http://localhost:2333/ErrorInspector/xiaofeng', //上報地址 qs:{ id:location.host, //默認以當前域爲id page:location.host+location.pathname,//錯誤頁面地址 from:Url, //錯誤來源的地址 row:Number, //錯誤行號 col:Number, //錯誤列號 msg:String, //錯誤詳情 browser:util.Browser, //瀏覽器類型及版本,默認幾大主流瀏覽器,後續完善 time:util.fmtTime(), //錯誤觸發的時間 inspector:String, //上報者window|user|log...... // ...其餘參數 ext:'hufeng' //擴展的參數 }, $:{ timeout:Number, //Jquery的Ajax超時設置,會觸發onError onError:function(xhr){} //全局的Jquery的Ajax錯誤捕獲 }, submit:function(data){}, //自定義上報方式,回調了上報內容 IgnoreFromJSPattern:/reg/ig, //屏蔽錯誤來源的地址,好比第三方的廣告 IgnoreMsgPattern:/reg/ig, //屏蔽上報的消息內容,好比沒太大意義的script.error IgnoreBrowserError:0|1 //是否屏蔽控制檯,主要屏蔽掉那個IE上討厭的彈框 }
ErrorInspector.Config.qs裏的參數通常無需過問,錯誤觸發時會本身收集上報;
三、Tryit(function(report,log){});
包裝好的try_catch,回調的ErrorInspector.report和ErrorInspector.log其實大同小異,除了try_catch裏的上報外,能夠用回調值繼續自定義上報;通常用這個函數包裝代碼塊;
四、ErrorInspector.report({name:value});
主動上報;
五、ErrorInspector.log;
模擬簡單的console.log,其實更像alert,能夠充當統計代碼用,或許還需改進;
六、後端使用Express和Socket.io,玩過H5的webSocket的同窗立馬就懂了,不解釋;
這些天被IE忙活壞了,例子未整理,唉,其實IE並不是那麼可怕!ErrorInspector.js僅做分享,能力有限,歡迎改進!github地址:https://github.com/famanoder/...
若是你已在路上,就勇敢的向前吧!