1: 為什么列表的數(shù)據(jù)不要讓后端同學(xué)返回對象， 而應(yīng)該返回數(shù)組？

返回對象我們前端直接遍歷有沒問題啊， 可以正常顯示，那是因為你沒有遇到下面描述的情況

bug現(xiàn)象1:

「我明明把3這個key定義在了第二個位置， 但是每次打印出來他都跑到了第三個位置， 那么我是不是循環(huán)出的列表就有問題了」

html>???Document?

bug現(xiàn)象2:

123照樣被排序， 而帶漢字的放到最后

let?obj?=?{???????'1':"數(shù)字1",???????'3':"數(shù)字3",???????'2':"數(shù)字2",???????'0漢字':'數(shù)字0'?????};?????console.log(Object.keys(obj))?//??["1",?"2",?"3",?"0漢字"]?????```?????我把0換個位置?????```?????let?obj?=?{???????'0漢字':'數(shù)字0'，???????'1':"數(shù)字1",???????'3':"數(shù)字3",???????'2':"數(shù)字2",?????};?????console.log(Object.keys(obj))?//??["1",?"2",?"3",?"0漢字"]

「bug現(xiàn)象3: 那我加上漢語」

使用下面的代碼順序就不會有問題啦，

????let?obj?=?{???????'1漢字':"數(shù)字1",???????'3漢字':"數(shù)字3",???????'2漢字':"數(shù)字2"?????};

bug理解:

數(shù)組也是對象， 那么對象對這種數(shù)組的形式是有一些特殊操作的，這個坑點一定要后端同學(xué)明白， 不然后期出現(xiàn)奇怪的bug還要轉(zhuǎn)換數(shù)據(jù)形式就太苦惱了。

2:echarts的圖表如何顯示“無數(shù)據(jù)”, 描述了一個思維過程。

事情是這樣的

我要畫一張折線圖， 但這個折線圖有兩個狀態(tài)顯示， 無數(shù)據(jù)的時候顯示“暫無數(shù)據(jù)”， 有數(shù)據(jù)的時候正常顯示數(shù)據(jù)，所以有了如下的代碼。

「其中l(wèi)ist就是折線圖數(shù)據(jù)的數(shù)組， 就是這個樣子的[{},{},{}];」 你可以分析一下下面的代碼bug

??暫無數(shù)據(jù)??...?mounted()?{????this.initLine();?//?初始化折線圖?}?initLine()?{??????this.myChart?=?echarts.init(this.$refs.main);??????//...}

bug現(xiàn)象1:

很明顯第一次 this.initLine(); 會報錯， 因為list的初始值肯定是空數(shù)組導(dǎo)致沒有ref等于main的dom元素， 這樣當(dāng)然會報錯啦，所以有了下面這段代碼。

「使用一個變量來控制是否顯示暫無數(shù)據(jù)」

??暫無數(shù)據(jù)??data(){??return?{????showNodata:false??}}...?mounted()?{????this.initLine();?//?初始化折線圖?}?initLine()?{?????//...?比如請求拿到返回值?????this.list?=?res.list;?????this.showNodata?=?res.list.length?===?0;?//?這里要嚴(yán)謹(jǐn)一點的話，?要處理請求出錯的情況，?提前把this.showNodata賦值為false，這里我就只是舉例子啦。}

bug現(xiàn)象2:

看起來好像沒有大問題， 但是測試提出了一個詭異的問題， 在數(shù)據(jù)從有數(shù)據(jù)到無數(shù)據(jù)不斷切換的時候， “暫無數(shù)據(jù)”與圖表竟然一起顯示了出來，如圖所示。

bug現(xiàn)象3:

明明是 v-if 控制的dom元素，怎么會同時出現(xiàn)兩個。。。

這類問題第一反應(yīng)肯定是元素的復(fù)用問題啦， 加個key就有了如下的代碼

??暫無數(shù)據(jù)??

問題真的就解決了， 但是明明倆個class 不同， 一個有ref一個沒有， 那么這個元素為啥還要重復(fù)啊？

bug現(xiàn)象4:

帶著疑問去掉了class， 同時去掉key， 竟然也可以消除bug

??暫無數(shù)據(jù)??

bug總結(jié):

如果都有class的話，就會復(fù)用下面的dom， 把這個dom的class換成 nodata ， 但是這個dom被echarts處理過所以就導(dǎo)致折線圖還在， 所以如果想避免這個bug那就需要其中一個dom不加class或者乖乖加個key啦。

3:commit 了不想提交的內(nèi)容，但是又commit其他的數(shù)據(jù)

bug現(xiàn)象:

周末加班不小心把一個 .zip 文件commit了上去， push時報的錯誤信息是內(nèi)容過大， 那好辦我直接刪除了這個文件再push， 還是抱這個錯誤， 那我修改 .gitignore 文件， push仍然報這個錯誤這就很惱火啦。

bug追查:

通過 git log 查出每個commit的hash號碼， 然后 git show 打出來看看具體的commit信息， 的確就是因為這個.zip文件出的問題， 那么我現(xiàn)在就是需要取消那一次commit， 但是那次提交之后我又進(jìn)行了多次提交，這可怎么辦。

bug解決:

git reset 出錯commit的前一個hash ， 運(yùn)行 git status 你就會發(fā)現(xiàn)已經(jīng)把.zip文件‘吐出來了’，當(dāng)然這種回退并不會把我們的文件刪除， 或者是把文件修改的內(nèi)容回退， 所以大家可以放心使用， 要記住的是對于已經(jīng)commit的文件，配置 .gitignore 文件是無效的。

4:為什么每次時間都會變化

bug現(xiàn)象:

一個風(fēng)和日麗的傍晚... 我寫了一個毫無花哨表單, 但是詭異的事情正在緩緩到來，背景是我們那個項目使用了nuxt.js, ui選用了Ant Design Vue, 這個表單里面使用了一個時間控件， 就是那種可以選小時與分鐘的， 不可思議的是每次我提交的數(shù)據(jù)‘時間這一項都是錯誤’， 比如我選的下午2點，但是提交的是上午3點， 就是時間永遠(yuǎn)提交的是錯的。。。

bug追查:

const?form?=?JSON.parse(JSON.stringify(this.form))

由上面的內(nèi)容分析了一下， 我突然想到Date對象不支持json序列化， 會不會是序列化的時候?qū)е铝俗儺?#xff1f;

想到了就趕快試一試

「不難看出本來是18：41：19， 但是轉(zhuǎn)換完畢變成了10：41：19， 前面的小時數(shù)出現(xiàn)了變化。 但調(diào)用toString方法就不會使其變化 這么好玩的事情一定要追查下去啊， 這個10到底是什么， 他的轉(zhuǎn)換規(guī)則到底是什么， 當(dāng)時沒有這方面的知識儲備， 那么就把date對象身上的屬性一個一個的試我就不行找不到」

果然被找到了，如圖

「d.getUTCHours() 是什么？」

getUTCHours() 方法可根據(jù)世界時 (UTC) 返回時間的小時。 也就是說他是世界時間， 而不是北京時間的小時

「為啥只有小時不同， 分鐘和秒都一樣」 哈哈哈這個其是很好解釋， 就是聯(lián)合國規(guī)定每個時區(qū)之間的差異只能以小時為維度， 所以才有了這個bug的情況， 真是無用的知識又增加了感覺自己棒棒的。

如果以后大家遇到了這種bug可以大膽的吹它一頓nb啦。

5:Failed to execute 'appendChild' on 'Node': This node type does not support this method

前因后果:

在使用nuxt.js框架編寫項目的時候，遇到了一些實際的問題。

1.部署成本的增加，服務(wù)端可能要安裝pm2，node，yarn。

2.每次更新代碼太慢了， 尤其實在聯(lián)調(diào)階段，每次更新代碼要花費我5分鐘左右(你可以想象遇到一個只在線上才會出現(xiàn)的bug我有多心累)。

3.莫名其妙的錯誤增加了學(xué)習(xí)成本， 并且這些錯誤可能對我們沒啥提高。

4.每次編譯速度極慢極慢，并且編譯后有錯誤(在這里熱更新就是個笑話)， 開發(fā)了一個月我甚至都已經(jīng)習(xí)慣用鼠標(biāo)點瀏覽器的刷新按鈕， 甚至甚至！！！！刷新一遍可能還是錯誤的我要手動刷新第二遍才會正確(桌子都掀了， 再擺回去)。

5.報錯很夸張， 可能我一個代碼錯誤它報500....我一個取值錯誤它就白屏。

6.自身代理需要在每個環(huán)境里面修改， 比如測試環(huán)境服務(wù)器在3000， 開發(fā)環(huán)境啟在8080， 上線又要變。

吐槽還有很多很多， 但是我就不吐苦水了， 大家想清楚如果真的真的需要服務(wù)端渲染再選擇使用它，我們項目一個后臺管理系統(tǒng)使用它收益真的有點小。

bug現(xiàn)象:

在我們不堪其擾的時候， 團(tuán)隊終于決定使用靜態(tài)包來部署， "generate":"nuxt generate", 也就是這句神奇的命令， 它會生成多個html文件來達(dá)到區(qū)別于spa技術(shù)的目的，而我們部署起來方便多了， 但是開發(fā)還是很很不舒服， 就在這個時候出現(xiàn)了這個問題，我在開發(fā)服務(wù)器上啟動的服務(wù)跑的沒問題， 但是在測試服務(wù)上面的generate靜態(tài)包出現(xiàn)了題目上的錯誤， 難道這個錯誤與打包方式還有關(guān)？？？

bug解決:

解決方法說來也簡單， 我使用了一個

6:在nuxt的靜態(tài)打包時，前端path被占用

bug現(xiàn)象:

做好的項目放在新的測試服務(wù)器上， 其中動態(tài)大屏的頁面訪問包nginx報403， 這時候測試與后端同學(xué)就來找我了， 質(zhì)問我做了什么導(dǎo)致nginx出了問題....我給他們的是靜態(tài)包根本沒有操作服務(wù)器的代碼， 那么問題已經(jīng)就處在服務(wù)器環(huán)境或者后端同學(xué)代碼身上啦， 雖然不是前端的工作，但正好是個學(xué)習(xí)的機(jī)會就來幫他們查一查吧。

在項目內(nèi)用 $router.push 的方式跳過去沒問題， 點擊刷新頁面就會404.

bug追查:

nginx報錯那么一定出在路徑上， 查看nginx配置文件里面是如何代理這個路徑的，外部直接訪問這個路徑查找走到了那個代理，最后果然發(fā)現(xiàn)了這個路徑被一個空的資源占據(jù)了。

bug解決:

1.加上路徑前綴也就是publicPath

2.前端給這個頁面改名

最后為了最快時間解決，并且也是后端同學(xué)實在忙不過來了只能妥協(xié)這個版本使用第二種方式。

7:echarts的幾個不常見的問題羅列

「知識點羅列:」 1.讓折線圖堆疊與不堆疊

在使用折線圖的時候， 有時候會涉及到多折線， 這個時候就可能需要這n條折線各自之間互補(bǔ)干涉，也可能讓給他們成為堆疊的狀態(tài)， 如圖所示：

通過設(shè)置每條線的stack屬性相同達(dá)到堆疊效果， 反之亦然

series:?[?{????????????name:?'緊急',????????????type:?'line',????????????smooth:?true,????????????stack:?'緊急',?//?不一樣就不堆疊了????????????data:?[1,2,3],??????????},??????????{????????????name:?'高危',????????????type:?'line',????????????smooth:?true,????????????stack:?'高危',?????????????data:?[5,6,7],??????????},??????????{????????????name:?'中危',????????????type:?'line',????????????smooth:?true,????????????stack:?'中危',??????????????data:?[8,9,10],??????????},??]

1.使橫線變成虛線

這個要求好詭異我找了半天才找到， 不分享出來都感覺對不起自己，對比如圖：

「代碼如下」

yAxis:?{??????????type:?'value',??????????axisLabel:?{????????????color:?'white',????????????fontSize:?14,??????????},??????????splitLine:?{?//?這個就是精髓????????????show:?true,????????????lineStyle:?{??????????????color:?'#d8d8d8',??????????????type:?'dotted',????????????},??????????},????????},

1.讓地圖可以根據(jù)評分變成相應(yīng)的顏色

這個也是我找了半天， 官網(wǎng)里面說的都是 inRange 屬性， 但是這個屬性沒法讓我們?nèi)ピO(shè)置范圍， 后來我找到了 dataRange 這個屬性如圖：

「如下的方式去使用就好啦」

dataRange:?{????????????right:?"2%",????????????bottom:?"3%",????????????icon:?"circle",????????????align:?"left",????????????splitList:?[{????????????????????start:?0,????????????????????end:?0,????????????????????label:?'提示',????????????????????color:?"#6ead51"????????????????},????????????????{????????????????????start:?0,????????????????????end:?250,????????????????????label:?'低溫',????????????????????color:?"#92b733"????????????????},????????????????{????????????????????start:?250,????????????????????end:?500,????????????????????label:?'中溫',????????????????????color:?"#c4aa29"????????????????},????????????????{????????????????????start:?500,????????????????????end:?750,????????????????????label:?'高溫',????????????????????color:?"#ce6c2b"????????????????},????????????????{????????????????????start:?750,????????????????????label:?'超高溫',????????????????????color:?"#c92626"????????????????}????????????]????????},

8:寫一個官網(wǎng)的注意事項

「bug現(xiàn)象1: 所有關(guān)鍵的key與詞語必須讓用戶搜索得到：」
ui組件庫的官網(wǎng)每個實例下面，基本都有一個折疊代碼的功能， 但是當(dāng)我想要 ctrl+f 搜索的部分就在這個被遮擋住的代碼塊中的時候怎么辦？？ 那就很不方便找到了， 所以說折疊代碼的同時不要讓這里的dom結(jié)構(gòu)消失會更舒服， 畢竟ui的官網(wǎng)應(yīng)該以方便查詢?yōu)橹?#xff0c; 而不是官網(wǎng)頁面的性能。

這方面element-ui做的很棒。

「bug現(xiàn)象2: 過于簡短的介紹甚至無介紹：」 很多官網(wǎng)對于一些用法都是一句話了事， 舉例子也就舉其中的一段代碼， 導(dǎo)致我們要付出更多的學(xué)習(xí)時間才能把他研究懂， 官網(wǎng)你都做了為什么不能附上完整的代碼？與詳細(xì)的介紹。

可能寫這個的團(tuán)隊都是大神， 怕寫多了沒有身份。

更有甚者， vue的一個插件他在介紹里面引入了個mixin 也不說mixin里面是啥代碼。。。。

「bug現(xiàn)象3: 不怕重點詞的重復(fù)」 其實某個知識點你雖然說過， 但是有些時候如果解釋的話術(shù)不是很多的話， 我還是建議直接在使用的位置的旁邊附上解釋， 不要為了找一個13個字就能說清楚的東西還要點三層連接去到你們的英文文檔里面自行查閱，我承認(rèn)你寫的很規(guī)范很秀， 但是不太好用。

如果你現(xiàn)在也想學(xué)習(xí)前端開發(fā)技術(shù)，在學(xué)習(xí)前端的過程當(dāng)中有遇見任何關(guān)于學(xué)習(xí)方法，學(xué)習(xí)路線，學(xué)習(xí)效率等方面的問題，你都可以加入到我的Q群中:前114中6649后671，里面有許多前端學(xué)習(xí)資料以及2020大廠面試真題 點贊、評論、轉(zhuǎn)發(fā) 即可免費獲取，希望能夠?qū)δ銈冇兴鶐椭?/p>

總結(jié)

以上是生活随笔為你收集整理的bootscripttable前端排序无效_前端你应该知道的八条bug分享给你们的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。