Bug 太多，bug 以外的易用性問題也很多

開發相關問題

開發得有付費帳號

• 一定得要付費帳號才可以著手寫 POC，沒錯，就只是簡單的 POC 都得花錢，如果公司限制開發人員進行測試，那你沒辦法從 0 開始簡單建個可以用的測試環境，因為免費的 Teams 只有 Chat 功能

開發流程說明混亂

• 以 TypeScript 開發 bot 為例，微軟官網文件 - 如何用 JavaScript 建立 app 要你裝一堆 VSCode plugin，然後從 plugin 裡 New app (在你登入 VSCode plugin 的時候還會先遇到一次帳號權限問題，因為需要申請 Developer account，但他不會告訴你，只會說沒權限)
• 微軟官方文件 - 如何註冊 Bot 教你從 Azure Portal 登入註冊並取得 credentials，而 github 範例引導你到 位於 Azure AI Bot Service 底下的 register 流程，雖然一樣都是 Azure Portal，但是 AI Bot Service 他有自己叫做 Bot Service 的區塊，與列在 Marketplace 的 Azure Bot 非常容易搞混，而實際上，有個 https://dev.teams.microsoft.com 可以用，流程更短更清楚，但在 Teams bot 相關的開發文件都沒有直接連到 Teams developer portal 的文件

Bug(s)

• 有機會多翻轉幾次螢幕方向後，landscape 模式的側邊 menu 出現在 portrait 模式，看不到完整訊息
• 暗黑模式不知道在什麼情況下變成白的，過一陣子又自己突然好了
• Mac desktop 上開會中的視窗右上角時常按不到，像有個 mask 卡在上面的樣子
• Mac 上的 multi task 切換轉不到 Teams，不管是從 Teams 點 URL 開啟 browser 轉不過去，從其他 app 點 Teams window 轉不過來
• Mac 上的開會視窗有時候會錯位，格線跟人的位置搭不上
• iOS app 裡，Group chat (chat) 的時間顯示有時候會維持 Today 不變，就算今天沒有新訊息一看也會以為有新訊息沒跳通知，實際上實際上是昨天看過的舊訊息
• 在 Channel 用 code blocks 貼上 code，indent 會莫名全消失 (space，tab 沒問題)
• 如果在 Group chat (chat) 裡面試著用 quote 當代用品把 indent 變成不可明喻的東西，貼 code 本來是 4 spaces 會變成 3 然後中間插個看不到的 invisible character (就算不是拿來當 code blocks 帶用品，貼上任何內容都不應該有有原本貼上預期外的內容)
• 傳過的訊息，就算 remove 收回，還是可以在 Notifications 裡面看到收回前的訊息 (2023/09/04 發現已經修好了)
• ...(肯定還會有新的，所以這邊定期有遇到會更新)

UIUX 易用性問題

• Windows desktop / Mac desktop 都一樣，開 teams 內 tab 的內容只能開一個，沒辦法多工，像是 word 跟 excel 沒辦法同時開，很蠢
• 各裝置間訊息同步非常慢，回到工作狀態之後會很長一段時間沒反應，但通常這時候都很急著要回訊息，或是根本要自己重開才會更新 (其實算 Bug?)
• Group chat (chat) 不支援 multi line code blocks，跟 channel 行為不一樣，但很多時候明明就需要 1:1 討論程式
• 在 Desktop 上不管是 chat or channel 的編輯文字功能都很難切換，如果從別的地方 copy 內容貼過去是大標題或是夾了背景色或文字有顏色，想切回一般字體大小或顏色就辦不到
• Channel 的 Thread 只要有新的回覆就會被拉在最底，也沒辦法自己選訊息排序方式，時常以為沒有新訊息要看，但實際上是因為新的 Thread 被舊的 Thread 蓋過順序
• Meeting 邀請進來的 Guest 如果是以 Channel 為單位 book 的會議，會沒辦法留言，但是 Chat 可以，也沒辦法，也沒辦法細節調整權限 (邏輯不一致，要自己試過才知道)
• 上傳的檔案在不同地方有不同預設邏輯，個人上傳的會到 onedrive，Group chat 裡的會到 sharepoint (person)，Channel 會到 sharepoint (channel)......所以說為什麼會冒出個 onedrive
• 檔案命名不能有 slash (/)，又不是 Windows 系統，why not
• 各個裝置都一樣就算有 book 行事曆都不會會前通知，當然就沒辦法設定幾分鐘前通知，非常蠢
• 在 iOS mobile 上訂行事曆，時間下面的欄位會被自動彈出的 Date picker 擋住，我猜應該只有工程師知道要滑動才可以收起來，上面也沒有留個 done 可以收輸入，偶而用的時候都會被嚇一跳
• 在 Desktop 想要更新 meeting 的話，高機率開啟 Dialog 後 Skeleton loading 需要等超過一分鐘才會讀完，同樣的，按下更新之後 Loading progress 也會等很久才完成同步
• Book meeting 之後， calendar 會跳回現在的時間點，令用戶感到混亂 (舉例來說: 找到未來兩週後的 meeting 並更改時間，因為更新完/或是按下 close 離開更新之後會回到現在的時間點，但通常會需要一並檢視同時段的會議內容，甚至會不知道之前更動改的時間對不對)
• private channel 沒辦法訂行事曆，這什麼神奇到爆炸的邏輯，難道 private channel 就不用開會嗎？
• 沒有辦法像 Google calendar 一樣一樣分享自己的行事曆給別人，所以得親自問對方有沒有空
• ...(相信也還會有新的，也會定期遇到就更新)

…實在太多了，拜託至少把 code blocks 在 Chat 跟 Channel 的行為統一，這產品明明好幾年了卻像是大學生做出來的一樣問題一堆，微軟的資源有比 slack 少嗎？

ref: https://zh.moegirl.org.cn/zh-tw/来，细数你的罪恶吧

pull-to-refresh (iOS 15+)

沒有辦法透過 onscroll 或是任何方法知道 user 正在 pull-to-refresh，沒錯‌‌，沒有任何方法 (ref from: https://developer.apple.com/documentation/webkitjs/)

解決方法：當 scrollY 在 0 的時候， touchmove 是負數當作開始嘗試 pull-to-refresh (正在 overscroll) 的狀態

let startTouchY

function onTouchStart(event) {
  // We're going to try to guess whether the user is trying to pull-to-refresh only.
  if (event.touches.length > 1 || window.scrollY !== 0) {
    return
  }
  const [touch] = event.touches

  startTouchY = touch.clientY
}

function onTouchMove(event) {
  if (event.touches.length > 1 || !this.startTouchY) {
    return
  }
  const [touch] = event.touches

  const offsetY = this.startTouchY - touch.clientY
  // Pulling to refresh, offsetY smaller than 0 means scrolling down.
  if (offsetY < 0) {
    // ...Do anything you want when user pulling to refresh.
  }
}

function onTouchEnd(event) {
  startTouchY = null
}

Navigation bar/Address bar 縮放 (iOS 15+)

同樣的也沒有任何 event 可以知道 user 目前的操作使 navigation bar 變小還是變大，如果需要做出 full screen 效果，唯一的方式是透過 resize event 通知需要重新計算高度，而高度則需要借助 CSS variable 調整 (作法參考來自 https://zenn.dev/tak_dcxi/articles/2ac77656aa94c2cd40bf)

let vw
let vh

function setFillHeight() {
  if (vw === window.innerWidth && vh === window.innerHeight) {
    // 畫面尺寸沒有更動，所以不做任何事
    return
  }

  // 畫面尺寸有更動的時候重新計算高度
  vw = window.innerWidth
  vh = window.innerHeight

  const vhUnit = window.innerHeight * 0.01
  document.documentElement.style.setProperty('--vh', `${vhUnit}px`)
}

window.addEventListener('resize', setFillHeight)
// 記得手動初始化
setFillHeight()

// 沒有用到的時候也要記得回收 listener
window.removeEventListener('resize', setFillHeight)

另外也可以透過 safe-area-inset-bottom 來預留 address bar 的空間

Does Safari 15 finally fix viewport height?

Luke Channings’s blog

有些實作元素像是 drag&drop 的操作因為上下移動會造成 navigation bar (address bar) 變動，目前沒有相對應的處理方法 (像是 disable address bar 縮放的任何手段)

↓ 範例：navigator resize 造成的 dragging 中斷

https://user-images.githubusercontent.com/1218900/160944477-cae01126-b2bd-4555-a6f9-5d864637f1a9.mov

swipe-to-back

直接電死系列第三彈，透過手勢回到前/後一頁的功能沒有 event 可以知道開始手勢/觸發，所以當有 swipe 手勢偵測實作的時候，建議可以留左右 edge 的空間，避免手勢重疊 (大約 50px 的空間，如果有官方文件清楚定義 swipe-to-back 的空間 pixel 請告知小弟，非常感謝)

以上是避免手勢重複的部分，而如果想要 disable swipe-to-back 手勢的話，可以參考 https://pqina.nl/blog/blocking-navigation-gestures-on-ios-13-4/

基本上就是在想要 disable 手勢的元素上接收 touchstart event

<div style="height:100px">Our element that prevents navigation</div>

<script>
    const element = document.querySelector('div');

    element.addEventListener('touchstart', (e) => {
        // prevent swipe to navigate gesture
        e.preventDefault();
    });
</script>

Wrap it up

以上特別是 navigator (address bar) 花了小弟特別多時間，最令人難過的是沒有解決方法...雖然我也是比較喜歡 iPhone 帶給我的使用體驗，但開發起來真的只能芭比Ｑ了

受各方親朋好友的眷顧，小弟在 9/3 完婚了，真的非常感謝 🙇‍♂️ 這篇文章是想要將在婚禮籌辦期間做的小工具做個推廣、文章留存，但止於實在有點短且無聊，所以一並將老婆的心血結晶分享上來，希望可以幫助到網路上萍水相逢的各位。

先來一波無情工商 - 婚禮入席小助手 (https://github.com/Calvin-Huang/take-a-seat-guide-assistant)

結婚 - 人生的大事，撇掉最前面的單膝下跪並且得到雙方家長的同意這些前置努力外，其需要開始費神耗時的時光集中在開始籌備婚禮後 (感謝老婆 200% 的罩，愛你 3000 次)。

首先，奉上一份整理詳盡的 👉 婚禮總表 👈 (感謝前人的整理) 其中的結婚流程 tab 極為重要，可以有效的檢視需要執行的項目是否被排進行程，確認哪些需要聯絡、告知的事項還有哪些。

其次，時間有限與聯絡窗口、執行人可能會有不同調的情況，為了溝通的效率，這邊提供一個聯絡事項用的樣本，各位可以利用這份樣本來填上內容，確保雙方在同一條線上。

要聯絡誰、為了什麼事 (清楚的講出是什麼事情)、什麼時候要發生、在哪裡發生

上述雖然與原版的 5Ws 管理法相比少了一個為什麼，但在目前要執行的項目裡他幾乎不在考量內

切記「一定要」問清楚長輩所想的事情跟你們想的事情是否在同一件事上，而且「一定要」充分瞭解長輩心中所描繪的儀式的內容步驟有哪些。

「傳統」現今充滿彈性，中間非常多模糊地帶，需要充分釐清

注意事項

預約場地、彩排、場佈

以下以一般喝喜酒的流程作為預設，一般需要往前抓 1 年保險時間預約，在與飯店方交涉時建議主動詢問對新人來說想要達成的效果相關的事項，畢竟飯店方在接洽各式客人的需求各不相同，要他們主動提出有些強人所難。

可以詢問飯店方的問題集

• 場地佈置是否可以更動顏色
• 送客背板客製化修改程度
• 什麼時候可以開始準備會場 / 如果邀約婚佈廠商可以進駐的時間
• 是否會有主持人，何時可以確認主持人的時間 (如果飯店方說可以提供主持人，需要再三確認所謂提供主持人的條件是什麼，我們直到婚宴要開始的前一週才知道有桌數限制，而我們剛好壓線卻沒有達成條件，老婆一度接近崩潰)
• 設備有哪些可用：投影機是 VGA? HDMI? 能不能帶自己的裝置接音響? 音源線是 3.5mm? 需要準備隨身碟?
• 彩排什麼時候進行，婚宴進行的步驟流程有哪些

婚禮廠商相關 / 工作人員

• 外縣市的車馬費、住宿費
• 婚宴當天的飲食偏好，餐盒送達/用膳的時間
• 可以主動提出自己的攝影規劃、當日行程規劃
• (以我們邀請來的互動遊戲 - 拍拍貼為例) 是否需要協助準備設備放置區，路線引導，協調婚宴現場影音設備規格，是否需要人手幫忙桌卡擺設
• 鮮花保存，協調婚宴場地進出：送貨路線、接洽人員

這邊順便工商、感謝一下協助我們婚禮協辦的各家廠商們 ，不論是新秘、婚攝、婚錄、拍貼機/遊戲、捧花都非常專業：溝通順暢，效果、成品極佳，我們非常滿意 & 感謝各位廠商的協助。

• 新秘： Arting話化妝．新娘秘書.個人彩妝.整體造型
• 婚攝： 時隧影像－Time Tunnel Photography
• 婚錄： Daji Film studio【大吉映像】
• 拍貼機＆遊戲： 拍拍印 LineIn 你的專屬拍貼系統
• 捧花： 說給花聽花坊 (花鮮美到像凍結在最完美時間的假花)

傳統儀式相關 - 禮車

• 需要跟禮車司機先行確認路線
• 留意婚宴場地是否可以預留禮車的停車位
• 禮車數量通常為雙數，2, 6...
• 車彩通常租車公司會提供，或者是婚紗店會有，當然如果沒有的話可以以便宜的價格在婚禮用品店/百貨批發購買 (感謝老婆到台北火車站後站批發百貨商圈購買 https://goo.gl/maps/QUKqp5yq6LqiWZAAA)

傳統儀式相關 - 奉茶

• 確認參與的長輩人數，準備相符合的謝禮
• 奉茶的過程會需要作媒人向新娘介紹各位長輩是誰 (我們則是我)，因此事前功課需要先做好臉/稱謂的調查
• 戴上長輩送的結婚金飾

其餘事項

• 列出必帶品清單，出門前勾起確認
• 準備重要品用的小袋子數個，可以用來帶著印章、金飾等等以供快速取用，收納
• 帶著腳跟保護貼、眼藥水、小面紙以備不時之需
• [✅ 非常重要] 事前記下重要聯絡人的手機號碼，避免手機沒電、網路不穩時通訊軟體不可用時找不到人的情況
• 建立備援聯絡人的機制，當分身乏術的時候有人可以補位

以上是提供給各位參考的秘技，希望我們的經驗可以對到來此尋求幫助的各位起到作用，祝一切順利 🎉

歷經一番苦心處理 User Login Flow，配合 UX Designer 將需求實作出來，同時完成了整合 Nextjs 的複雜設定完美的解決 SEO 需求與提升初始畫面速度、通過 QA 層層打磨，你非常確信這次上線的系統不會有什麼節外生枝的問題在心中放了 120 顆心決定好好放鬆一下近期來的疲憊。

「為什麼我會突然什麼事情都沒做就被登出？」

「嗯？使用者資訊顯示的人不是我啊？」

收到 PM 回報的 issue，你乾瞪著眼重複確認 code 的 credential 認證沒問題，axios 很聰明的將 JWT 在 interceptor 夾上 Header 送出，看似萬無一失卻又無法抵擋來自 end user 的怒火。

理應是不同的 session 卻發生資料錯置、state 共用的問題是前端工程利用 Nextjs 或是 Nuxtjs 實作 Server Side Rendering，特別是想要在 Render 前先準備好資料時常誤觸的禁區。

我們試著來拆解上面情境一般來說的實作步驟 ↓

1. 使用者登入成功，將 API 回傳回來的 JWT 存在 Browser 的 cache (可能是 Cookie 或是 LocalStorage 等等)
2. axios 實作 interceptor，不管有 Credentail 或是沒有都會在每次 request 前夾入 Header 免得每次需要 Authentication 的 API call 都得自己夾上 Credential

這段簡單的實作在 Browser 端完全沒有問題，但如果想要更進一步，為了讓 Render 的時候不會閃一下 (因為一開始 intial 的時候沒有 user 資料)，選擇在 Server Side 先執行 API call，我們稍微改一下上面的範例。

單純地將 API call 往上拉到 Server Side 完成又沒有調整太多實作邏輯，看起來萬無一失且有效地達成目標，但自從將這個改動部署上去之後就時不時收到有用戶會看到其他人名字的 Bug 回報。

「當開始使用 Server Side 準備資料，事情就會變得遠比只在 Browser 執行複雜」

為什麼會發生隨機的 User 狀態錯置問題呢？因為 Server 與 Browser 的記憶體本位不同。

詳細一點拆分步驟來看 ↓

問題就出在 Singleton at Server Side

Home.getServerSideProps = async ({ req }) => {
  // Set shared cookie for 
  Cookies.shared = Cookies.new(req.headers.cookie)

  const { data } = await axios.get('https://mock.bugfree.app/api/me')
  return {
    props: {
      user: data,
    },
  }
}

-----

axios.interceptors.request.use(config => {
  config.headers = {
    authorization: `Bearer ${Cookies.shared.get('user-token')}`,
    ...config.headers,
  }

  return config
})

當 Request 進到 getServerSideProps，我們取代/準備了 Cookies.shared 到用的期間只要運氣夠好，axios 都有機會用到不同 Request 所對應的 Cookies.shared。

知道了問題點，調整的方式其實就非常簡單，每一次的 axios call 都一定需要重新夾 Credential 送出 ↓

Home.getServerSideProps = async ({ req }) => {
  // Set shared cookie for 
  const userToken = Cookies.new(req.headers.cookie).get('user-token')

  const { data } = await axios.get(
    'https://mock.bugfree.app/api/me',
    {
      headers: {
        Authroization: `Bearer ${userToken}`
      }
    },
  )
  return {
    props: {
      user: data,
    },
  }
}

上述的以 axios 當做例子所提到的誤區，需要擴充到包含狀態的所有實作，當然這包含了 redux。

next-redux-wrapper 就是以每個 request 當作單位來準備 redux store，確保 Server Side 不會混淆

// https://github.com/kirill-konshin/next-redux-wrapper/blob/master/packages/wrapper/src/index.tsx#L47
...
if (getIsServer()) {
    const c = context as any;
    let req;
    if (c.req) req = c.req;
    if (c.ctx && c.ctx.req) req = c.ctx.req;
    if (req) {
        // ATTENTION! THIS IS INTERNAL, DO NOT ACCESS DIRECTLY ANYWHERE ELSE
        // @see https://github.com/kirill-konshin/next-redux-wrapper/pull/196#issuecomment-611673546
        if (!req.__nextReduxWrapperStore) req.__nextReduxWrapperStore = createStore();
        return req.__nextReduxWrapperStore;
    }
    return createStore();
}
...

對比常見的在 Client 不會有問題但在 Server Side 會有機率出錯的問題寫法

let store

export cosnt withRedux = () => {
  store = createStore()
}

export store

到此，我們提出了一個解決方法，卻提升了實作上的冗贅，一開始的 axios interceoptor 在使用時一率都將自動夾上 Credential，如果要沿用這樣的設計，不論如何 axios module 都會在 Nextjs 的 Lifecycle 外，沒辦法達成每一個 Request 都分離的需求。

相對 Nextjs 來說，Nuxtjs 的解決方案提供的相對齊全，使用整合的 $axios 就不必擔心 by request 的問題。

// https://axios.nuxtjs.org/usage
async asyncData({ $axios }) {
  const ip = await $axios.$get('http://icanhazip.com')
  return { ip }
}

-----

methods: {
  async fetchSomething() {
    const ip = await this.$axios.$get('http://icanhazip.com')
    this.ip = ip
  }
}

現階段而言，對 React 的設計原則來說，不應該學 Vue 將 axios instance 夾在 props 裡面傳遞，所以在不考慮任何 side effect 解決方案 (redux-observable、redux-saga) 的整合方案來說，最簡單的處理方式如下 ↓

⚠️ 但需要非常小心使用，只有 Client Side 才能用 default，Server Side 得每次都手動賦予 Credential。

總結：當需要 Server Side Rendering 特別是處理 state 相關的處理的時候，都需要非常小心避免使用 Singleton。

另外，上面所提的解決方案只有 axios 的簡單解法，如果是需要整合 redux-observable、redux-saga 的話，這又是一段艱辛的路程了...

各位路過的大家好，我是Michael，CapsLock, Studio的編輯及負責人之一，最近一段時間沒有更新blog了，特地來更新一下。

開始接受BAT捐款

因為最近伺服器的負擔加重，所以開始尋求贊助(雖然讀者好像不是很多就是) ，如果願意支持的歡迎透過 Brave Browser 進行BAT捐款

接受coinpayments捐款

如果有follow的大概會知道這段時間開通的telegram服務 牧羊犬 (@group_captcha_bot)

牧羊犬是一個可以防止廣告機器人的anti-spam bot，有興趣的話歡迎隨意使用，同時開通的到現在也開始接受捐獻，有興趣的話歡迎打賞

其他服務開通

另外也開通了一些金融相關的服務，有興趣的路過的歡迎來信詢問

其實我原本2017的12月就應該發了，絕對不是因為去國外玩的太爽，而且中間還卡別的專案

BTW, 2017年的唯一一講就選擇在台大進行!

DevFest主要是由Google相關的周邊社群所主辦，主要社群包含 GCUPUG.tw、GDG Taipei、Android Study Group、Women TechMakers Group，主題主要環繞在Google上或是相關專案及經驗。

然後很有幸的，這次CFP也有上，主要主題是用GCP Vision打造圖片搜尋，先把相關簡報附上

原則上是公司內部的實驗專案，而且一直都在pending的實驗專案就是了

其中有簡單比較一些現成的服務上，不同服務的平台的效益為何，根據不同的公司背景也會有不同的效果出現，其中一些眉眉角角都詳盡的紀錄在簡報中

原文連結：http://eiki.hatenablog.jp/entry/meteo_fall

今天來為大家介紹最能代表日本軟體業界的開發方式吧。

其名為：流星轟落開發/隕石開發(英文: Meteo fall) *1

第一節

通常以 瀑布模型 開發方式進行的專案會是像下面的方式。

那麼 流星轟落開發 則會變成這種形式。

然後變成這樣。

接著下面是敏捷開發的生命週期。

但在神的面前一樣婉如螻蟻。

神之聲，毀滅萬物。

而人們則傾注全力從廢墟中重造。

這就是流星轟落開發 (≒隕石驅動開發)。

第二節

所有的工作排程都由天界的意識來做決定。這同時也可以被稱為默示錄。

對於軟體開發來說，Feedback 是重要的一環。

但對神來說 Feedback 就像耳邊風一樣。

只不過，向神奉上祈求是被允許的，雖然很少能傳達到神到耳中。

神明大人有各式各樣的姿態。
從外部顯身，

或是棲息在內部。

甚至，根本還沒見到，或是沒辦法見到的某某某也說不定。*2

讓軟體開發效率激增的銀彈雖然不存在，但相反的存在是有的。在梵教裡面的話來說，就像是帝釋天的箭矢一樣吧。

第三節

即使如此，當秩序是建立在神只有一人的情況下，這都算還不錯了。

問題就出在神存在兩人以上的時候。
這些神祇們會經常性的下達相反的指示，經常性的爭執。

而這就是吾輩的諸神黃昏《Ragnarok》。
然後受害最深的，終究還是我們「人民」

另外，原本只有一個神所建築起來的秩序，當新的神降臨的時候，
古神所構築起來的一切全部都會被推翻。

而這就是聖戰《吉哈德》。*3

但因為神的不同，可能會有依舊持有絕對的力量，卻存在感極為稀博的神存在。

需要的時候卻找不到的神，恐怕就是邪神了。*4

然後我們用血與汗堆砌而成的結果，會在吾輩所未知的地方盛大的發表。

然後在此彼方，將會誕生新的規格。

結論

這次我們介紹了非常自然的存在於日本軟體業界裡，最為災厄性的流星轟落開發給各位。

順帶一提，對抗這種情況的解法並不存在。
願汝，不，願吾輩能早日在某天找到對抗手段。

本篇文章純為虛構。與一切實際存在的人物、團體無關。

*1: 命名由來。へっぽこ氏（@heppoko）
*2: 簡單來說就是指擁有版權者或是著作者。這種模式更為糟糕。
*3: 最常發生在比預定的 Release 時間晚一年的軟體專案裡。
*4: 出處為馬太福音７章７～１２節：『你們祈求，就給你們；尋找，就尋見；叩門，就給你們開門。因為凡祈求的，就得著；尋找的，就尋見；叩門的，就給他開門。』

翻譯授權：EIKI (id:eiki_okuma)
https://twitter.com/eiki_okuma/status/1002390661448982530

本篇文章 slide 請見此

In The Beginning

相信有很多開發者第一次接觸 Redux 就是從 React 了解過來，或是從 Redux 當作進入點，開始學習 React，如此一來的結果會是很容易忽略了 Redux 官方文件上一開頭就寫的 You can use Redux together with React, or with any other view library.。而基於之前得到的任務要求：「你要如何向只會 React，但不知道 Redux，甚至只會 jQuery 的開發者介紹 Redux？」的原因，所以這次從 jQuery + Redux 這有趣的組合出發，來重新檢視 Redux 是什麼。

Spaghetti Code

國外很有趣的飛行義大利麵怪物(Flying Spaghetti Monster)

Spaghetti code is a pejorative phrase for source code that has a complex and tangled control structure, especially one using many GOTO statements, exceptions, threads, or other "unstructured" branching constructs. It is named such because program flow is conceptually like a bowl of spaghetti, i.e. twisted and tangled.

對於 jQuery，一直以來我對他的印象就是跟義大利麵一樣裹成一團(相信應該也很多人跟我有一樣的印象），而利用 Redux 來將麵團解開就是這篇文章的最終目標。

Start from simple jQuery implementation

使用 GitHub API 搭配自己的 Bookmark API 來實作簡易的 Bookshelf 功能。

Fetch 資料並且 Update UI

從 GitHub API 取得 repo 列表時，同時從 local server 拿到 Bookmark 列表，並且將原本不存在的 is_saved 屬性加回於 repo list。

Toggle Bookmark 而且如果 request failed 恢復狀態

Toggle bookmark icon 之後會送出請求，新增/刪除 存在於 local server 的 Bookmark，當 request failed 將狀態改回去並且顯示 message。

Template based GitHub bookshelf implemented by jQuery - release 1.0.0

Not too bad, huh?

但，有很多地方藏著可怕的潛在問題。像是：重複的程式碼、操作分散、意料外的修改所造成的邏輯 Bug
修改 is_save 屬性的地方幾乎一樣但在不一樣 callback 做了兩次，page 要是在別的地方被改到，整個 fetching process 就會噴掉而且不知道為什麼。

Unit Test

基本上不可能做測試，如果正在看這篇文章的你覺得可以的話，還請教學相長一下🙏

IT'S TIME TO REDUX

What's Redux?

Redux is a predictable state container for JavaScript apps. It helps you write applications that behave consistently, run in different environments (client, server, and native), and are easy to test. (From redux official site.)

那 Redux 與 MVC 的差異在哪裡？

傳統 MVC 在 Controller 內處理 Model 再把資料交給 View ，但當 Model 一多 MVC 的複雜度就會急劇增加，而 Redux 維持著單一個 State 來源試圖減少因為複雜度所造成的問題。
F8 2014 議程影片 (順帶一提，Redux 是由 Flux 所派生出來的)

當然還有其他 Pattern 像是 MVVM、MVP、VIPER 等等不錯的解決方案...而且老實說我從一開始接觸 Redux 的時候對於 Holding State 這件事相當反感，因為當時我最熟悉的 MVVM 就是透過 ViewModel <=> View 的 Data Binding 來消除 State，減少 Side Effect，但實際上 Redux Flow 相較於 Two Way Data Binding 所帶來的不可預期性，Redux 更為簡單並好測試。

REDUX FLOW

Getting Started with React, Redux and Immutable: a Test-Driven Tutorial (Part 1)

Redux 維持 State，並且只有單一方向的透過 dispatch actions 去更新 State，如同官方文件上所提到的 Redux is a predictable state container for JavaScript apps.，它非常的好理解與預期，甚至因為這一點，有很棒的開發工具能協助我們有效的的提升效率。
Redux Devtool 能檢視現在的 state、dispatched action、甚至返回已經執行過的步驟

使用 Redux 重構 jQuery App

加入 lastAction reducer 後透過 subscribe store 來取得最後執行的 action，對應 action 觸發其他 action。

使用 Redux 重構之後，現在我們解決了重複程式碼與迴避無可預期狀態改變的情形。

但，截至目前為止，code 變多了，它依舊無法被測試。

SPLIT APP INTO MODULES, and wrap it up as ESModule for jest

並且修改 subscribe，把異步動作註冊為不影響 action 的 middleware，同時 middleware 為了徹底解耦合利用 Curry 的方式做 DI。

最後留下的進入點就變得非常乾淨

並且可以依照模組進行測試，大功告成！

Bonus: redux-thunk

使用自己註冊一個 middleware 實作的方式是一個方法，但到底還是不夠精簡，在這個 Bonus section 裡面我另外又實作了一個使用 redux-thunk 時做了相同的功能，各位可以在 GitHub - release 3.0.0 找到 code，在這裡就不增加篇幅解釋了。

另外在 redux community 裡面處理 asynchronous action 的優秀 middleware 很多，關於其他 middleware，我整理了另一篇文章，希望可以幫助到各位做選擇 redux-observable/Redux-Saga。

Wrap it up

這篇文章的專案裡面我們使用到了 JsRender 來做 template，所以實際上也可以再加上同系列的 JsViews + JsObservable 去實作 MVVM pattern，就兩者相對的比較來說，雖然以這個小專案來說 MVVM 實作程式碼肯定比較精簡，但redux/flux pattern 的 one way data flow 更好預期，不論是開發或是協作上都很有幫助。

另外就是 jq 本身並不像 React 一樣是 one way data flow，所以在當多人協作時難說會有人就打破了 one way data flow 造成管理上的混亂，所以既然都 redux 了，Why not React? Lol

最後希望各位可以找到最適合自己/團隊的開發方式/技術，來跟飛天義大利麵怪物 Say good bye! 祝各位平安喜樂、身體健康，我們下次再會。

References

• Pure jQuery implementation - release 1.0.0
• Redux middleware implementation - release 2.0.2
• redux-thunk implementation - release 3.0.0
• Online site in Heroku

關於 redux side effects

在開發前端 SPA 的時候，我們有一大半的時間再處理異步動作，更具體來說的話就是網路請求(ajax)。

在一般的使用情境下的流程大概會是這樣的

處理從請求開始到請求結束的流程在 redux only 下，我們可以透過 store.subscribe 去監聽 actions，然後進一步的調用異步方法，並在異步方法結束的時候 dispatch 相對應的 action。

• lastAction 需要自己在 reducer 內實作，可以參考到 https://github.com/reactjs/redux/issues/580

但如果註冊為 middleware 而不是 subscribe store 的話，不但可以取得 store/action 甚至進而調整輸出的 action。

到這邊，其實光是用來舉例的單單一個 action 在不管是 subscribe store 或是 middleware 裡面的實作，從冗長的 switch 判斷就知道這樣的解決方式是一個不好的方案。

redux-thunk

redux-thunk 是 redux 異步處理 middleware 的開拓者，他非常簡單易懂 (不過其實在接觸thunk初期的時候我根本不知道 dispatch 從哪來，有興趣的人可以看一下 redux-thunk source code，極短)。

但在更為複雜的架構下就顯得較為無力招架，所以開發者們從最原初的
thunk 出發，開始尋求其他的解決方案。

處理 side effects 的其他 middleware 中較為亮眼的則有 redux-observable，與 redux-sage，基本上兩者處理 side effects 都非常優秀，並且相似，而這篇文章則是想要整理些比較做個筆記以及提供給各位做選擇上的參考。

那麼先從簡單的介紹開始切入核心：

以 RxJS 為主，核心概念為將 action 視為 stream，透過 observe action 並且轉換為另一個 action 來處理異步請求。

Actions in, actions out，在這邊附上從官方文件來的簡單範例。

而對 RxJS 並不熟悉的各位，Rx 系列的文件非常齊全，推薦可以透過 RxMarbles 的視覺化 Operator 來學習。

Netflix 工程師 Jay Phelps 的 talk 也非常有幫助，並且非常風趣 (Jay: open source的第一步，就是要做一個好 Logo)。

以 ES6 generator 為核心主軸，利用 yield 和 redux saga 所提供的一些 helpers 來處理 async actions。

我們可以從官方的範例裡看到 generator 的運用，而學習 redux-saga 基本上就等同於學習 ES6 generator 的過程。

By doing so, these asynchronous flows look like your standard synchronous JavaScript code. (kind of like async/await, but generators have a few more awesome features we need)

Compare side by side

因為 redux-sage 或是 redux-observabl 其實兩者的差異並沒有到天差地遠的大，那就跟選用顯卡一樣各取所需，接下來就依照一些使用情境來讓各位能更清楚的了解兩者的差異。

Launch Up

saga - Watcher + Worker

observable - Type & Observable

Cancelable

saga

observable

Throttling

saga

observable

Debouncing

saga

observable

Retrying

saga

observable

Conclusion

另外有其他更棒的 side by side comparison 例子歡迎大家討論提供 😉

為了確保產出良好的品質，我們大多都要模擬不同的情境下程式可能會發生的狀況，傳統不走TDD的話都要回去一行一行的翻程式碼，此舉需要花費的時間相當漫長，而且並不是很有效。

甚至寫到一半要去看covergae report有踩到哪些地方，這樣下次寫的時候才可以儘量不重複寫(尤其多人開發非常容易踩到)

如果是小範圍的程式還好，但是total lines成長到上千或是上萬行就很頭疼了...

對於這樣漫無目的的找無疑是相當大的成本，常常找一找就一整天過去了，所以就在想說有什麼更有效的方式可以處理這個問題，而目前也沒有很有效的方式去判斷哪些函式(function)哪些有用到哪些沒用到的，基本上都是靠漫無目的的人為判斷。

但這時候又要問了：難道沒有什麼更有效的方法嗎？

簡單來說，那時候的初步構想是這樣的

那時候的需求很簡單，就是我要知道哪些class有用到哪些模組。

那作法呢，首先必須要有兩個封裝的ClassA及ClassB，當ClassB需要ClassA的時候總是會用到像是use Foo\ClassA或是new ClassB之類的關鍵字做引入動作

用上面的關鍵字做regex(正則)的全文比對來找哪些有用到，這樣就可以判斷是不是有使用啦～

但是我想的實在太美好了...

如果我想知道有什麼function有用到什麼沒用到

還是得去擲筊，因為我這樣只能知道引入什麼套件啊

那除此之外還有其他作用嗎？

不好意思沒有了

所以只好硬著頭皮繼續改

一個龐大的專案經過多人維護，因為PHP「奔放」的syntax，其coding style及用的邏輯還有規則基本上都是「不可考」的狀態，像是這樣

用傳統的正則拉勢必會拉到獵奇不該出現的東西，所以正則不是一個好辦法。

到後面用上了這個東西
http://php.net/manual/en/function.token-get-all.php

這個function是早期PHP4的時候因為大量與HTML混搭，所以PHP的核心模組就把PHP Interpreter的解析用的模組另外再放出來使用，它可以很準確的判斷現在這個區塊(block)的是什麼型態。

像是上面的程式解析出來就會長的像是這樣子

array(11) {
  [0] =>
  array(3) {
    [0] =>
    int(379)
    [1] =>
    string(6) "<?php
"
    [2] =>
    int(1)
  }
  [1] =>
  array(3) {
    [0] =>
    int(382)
    [1] =>
    string(1) "
"
    [2] =>
    int(2)
  }
  [2] =>
  array(3) {
    [0] =>
    int(378)
    [1] =>
    string(23) "/**
 * @use Foo\Bar
 */"
    [2] =>
    int(3)
  }
  [3] =>
  array(3) {
    [0] =>
    int(382)
    [1] =>
    string(1) "
"
    [2] =>
    int(5)
  }
  [4] =>
  array(3) {
    [0] =>
    int(361)
    [1] =>
    string(5) "class"
    [2] =>
    int(6)
  }
  [5] =>
  array(3) {
    [0] =>
    int(382)
    [1] =>
    string(1) " "
    [2] =>
    int(6)
  }
  [6] =>
  array(3) {
    [0] =>
    int(319)
    [1] =>
    string(3) "Foo"
    [2] =>
    int(6)
  }
  [7] =>
  array(3) {
    [0] =>
    int(382)
    [1] =>
    string(1) "
"
    [2] =>
    int(6)
  }
  [8] =>
  string(1) "{"
  [9] =>
  array(3) {
    [0] =>
    int(382)
    [1] =>
    string(1) "
"
    [2] =>
    int(7)
  }
  [10] =>
  string(1) "}"
}

上面可以很明顯的看出來，經過token_get_all的洗禮之後，程式碼片段被拆解成一個一個的碎片(slice)，每一個碎片都有一個type做定義(參考: http://php.net/manual/en/tokens.php)，透過定義好的type我們可以蠻快知道哪些是註解
所以，如果我需要砍掉沒辦法受我控制的註解我可以這樣做

透過built-in的constant判斷不是註解的部分，再重新組合整份程式碼，這樣就可以用正則撈這個php file裡面引入什麼package啦

那說好的function分析呢？

前面不是提到我怎麼判斷這個php file有引入什麼package嗎？
除此之外還遇到了下面的情況:

1. 我要怎麼判斷我用了private function或是protected function呢？
2. 我要怎麼判斷繼承呢？
3. 判斷使用很簡單，怎麼做到判斷沒用到的function？

一切的一切都是建立在良好的分析工具上面

token_get_all是很好的工具，不過很可惜的是它再怎樣都沒辦法做有結構性的檔案分析，於是嘗試了稍微專業一點的PHP Parser (https://github.com/nikic/PHP-Parser)
它跟token_get_all有什麼樣的不同呢？最大的區別是它可以把同一個statement(敘述)的歸類在一起，舉一個簡單的宣告來說好了

如果用token_get_all的話可以看到會變成像是這樣子

array(13) {
  [0] =>
  array(3) {
    [0] =>
    int(379)
    [1] =>
    string(6) "<?php "
    [2] =>
    int(1)
  }
  [1] =>
  array(3) {
    [0] =>
    int(320)
    [1] =>
    string(4) "$foo"
    [2] =>
    int(1)
  }
  [2] =>
  array(3) {
    [0] =>
    int(382)
    [1] =>
    string(1) " "
    [2] =>
    int(1)
  }
  [3] =>
  string(1) "="
  [4] =>
  array(3) {
    [0] =>
    int(382)
    [1] =>
    string(1) " "
    [2] =>
    int(1)
  }
  [5] =>
  array(3) {
    [0] =>
    int(305)
    [1] =>
    string(3) "new"
    [2] =>
    int(1)
  }
  [6] =>
  array(3) {
    [0] =>
    int(382)
    [1] =>
    string(1) " "
    [2] =>
    int(1)
  }
  [7] =>
  array(3) {
    [0] =>
    int(319)
    [1] =>
    string(3) "Foo"
    [2] =>
    int(1)
  }
  [8] =>
  array(3) {
    [0] =>
    int(390)
    [1] =>
    string(1) "\"
    [2] =>
    int(1)
  }
  [9] =>
  array(3) {
    [0] =>
    int(319)
    [1] =>
    string(3) "Bar"
    [2] =>
    int(1)
  }
  [10] =>
  string(1) "("
  [11] =>
  string(1) ")"
  [12] =>
  string(1) ";"
}

那PHP Parser呢？

array(1) {
  [0] =>
  class PhpParser\Node\Expr\Assign#9 (3) {
    public $var =>
    class PhpParser\Node\Expr\Variable#2 (2) {
      public $name =>
      string(3) "foo"
      protected $attributes =>
      array(2) {
        ...
      }
    }
    public $expr =>
    class PhpParser\Node\Expr\New_#8 (3) {
      public $class =>
      class PhpParser\Node\Name#7 (2) {
        ...
      }
      public $args =>
      array(0) {
        ...
      }
      protected $attributes =>
      array(2) {
        ...
      }
    }
    protected $attributes =>
    array(2) {
      'startLine' =>
      int(1)
      'endLine' =>
      int(1)
    }
  }
}

差異在於token_get_all是逐字分析，所以會需要做iterator做判斷，比較麻煩而且容易出錯；可是PHP Parser的話則是採用一句statement判斷，所以識別上更容易判斷這是同一段code。

關於PHP Parser的用法 - 怎麼拉出我要的function呢

一般而言一個class裡面會由很多function組成，大概像是這樣的感覺

每一個class底下的function都形成一個封閉的空間，像是$foo的話可以在其他地方使用嗎？不行，所以我們的目標很明確了，要把所有的class底下的function拉出來做分析
像是Example.php

拆開之後會變成像是這樣

接著就是解開單一個function就好了喔！

幾個需要特別注意的東西

PHP裡面有幾個關鍵字比較特殊一點，它們分別為this、parent、self、static，它們的關係可以簡單畫成下面這張圖

只有parent獨立出來(只能拉extends)，其他的繼承parent又可以算是自己的function，這裡都需要特別處理，譬如this可以拉到parent及自己，但是parent只能拉到自己類似這些情境。

最後，奉上專案位置，有問題歡迎給issue或是PR，可以的話順便留star吧！

https://github.com/CapsLock-Studio/FilterClass