Rive 畢竟是一個蠻新的東西，所以不得不承認，有一些細節還沒有那麼成熟，有一些奇怪的雷。這些雷分布的蠻發散的，但又會影響開發與使用體驗，所以趁這個機會，把這些東西整理一下。
首先不免俗的要提一下，畢竟是新東西，更新的很頻繁，所以如果遇到某個功能不能用，或是有某個 bug，很有可能只是你還沒更新到最新版而已，官方文件有特別列出各個 feature 支援的版本。
這是一個奇怪的 bug，State Machine Inputs 是一個陣列，所以 inputs 順序很重要，例如你的 inputs 可能長這樣。
[inputA, inputB, inputC]
但每次用 Rive Editor 重新打包輸出新版本的時候，這個順序有機會亂跳。
[inputA, inputC, inputB]
這會造成蠻大的困擾，畢竟這幾個 input 分別代表不同的參數。而且有可能一個是 boolean 或 number，另一個是 trigger，型別不一樣，裡面的 state 或 method 也不一樣導致報錯。通常也不會特別幫這一段包 try catch，所以一個不小心，有可能導致整個應用 crash 掉。
據我所知這應該是 Rive Editor 的 bug，已經持續一段時間了，而且老實講，通常遇到問題的時候，也不會特別去懷疑這一塊。只能說輸出新的 .riv 檔後，要先在本地多測幾次。
就我個人的感覺來說，Rive 官方還是比較習慣 OOP，他們比較是用 class 的想法在做 Rive，所以有時候他們的 TypeScript 支援會有點……哪裡卡卡的。
例如這是 Low-level API 的 asNumber，他的功能是把 input as number，但他會回傳 SMIInput，SMIInput 的 value 又是 boolean | number？用常理來看，這是一件非常怪的事情，為什麼 asNumber 回傳的值有可能會是 boolean？
站在 TypeScript 的角度來看，應該開一個 generic 出來， 讓 value 的回傳值可以被寫死，如果這樣寫的話，或許可能不用 asNumber 這種 function。就算不用 generic，至少也要想辦法用 inference 的方式，讓 TypeScript 自動推論出回傳的 type，而不是寫死成 boolean | number | undefined。
類似的問題其實蠻多的，散落在各個部分的程式碼裡面，我是覺得 Rive 因為不只想支援 JavaScript 的關係，他們有很大一部份的客戶是用 Flutter 或其他 native language，這些語言雖然也有 type 的概念，但畢竟是 OOP，思考邏輯還是跟 TypeScript 會有點水土不服。這點有點難解釋，但他是存在的，只能說在用 TypeScript 寫 Rive 的時候，有些跟型別有關的地方要多留意一下，必要的時候多用斷言處理。
其實站在其他語言的角度來說，可能 TypeScript 才是那個讓人水土不服的怪胎就是了🥹🥹
最後是一個偏設計的問題，Rive 本質上是一個做動畫的工具，但很多人會想拿他來刻整個 UI，例如這樣。
我可以舉出很多拿 Rive 刻 UI 的缺點，例如檔案容量太大、不好掛事件、RWD 不好支援、太過笨重不好做一些操作等等，但這都不是重點，重點在於「拿本來被發明做 A 的工具去做 B」這件事本身就是一個缺點。
可能是我比較笨吧，但就我的經驗來說，在資訊流通的現在，Somebody has already solved your problem，每個問題通常都已經有最適合他的 solution，如果這個工具當初不是被設計用來做他的，那一定有他的理由，不要自作聰明另闢蹊徑，不要小看群體智慧。這跟投資一樣，市場不一定永遠都是對的，但大部分的時候他最終都會是對的，至少比我們還對。
現在 Rive 社群上還是可以看到很多人在做 UI，但通常沒有一個是真的可以用的。Rive 是一個動畫工具，所以你要做的是拿他做一個一個動畫，輸出成動畫素材，再乖乖用 HTML, CSS, JavaScript 加上這些素材堆出 UI。
不要自己發明輪子跟工具，幾百萬年前原始人就已經證明圓的輪子比較好用了，就不要自己再敲一堆三角形輪子來拉車，再來跟大家說「喔根據我的實驗輪子是圓的比較好」。
以上都是一些比較零碎、發散、但又有一點重要的問題，這些問題如果我當初早點知道的話，應該能再省下不少開發時間（State Machine Inputs 亂跳的問題真的很坑害我當初罵了一推設計師好幾次對不起🥲🥲🥲），所以在這裡紀錄一下。
iThome鐵人賽
看影片追技術