點一點、滑一滑、捏一捏，聊聊輸入處理
這篇文章會深入聊聊 StitchPress 的輸入處理是怎麼設計的，有點像是把架構拆開來看的拆解文。不過我們會盡量不用術語，就算你對程式或技術沒那麼感興趣，應該也能有些收穫。就把它當成一篇開發日誌吧：StitchPress 有大量需要動手操作的地方，我們想讓大家知道，這些操作背後，我們都是認真思考、仔細設計過的。
一台裝置都不能少
在 StitchPress，我們希望盡可能照顧到各種裝置：桌機、手機、平板等等，也希望支援各種作業系統和平台：macOS、Windows、Android、iOS 等等。要做到這點，我們有兩條路可以選：
- 替每個平台各寫一套原生程式。
- 善用網頁技術，以及幾乎每台現代裝置上都有的東西：瀏覽器。
我們選了第二條。原因很簡單：我們沒有足夠的人力，替所有想支援的平台一一寫原生程式。話雖如此，第二條路也不輕鬆，只是比較做得到。
目前，StitchPress 在主流桌面作業系統（Windows、macOS 和 Linux）的瀏覽器上，支援鍵盤加滑鼠、鍵盤加觸控板這兩種操作方式（其他 Linux 發行版可能還需要進一步確認，但 Ubuntu 和 Arch Linux 已經確認可以使用）。Android 和 iOS 的平板、手機等觸控裝置也都支援。不過，這些可不是瀏覽器內建、開箱即用的功能。細膩的輸入處理，尤其是在無限畫布上，需要在程式架構上好好設計，再加上大量又瑣碎的細部調整。
幕後功臣
StitchPress 背後的小團隊 Kinnet Studio，一直在開發各種以「無限畫布」為核心的網頁應用。一路做下來，我們整理出一系列叫做 ue-too 的開源套件，專門協助打造無限畫布應用，特別是讓可視範圍（viewport，也就是畫面上看得到的那塊畫布）跟著你的操作移動的部分。如果你是開發者，歡迎來看看：原始碼放在 GitHub 上，套件則可以從 npm 安裝，其中負責控制可視範圍的是 @ue-too/board。StitchPress 也是以 ue-too 為基礎打造的。
所以，實際上到底是怎麼運作的？
要了解 StitchPress 怎麼處理你的操作，得先從瀏覽器的事件機制說起。每當你按下滑鼠按鍵、滾動滑鼠滾輪，或是按下鍵盤上的按鍵，瀏覽器都會發送一個「事件」給頁面上正在執行的程式。不過，程式並不會收到瀏覽器提供的所有事件，而是透過「事件監聽器」告訴瀏覽器自己想收到哪些事件，只接收在意的那幾種。所以，如果程式想知道你什麼時候按下滑鼠左鍵，就會去監聽 mousedown 事件。程式能監聽的事件種類非常多，足以組合出 StitchPress 正常運作需要的所有操作。
瀏覽器的事件機制設計得很有彈性，但彈性是有代價的：複雜。輸入事件是可以組合的。舉例來說，如果你想讓使用者像在 Figma（以及許多其他無限畫布應用）裡一樣，按住空白鍵、拖曳滑鼠來移動畫面，就得同時監聽鍵盤事件和滑鼠事件。麻煩的是，你沒辦法把想要的事件合併到同一個接收端；每種事件都有各自的接收端，你得把它們協調好，才能在對的時機開始移動畫面。需要的輸入事件越多，就越難把它們全部管好。
為了對付這種複雜度，StitchPress（建立在 @ue-too/board 之上）用上了「狀態機」的概念。簡單來說，狀態機就是一台有好幾種「狀態」的機器。不同的狀態面對同一個事件，處理方式也不一樣（甚至完全不處理），而事件也能觸發狀態之間的轉換。百聞不如一見，下面準備了一個小範例，展示無限畫布是怎麼處理你的操作的。範例裡負責處理輸入的狀態機，就直接畫在無限畫布上，而且會即時反應：當你在畫布上移動、縮放時（記得用下拉選單切換成你的輸入方式），就能同步看到狀態轉換和事件的發生。這個範例精簡到只剩移動、縮放這類基本的畫面控制。
StitchPress 會依照不同用途使用好幾個狀態機，但基本原理都一樣。還有一些更進階的用法，例如擴充現有的狀態機（可能是別人寫好的），StitchPress 也有用到，不過那就超出這篇文章的範圍了。狀態機套件 @ue-too/being 有一個說明文件網站，裡面有更詳細的解說和使用指南。如果你也想在自己的專案裡用用看狀態機，歡迎去逛逛。
這篇差不多就到這裡告一段落。這次的內容比較偏向開發者，跟鉤針編織或手作圈可能沒那麼貼近；但我們還是想讓大家知道，在 Kinnet Studio，使用者體驗是我們設計 StitchPress 時非常重視的一環，我們絕不馬虎。
StitchPress 目前還在 pre-alpha 階段，我們正在積極尋找鉤針織圖設計師，一起打磨使用體驗。如果你有興趣，而我們還沒跟你聯絡，歡迎寫信到 contact@kinnet.studio。想追蹤 alpha 和 beta 測試的消息，歡迎加入候補名單：