【前端新手日記】實作My GitHub Repo頁面(github API + infinite scroll)－文科少女學程式

上禮拜意外獲得一個實作的機會，
雖然在拿到這份作業時，心中忐忑不安，
因為除了串API是自己確定自己有做過的內容外，
其他部分對我而言都是沒碰過的東西。

不過想著「當工程師就該有解決問題的能力」這點，我還是勇敢接招了XD
(其實OS是老娘就跟你拚了~~~~)
搶先看完成的畫面

GitHub連結在這裡

實作需求內容
1. 用GitHub API串接自己的repo資料到頁面上，並顯示標題、敘述、URL。
2. 用無限滾動(infinite scroll)的技術讀取repo資料。

需求解法相關資料收集
首先，我先透過收集資料去尋找可以完成需求內容的靈感。
主要就分以下兩個方向下去收集資料。
1. 看API使用相關的資料
- 了解到API串接只需要透過GitHub產出自己的token再帶入header就可以了
- 確認到自己要用哪條API下去拿我要的資料
- 用POSTMAN先模擬是否能正常取得資料，以及會取得那些資料
2. 查無限滾動相關的資料
- 了解到大概念是要偵測捲軸是否移動到整個頁面的底部，讀到底部再讀取一次資料
- 需要透過clientHeight、scrollY、scrollHeight去做計算是否已經滑到底部

實作過程(包含發生問題處及解法)
1. 查完資料後，我先設定一個vue專案，進行版面的切版。
(想讓自己多刻意練習一些過去用過的東西切版內容，所以雖然需求沒有要做RWD，
我還是加了這部分的內容)。
2. 切完版之後，我就使用Axios串接API拿自己的repo資料，並透過v-for進行渲染。
串API時出現的問題
在用POSTMAN模擬API串接時，有遇到跨網域存取被拒絕(CORS)的問題，但是這次使用的是public API，
並沒有一位負責製作API的夥伴可以協助從後端解決這個問題，所以就上網查詢如何透過前端解決這樣的狀況。
有查到可以利用cors-anywhere這個API，可透過另一個管道幫我們處理CORS的問題，在要串接的API前面，
再加上cors-anywhere API所提供的網址，最後順利拉取到資料。

3. 確定能夠正確的渲染到頁面後，接著實作infinite scroll的部分，這個部分的實作又拆解成以下幾個步驟。
(1) 進入頁面時，不會將所有資料一次渲染，只會渲染特定筆數的資料
=> 為了讓資料不要一次顯示，除了在Vue data中宣告透過API fetch到的所有repo的資料陣列外，
又宣告了另一個空陣列，好讓頁面上要渲染資料可以依照有無滑到頁面底部而增加。

=>接著讓第一次進入頁面時，currentRenderRepos就能被放入10筆資料。
(這次實作，我想讓每次載入資料時，最多都載入10筆資料)
所以在created的fetch資料動作中，除了拉取API資料外，
還必須讓前10筆資料塞入渲染用的陣列。
我的想法是利用slice去把myTotalRepos的前10筆資料取出，
並且push到渲染用陣列。

let pushData = this.myTotalRepos.slice(0, 10);

this.currentRenderRepos.push(...pushData);

也就是會是以上面這段內容進行，但是之後會統一調整放入依照push次數將資料塞入的method裡面。
*在push我要的資料時，因為要放入的是物件，而非陣列，
但是slice出來會是一個陣列，所以有先用展開運算子把陣列的物件拿出來。
=>最後就能只渲染出前10筆資料了。

(2) 監聽捲軸是否到底部
接著還要讓資料隨著滾動而增加，所以需要監聽滾動這個動作，
並將滾動時需要執行的內容也一併放入。
=>因為要監聽整個瀏覽器，所以使用window來監聽事件，
另外把這個事件的觸發點放在created這個階段。

*原本有在這個事件接聽放上true，讓監聽在捕獲階段就觸發，
但是目標是在根結點，ture或false都不影響，所以拿掉。

=>在監聽滾動動作時，會執行的動作就是確認捲軸有沒有到底部。
這裡確認的方式是用clientHeight、scrollY、scrollHeight去判斷。
clientHeight：是不包含border的可視範圍
scrollY：垂直捲軸已經滾動的距離
scrollHeight：整個頁面的高度（包含超出可視範圍的部分，也就是還沒滾動到的地方）
整個頁面的高度會等於 = scrollY + clientHeight +下半段還沒滑動到的區塊。
所以當scrollY(已經滾動的高度)+clientHeight(現在可視的範圍)等於或大於scrollHeigh(整個頁面高度)時，
也就代表已經滾到底部了。

=>到底部也就可以再次把資料放入渲染用陣列中，讓畫面渲染增加的資料。

(3) 依照狀態增加渲染用陣列的資料
最後一個步驟是要把更動渲染用陣列的method寫出來。
=>在完成這個method前，考慮到要能判斷什麼時候就不再反覆地進行push資料的動作，
所以必須先把資料可以被push到渲染陣列幾次的總數計算出來。
先在Vue data宣告totalLoadingCounts這個變數，也就是透過資料總筆數計算的可被push資料的次數。
另一個perLoadingReposCount參數則是指一次最多能push的資料數，我們一次最多是10筆。
透過這個methods就能計算總共可被加載(push資料)幾次。

=> 接著才進入到更動渲染用陣列的method (loadingRepos)。
在這個method中，我又在Vue data宣告了一個currentLoadingCount變數，
這個變數的用意是在確認現在實際上進行的加載(push資料)次數，是否有超過totalLoadingCounts。
每進行一次push資料的動作，也就會被+1一次。

=>再來先列出幾個無法進行push動作的狀況。
- myTotalRepos沒有資料
- currentLoadingCount 大於 totalLoadingCounts，也就是現在要進行的次數已經超過可進行push的次數
所以先把這兩個狀況排除掉。

=>排除掉上面的狀況後，其他狀況都是是可以進行push的部分。
每次推送資料都是以currentLoadingCount來計算slice的起點和終點。

*原本在這部分的判斷內容，還有想到比較複雜的部份(若是最後一次，但筆數不滿10筆的狀況)，
但是後來想通直接統一進行上面這個步驟即可，就刪除那段的判斷內容了。

其他額外內容
除了需求內容外，還另外進行了RWD，
也透過API把個人資料套用在個人資料頁裡。

實作後心得
這次的作業時間只有三天，其實對比需求內容三天的時間不算短，
但是我對於沒有碰過的東西，雖然會想辦法完成，但還是會很緊張。
而且就是因為是沒碰過的東西，就會需要時間查資料和消化，
等到實作又會遇到一些預期外的問題，所以整體上，預期會花不少時間。
也是因為這樣在接到這份作業時，自己就把它當作一個黑客松下去挑戰，
時間內解得開，是應該的，但會給自己的一個大掌聲XD；
時間內沒解開，算是挑戰失敗，但還是會把這個問題解決。
還是要有始有終~~
(不過因為強迫症(誤)，還是發揮了拼命三娘的精神花了差不多一天的時間完成)

透過這次的作業又學了到了不少新東西，特別是無限滾動的功能，
其實自己在做推特專案時，就有想要實作出這樣的功能，只是時間不夠，就先PASS掉。
所以很高興這次有這個機會可以趁這個作業了解背後呈現的方式。
這次的作業也讓比較沒自信的我，稍微再有自信一點。
雖然我的理解速度可能沒別人快，但是只要我有心，還是有能力解決我要解決的問題。

而且也很高興有公司願意給我這個機會試試看，真的超級感謝。
不論結果如何，我都會繼續努力向前走的 :)