返回網站

開源專案 react-native-tappay 背後的故事

今天來聊聊這個專案背後的故事以及心酸血淚史,沒有太深奧的詞彙,大家就當故事看看吧。

· 團隊雜感

在 Verybuy 的第一個開源專案:

今天來聊聊這個專案背後的故事以及心酸血淚史,沒有太深奧的詞彙,大家就當故事看看吧。

三年前一開始決定要用 RN 開發 Verybuy App 之後,隨之而來的很大問題就是 payment,當時 Verybuy 已經在用 Tappay 了,但 Tappay 並沒有 react-native 的版本,當時我想說,先用 webview 擋著吧,也許哪天就有人開源了,或者 Tappay 會有官方支援 react-native。

這麼一等就是一年過去了,後來我才知道,我們只能當那個人

我依稀記得,那一年的冬天,當時負責的 PM 來找我:「Bingo,跟你說喔,這是原本 Android 的進購物車之後的結帳轉換率,這是新的 app 的結帳轉換率,你可以看到新的 app 上線之後,轉換率就直接掉了一個很大的斷層,我判斷是跟 webview 有很大的關係….」,一直不想面對自己接 native SDK 的我,看著這摔下的斷層,身為技術人,還是得接下這個重責大任。

payment 用 webview 會有各種問題,比方說無法得知使用者輸入狀態,卡在3d 驗證,卡在輸錯卡號,不小心跳離頁面等等。而且因為需要載入更多的資源,非常容易掉單,使用者好不容易要結帳了,卻卡在結帳,轉換率流失的看得我也是很緊張。

第一階段 Prototype

當時有熟悉 Android 的工程師,被我逼著要寫 react-native,雖然後來他還是比較愛 Android develop,預計一個多月要離開了,因此我將他身上的工作都排掉,希望他一起來協助開始這個燙手山芋。

於是我們開始嘗試直接呼叫 tappay 提供的 UI 元件來進行操作,這是他們官方提供的 demo。

broken image

其實看文件還算簡單理解,他有提供一個 TPDForm 讓你直接使用,可以簡單設定一些狀態顏色,等等。然後提供一個 FormUpdate 的 callback function,就可以接上你要串的行為了。self.tpdForm = TPDForm.setup(withContainer: Your View)tpdForm.setErrorColor(UIColor.red)
tpdForm.setOkColor(UIColor.green)
tpdForm.setNormalColor(UIColor.black)tpdForm.onFormUpdated { (status) in
if (status.isCanGetPrime()) {
// Can make payment.
} else {
// Can't make payment.
}
}

因此一開始我們很天真的想要可以在專案裡頭可以直接引入

 

看起來很完美,就可以完成信用卡輸入框。

採用的方法是 react-native native UI Component 來做出這個元件,當然 iOS/Android 是各自的 SDK,因此要用不同語言來實作。RD 也很給力的在離開之前給出了一個可以動的版本,並且可以順利的走完刷卡流程。不過很快的我發現有非常大的問題:

  1. 樣式不易調整,而且可以客製化的地方很少。
  2. 用 native UI Component 實作難以維護,畢竟是要寫 native code 來產生 component,跟原本用 js/ts 來撰寫 component 的概念不太一樣,除了對 native 程式的熟稔度,也需要對 component 的 lifecycle 非常理解。

因此樣式問題成了這個專案最大的阻礙。糟了卡關。

第二階段 刻 UI

真的要客製化的話就要用 Android 刻 UI,然後接入 tappay withoutForm,但這非常複雜,如果考慮到還有各種信用卡互動的行為(輸入信用卡號碼自動跳下一欄,檢查卡號為 visa/master 等等),等於是要完全重刻信用卡操作的行為,非常麻煩。

樣式問題困擾了我一陣子,某一天我突然想到,不對啊,前端不就都一直在刻樣式,UI/互動讓前端處理,愛長怎樣就長怎樣,等使用者送出再去 Call Tappay SDK 做檢查,將 UI 與刷卡流程分開處理,不就可以了嗎?這麼一來 UI 反而變成一件簡單的事情了。

為了驗證這個想法,我們很快的將幾個重要的 method 用 native modules 串接起來。!!可以(在心中雀躍了一番)!!

由於 native 層只處理刷卡,實作的方式也變得相對單純,幾乎都是字串以及成功與否的 response。Android 實作成功之後,當時還有一個 backend 同學以前有寫過 iOS,也被我抓來一起實作。

同一時間,我也請前端同學 survey 是否有現成的信用卡 UI,接下來就火力全開,Android/iOS/Frontend 全力衝刺最後順利接起來了。

broken image

下方的實作,隨心所欲客製化

第三階段 Open Source

其實在 open source 之前,我們還經過了很多 feature 的開發,加上 Line Pay 的支援,解決了許多互動之間的 bug,升級 SDK 等等。一直以來,我對公司產品公開到 github 都是小心翼翼的,一來是開發的時間與產品都是屬於公司的資產,沒有特別的理由為何要公開。

不過某一次聽到一位前輩 (Sam Huang) 分享他們開源了一個 library,卻反而被競爭公司使用了的經驗,其中有一個點我覺得很好:「其實開源就是飲水思源,如果這個開源套件不是你公司賴以生存的核心基礎,那開不開源根本無所謂。反之如果這個套件是你公司賴以生存的核心基礎,那你反而要思考為何這麼依賴這個套件。」這個觀點讓我留下一個很深的印象,我反思我們這個套件核心其實也只是去 call Tappay 的 SDK,我們也不是因為這個套件才成功的商業模式,Open Source 只是順手,除了讓開發能量可以被看到,又能實現開發人員飲水思源的理想,何樂而不為。

很快的我跟技術長與 CEO 討論了這個想法,他們也都蠻支持我的想法的,因此前端團隊就開始將 package 拆出來到 github 了,其實拆 package 的過程就是一個蠻有趣的過程,一方面開源等於裸奔,你會重新審視你的程式是否有任何問題,另一方面會解耦,消除許多複雜的 dependency,在團隊有適度能量時,我認為都是利大於弊的。

小結

這就是我們第一個開源的 library 的小故事。不過我印象最深刻的是將 UI 思維從 native 抽離的過程,直接看結論好像很簡單,但當初我們都落入的這個陷阱。將 native SDK 當成是 API 來呼叫一切都變得很簡單了。轉個想法路就通了,這真的很有趣。

另外就是開源對開發者激盪出的火花與熱情,我認為是很好的實作過程,在公司有餘力時順手做的話並不會多花很多時間。不知道業界對開源的想法怎樣?有多少用 tappay 的開發者?若有興趣一起交流也很歡迎。如果覺得這篇文章有幫助到你的話,也可以來 github 給顆星星,給我們的開發團隊鼓勵一下。

 

by 說完故事的Bingo

文章出處是Bingo的Medium Blog,內有其他相關技術與心得文,歡迎點閱