還記得去年參加的 JSDC，一轉眼一年過去了，今年剛好主管被邀請當講者，就跟主管要了一張 VIP 票，人生中第一次拿到 VIP 票 XD
今年因受疫情影響，改由線上直播，我感覺挺好的，可以不受地域限制，戴著耳機，手機連線，隨時都可聽。
不過也有壞處，像上半場，因直播地的網路不穩定，造成看直播的我一直 lag，還以為我這網路有問題…
說來這篇本來要在上禮拜聽完就要寫的，但當時有個很緊急的作業得完成，就拖到這週才寫了…
與去年一樣，寫一篇觀後心得，不過今年只挑我有興趣的議題講而已，沒什麼技術可言啦… 我也不擅長寫技術文。
上午場
Remote Team - TonyQ
這場要講的就如題目所說的，他們團隊是如何 remote 的，利用的工具有什麼，並且他們面試也都採取線上的方式，因他需要進來的人都具備 remote 的能力。
今年剛好疫情，筆者待的公司也嘗試了 remote，對我來說是利大於弊，因離公司有點距離，單趟通勤就要 40 – 50 分鐘，一天 remote 就能為我省下將近兩小時的時間。
不過也有壞處，像是有問題要向某人提問，只能透過文字的方式，但一定都會有文字不好表達的，這部份就得花多點心力去說明問題。
再來是開會，當說明或解釋一個主題時，有時會得到一陣沉默，當下並不知道是其他人聽懂了沒，若是面對面，還可從表情或姿態得知，而線上會議無法，因此，在 remote 的第二週後，公司就規定得開視訊，這樣看得到對方比較有開會的感覺 !?
用 API mocking 讓前端不再苦苦等待 - Huli
當我看到講者名單內有 Huli 時，我還滿興奮的，走前端的人多少一定看過他寫的技術文章，他的文章質量非常之高。
而在這場演講中，他分享: 在一份專案中，前端與後端溝通是透過 API，但若後端 API 還沒生出來前，前端該如何，不太可能就不前進了。
在我公司，是先訂好 interface，再透過 Mocky 來 mock，等後端生出真正 api 時，再替換掉 url。
不過這樣會有個問題，就是 mock 的資料都是靜態的，若需求是當用戶選了什麼什麼後，資料會變，那就必須等真正 API 出來後才好做整合測試，而 Huli 大大分享的剛好能解決這個問題。
他分享了 MSW 與 MirageJS，雖然兩個我還沒去玩過，但看 MSW 似乎與 Mocky 一樣，資料都是靜態的，而 MirageJS 就比較強大了，他可以自由設定哪隻 API url 要用 mock 的，當判斷某個 flag 為真，則使用 Mirage，不會將 request 真的發出去，這樣當後端 API 完成後，只要將 flag 關掉，也不用動到 url 的部分。
除此之外，前端還可以利用 Mirage 自由設定回應的資料，他是動態的，故能做到不同操作，回應不同內容。
你喜歡寫程式嗎？為自己學習寫程式 - Rex Chen
有看過我寫放貸機器人分享文的，一定對此講者不陌生，他就是 Fuly.ai 的創辦人，是我覺得滿神奇的一個人。
他主要分享他的職涯過程，他列出從大學畢業後，至今做過 15 項工作，當時聊天室的人都很驚嘆，說這履歷超豐富，而我也覺得滿神的。
之後開始談他是如何走上創業之路的，以及對於在找、在選工作的人，他的建議是如何等等。
下午場
用錯非同步，服務一樣會卡住 - PJCHENder
這場主要在講 js 的 single thread，因是單一執行緒，故當處理大資料時會卡住後續要做的事，而有些人會認為，那將這些事情設為非同步的是否就能解決了，其實並不會，因 event loop 的關係，最後事情都會回到 stack，故一樣會阻塞後續行為。
那該怎麼做?
講者這邊用 worker 來解決此方法，若有大量計算的事情，就丟到 worker 裡去，就不會影響到用戶的操作了。
講者在講這邊時，有做一個很酷的 demo，來說明當有部份使用者做了印報表的請求時，會卡住只想單純瀏覽頁面的用戶的頁面請求，是個很差的體驗。
而用了 worker threads 後，這狀況就能避免，各做各的事。
跨平台(IOS/Android/Web)開發共用策略 — react-native-web - Bingo Yang
這位講者就是我的主管了，也是我目前的工作內容，利用 RN 與 RN-web 來實現 iOS / Android / mweb 吃同一份 code，且畫面一致的專案。
三平台都長一致，聽起來很完美，但做的過程卻不那麼輕鬆，常有 App 功能是好的，在 mweb 卻壞了，而調整的過程也不太容易…
用不用 TypeScript 隨便你，反正我是用了 - Will 保哥
今年保哥與去年一樣在大推 TS，雖然去年是搭配 Angular 來說，今年則是完全專注在 TS 上。
TS 我滿喜歡的，也是我工作業務上正在寫的，我認為用 TS 寫的專案，debug 起來就是容易些，能夠很快速地知道這些變數、這些參數的型態是什麼，且 autocomplete 也很好用，那種極端的型別這邊不談。
保哥推薦 TS 的論點我都滿認同的，且可以與當前的專案無縫接軌，只要將 *.js 改成 *.ts 就可以了，若有問題的地方，先暫時用 any 來處理也沒問題。
採用 TypeScript 前你該考慮的十件事 - Jeremy Lu
在保哥分享完後的 Jeremy，他主打 TS 的反方，他分享使用 TS 會遇到的問題，這邊我只講我有想法的:
1. 寫更久: 這點確實是，因還要花時間將型別寫好，與定義它。
2. 毒更慢: 這點我認為要看情況，講者在分享這點時，有列兩張一樣功能的 code，差別在一張有 type，另一則無，而有 type 的那張，就有一堆型別定義的，看起來很亂。而我覺得這點看情況的原因在於，在團隊合作中，寫成那樣很難讀的型別不太正常，感覺不是要與團隊溝通的，但卻有很多第三方套件的 type 是寫成那樣很難看懂的… 真的挺頭痛的。
3. 不安全: 這邊提到的是 soundness，TS 與其他強型別的語言不一樣，其他強型別在編譯階段沒問題，runtime 基本上就沒問題。
而 TS 不是，很可能會因 js call by reference 的關係，在 type 上是正確的，但執行起來卻會爆炸。
在說完 TS 會遇到的問題後，他提出幾個解決辦法:
像是用 FB 提供的另一套強型別的方案: flowtype，flowtype 是以 soundness 為優先的，故會比 TS 好很多。flowtype 我是沒用過啦… 所以不知道它的體驗如何。
除了 flowtype 以外，利用 FP 來替代以往 OOP 的寫法，FP 能讓結構更單純，更好懂。我本身還滿喜歡 FP 的寫法，看起來很舒服，很乾淨。
結語
以上便是今年 JSDC 我滿有興趣的議題，若你看到這裡，滿感謝的，因確實如開頭所說的，完全心得分享，沒什麼技術的成份…
參加這種一個人沒多少演講時間的議程，其實沒什麼期待能當下學到什麼技術，大概只能聽到別人在用的什麼新玩具是自己還不知道的。
今年與去年不一樣，去年還有第二天，而今年只有一天，其實我不知道為何去年會有兩天… 若有人知道麻煩告訴我一下，感激不盡~
最後呢，再次感謝看完的讀者~