作為一個前端使用 React Native 開發新產品的半年小心得

Standard

本文大綱

  1. 前言
  2. 團隊組成
  3. React Native
    1. 跨界踩坑
    2. 從 Web 到 App
    3. 升級 – 停看聽
    4. 團隊使用的工具與套件
  4. 其他:專案流程

前言

最近滿忙碌的,租屋約到期搬家、恢復長途通勤的日子,而工作上的話,則是團隊終於釋出新增社交元素的新版 App。雖不是什麼劃時代的產品,這個階段也只增加了一些留言討論、按讚等功能(接下來還是有其他新的功能的 :P),不過仍算是個小里程碑,忙碌的事情也暫時告一段落了,便想藉本文記錄一下這半年多*來使用 React Native 開發新產品的心得。

*半年多:實際上,新產品的開發期、基礎建設等約在三個月內,而前三個月是我輪調至 App Team 進行既有的 App 功能開發與維護

歡迎有興趣的朋友歡迎下載試玩看看!



我對投資沒什麼涉獵,也沒閒錢投資 😭 因此本文僅作為一名前端開發者的角度來記錄心得~

團隊組成

App team 團隊組成是 1 Director(也有參與前端開發)、3 名前端 (其中 1 名是 0.5 DevOps + 0.5 前端)、3 名後端、1 名設計、1 名 PM。

沒有 QA,也沒有原生 Mobile App 工程師。

前端的部份是純寫 JavaScript(React Native),不涉及後端開發。前端們原本都有用 React 開發 web 專案經驗。

另外有專門負責 Web 產品的團隊,配置有同等人數的前、後端工程師。

React Native

跨界踩坑

雖然沒那麼美好,但越來越好了

記得剛輪調去 App team 的時候,才剛要把專案跑起來就遇到很多問題,例如環境問題啦(node 套件、ruby 之類的)、Xcode 的設定問題、Apple Developer 的憑證等等的。

雖說現在要寫一個 Web 的前端專案,使用的工具、事前的準備也越來越複雜,但作為一個 Frontend,初接觸到 React Native 的專案真是頗挫折的,當時面對 Xcode 的 IDE 嘗試了兩天,當時的 OS 是 「…連要跑起一個專案都跑不起來,人生好難…」 ,結果發現是一個很蠢的步驟問題而已 😂

記得聽已經接觸半年的同事說,這時候其實 React Native 的專案開發已經不像更早期的「蠻荒時代」了。坑是越走越少,一些常踩的雷也因為前人的踩坑心得筆記累積而能夠避開。嗯,為此我也補了很多血淚筆記到專案的 README 中 😆

不過這些問題對原生 App 工程師來說應該是小菜一碟,如果團隊內有可以請教的 App 工程師那應該能少走上不少冤枉路 😆 若要更能隨心所欲地開發,也許還是得要補上原生開發的相關知識/人力吧。

現在若問我覺得用 React Native 專案的開發感想如何呢?以一個前端工程師來說,半年過去了,我覺得雖然開發體驗沒那麼美好,也的確會遇到意想不到的坑,但比起一年前,React Native 的確越來越好了,生態圈也越來越成熟。

繼續閱讀…

使用 React Native 與 Amazon Cognito 實作 Google & Facebook 登入的功能

Standard

最近開始接觸 React Native 的專案了,能用前端技術跟知識同時開發 iOS/Android App 滿新奇的!雖然缺乏原生 App 的知識讓我踩了不少坑,其中不少還是非常低能的坑 XD!

這次實作的任務是要在 App 加上 Google/Facebook 登入的功能,而會員系統是建構在 Amazon Cognito 上面的,再加上 React Native 的相關套件 – react-native-facebook-loginreact-native-google-signin 來實作 App 中的登入功能。其中有些設定上的眉角讓我花了不少時間嘗試,所以整理成本篇的筆記備忘囉~


本文大綱

本篇文章滿長的,所以先整理大綱在此,了解一下會介紹到的部份:

  • 本文的套件版本
  • AWS SDK React Native 與 Amazon Cognito
  • react-native-facebook-login
  • react-native-google-signin
  • 繼續未完的 Amazon Cognito 設定
  • 前端程式
  • 疑難排解
  • 用 Amazon Lambda 來做 Serverless API
  • Amazon API Gateway
  • 在 App 端補上註冊(register)的 function
  • Source Code
  • 參考資料

繼續閱讀…

淺談使用 Appium 進行 React Native 雙平台(iOS & Android)App 的 E2E 自動化測試

Standard

前言

先前在公司的產品流程中導入了單元測試的部份,而最近手上的任務是為 App 產品導入 E2E 測試(End-to-End Test)。由於目前的公司團隊沒有 QA 人員,因此每次產品新版 release 前都必須仰賴工程師自己與產品 Owner 等成員自行手動測試(Manual Testing),隨著產品功能越來越龐大,這個過程越來越曠日費時,也無法確保每次都能測到所有的項目,因此才會有導入 E2E 測試的想法。

本篇文章視角是給像我一樣的非 App 工程師(例如從沒接觸過原生 App 開發、準備踏入 React Native 開發的前端工程師)的經驗分享,又因公司 App 產品是用 React Native 寫的,所以也會提到一些 React Native 在搭配 Appium 測試時需要注意的一些部分(一點點啦)。這也是我首次嘗試 E2E 的測試,著墨不深,有不精確或誤導之處,一樣請偷偷告訴我以便修正文章囉 :)

自動化測試中的 E2E 測試與比重

自動化測試(Unit test、Integration Test、E2E Test)能為產品的品質帶來更多信心,E2E 測試更是貼近真實使用者的情境下進行整體性的操作測試,「專注在真實使用者情境」--嗯,聽起來 E2E 是很值得投資的事情!不過 Google Testing Blog 曾在 2015 年的 Just Say No to More End-to-End Tests 中提出一些不同的思路。

繼續閱讀…

使用 Jest 進行前端單元測試

Standard

去年底在公司分享了關於使用 Jest 進行前端單元測試的議題,簡報版本在此,現在將其整理為文章以方便日後查詢與閱讀。

前言

從事前端工作也幾年了,先前有諸多原因都未能在公司產品上實行單元測試,例如做功能都來不及了,哪有時間寫測試、程式寫的太過耦合難以測試之類的。

我以前只在個人的 side project 上寫過單元測試,也的確感受到「測試能夠減低重構時不致無意間把原有功能搞壞就釋出的風險」帶來的好處。而這次算是我第一次在公司產品上導入單元測試,在測試的領域還算是新手,這篇文章便作為新手的個人筆記,有什麼錯誤的部份請偷偷告訴我 :)

再提一下情境:我們使用 React + Redux 進行 SPA (Single Page Application) 的前端網站開發,是前後端分離的開發模式,後端團隊出 JSON 格式的 API 給前端進行資料串接。在 Scrum 會議中 Story Refinement Meeting 開 Story 的 Sub tasks 都會特別開 Unit Test 實作的票。

Why Jest?

為什麼選擇 Jest 呢?跟最常拿來被比較的 Mocha 來說,從 Jasmine 發展而來的 Jest 本身對於 React 的整合度挺不錯的(而且是 Facebook 自家的,釋出與修正速度可靠許多),而且本身也整合好了斷言 (Assertion)、Mock 等 Library 以及 Coverage 報告功能,還有滿特別的 Snapshot 測試,以及優秀的 watch 模式可以只測試當次更改的檔案,最重要是它的設定頗好上手的。

繼續閱讀…

主機搬遷至 Vultr 與其他瑣事

Standard

居然已經超過一年沒發文了! 😱 趁著這次主機搬遷至 Vultr 發文做個記錄吧。

主機搬遷至 Vultr

由於去年底換工作之後必須出外租屋了(說好的上班不打卡呢 😫),跟原本的計畫配置有些落差,所以日常花費能省則省,網站主機也想租便宜點的,便從最低每月 5 美元的 DigitalOcean 搬到只要 2.5 美元的 Vultr 了,而且在日本有個點,想試試看的話可以透過 推薦連結註冊 申請 。(可…可惡,這麼久沒發文一發就是業配)

繼續閱讀…

使用 Sketch 改善網頁前端與設計的標註與合作方式

Standard

前言

身為一名網站前端工程師,關於「工程師與設計師如何進行合作,進而能完成更好的作品」一直是個讓我感興趣的議題。

當然這個議題範圍相當廣泛,從規格規範、工作流程、彼此的換位思考,到各式能提昇效率的工具等等。

去年認識了幾位網頁設計領域相關的朋友,在工作之餘的分享小聚中,得知「Sketch」這個好用的應用程式,它似乎能改善工程師與設計師合作時遇到的許多痛點。

今年才來介紹 Sketch 是有些 Lag,不過還是紀錄一下我的試用過程吧。


合作時遇到的痛點

由於每間公司的工作流程,以及部門配置都不大一樣,因此每個人在這段合作過程中遇到的痛點也各有不同,就簡單列一些我遇過,以及從其他前端、設計朋友那邊聽過的吧。

  • wireframe -> mockup -> prototype 一套標準,各自解讀。
  • 工程師怎麼都不照 mockup 實做,出來的成果總是歪嘴眼斜。
  • 少了設計眼的工程師,實做時對於色碼與間距總感受不到細微差異。
  • 在工作流程中加入「設計師必須提供 mockup 及 design spec」的流程,但標註每個細項(間距、寬高、色碼等)實在是曠日廢時且無趣的工作。
  • 標註出來的規格表密密麻麻,讓人看到脫窗,很可能還會漏標或是漏看。
  • 設計師缺乏元件化的概念,每一個單元的按鈕都有不知道是不是手誤造成的些微差異,無法重複沿用。
  • 想要針對設計稿進行討論再實做,但不知怎麼進行。
  • 有些公司裡設計師不負責製成網頁,但是 PSD 圖層又亂得毫無章法,要切圖與排成網頁很讓工程師頭痛。
  • 要準備 @2x 跟向量 SVG 切圖相當麻煩。
  • 工程師拿到設計稿進行網頁實作時,PM 也沒提供文案,只能開 PSD 複製文字或是自己打。
  • 需求是個 RWD 網站,但設計稿只做了桌面版的大小,其他規格總是被遺忘,只好自己腦補。
  • 各種腦補。

等各式各樣的問題。


Sketch

嗯,不是那個作 3D 模型的 Google SketchUp,在 Google 搜尋常會誤搜到 SketchUp 的教學,哈哈。

那麼 Sketch 能幫助我們什麼呢?當然,必須先說的是,它並無法解決所有的痛點,有些問題其實不在工具。

Sketch 是一套 Mac Only(Windows 的朋友們抱歉了 :P)的向量 UI mockup 設計工具,比起最常被使用的 Adobe Photoshop 跟 Adobe Illustrator,Sketch 它:

繼續閱讀…

淺談 Google App Indexing

Standard

App Indexing (圖片取自 App Indexing – Google Developers)

前言

上一篇 談到 Facebook 推出的 App Links 標準,為 Apps 之間的連結跳轉帶來解決方案,而 2015 的 Google I/O 大會推出的 Android M,其中一個亮點就是推出它們對於跨 Apps 跳轉的解決方案 — 也叫 App Links — 但它是透過 json 檔設定實現,這邊就不多做介紹了,有興趣可看 HOKO 的這篇介紹

而這篇要介紹的是關於 Google 的 App Indexing ,在這個行動裝置當道的時代,App Indexing 的出現便是為了讓 Google Search 亦能搜尋到 App 中的內容,甚至點擊搜尋結果就直接讓使用者透過 Deep Link 連到 App 內的特定頁面。

還是有些抽象?那麼先來看看 Google Developers 釋出的這支影片,有趣地介紹了實際應用的情境。

繼續閱讀…

關於 AppLinks 兩三事

Standard

App Links

前言

在行動裝置時代,使用者更常停留在 App 中瀏覽資訊(像是 Facebook),而相對地在 Web 的停留時間就降低了。過去我們在 Web 上透過超連結搭起不同網站之間的橋,而在 App 與 App 之間又如何做到這件事呢?

當然,我們可以透過 URL Scheme 開啟應用程式,但我們並無法得知世上每個 App 的 URL Scheme,甚至是應用程式某個頁面 Deep Link 的 Scheme,而且萬一哪天增修了那又該如何?

我最近一部分的工作就在研究如何加強 App 於 Mobile Web 上的連結體驗,其實各大廠早提出了自己的構想及標準,例如 Google 提出的 App Indexing,以及 Facebook 提出的 App Links。

今天就 App Links 的部份做個簡單筆記與實作參考。App Indexing 等下次有空再寫文介紹囉。

繼續閱讀…

[Web][JavaScript] 有安裝 App 便開啟 App (透過 App URL scheme),若無則導去下載 (Google Play/App Store) 的 workaround

Standard

前言

製作案件上遇到的需求,若使用者有安裝 App 便開啟 App (透過 App URL scheme),若無則導去下載 (Google Play/App Store)。

在 App 內這件事應該是可掌控的(在自己做的 App 中攔截特定網址做處理),但在網頁上要做到這件事就有點麻煩了。一般常見的作法是擺個 Smart Banner,不過只有 iOS Safari 原生就支援,其他的得靠 jQuery Smart Banner(前陣子我也貢獻了修正 Windows Phone 相關錯誤的 pull request :P) 這類的第三方 plugin。

但 Smart Banner 和案件的需求還是有些差異,得靠其他方法解決,在實作的過程中遇到一些小問題與相應的 workaround,特此記錄。

實測環境

跟公司 QA 部門借了幾台機器,以及測試的瀏覽器分別是:

  • iPhone 5S(iOS 8.1.0) – Safari
  • LG G3(Android 5.0) – 內建瀏覽器、Chrome Android 43.0.2357.93、Facebook inapp browser(核心為 Chrome 30.0.0.0)
  • ASUS ZenFone 5 – 內建瀏覽器、Chrome Android 40.0.2214.89
  • SONY Z3(Android 5.0.2) – Chrome Android 43.0.2357.93

服用本文前請注意:也許瀏覽器版本更新後,本文的方法就失效了,所以請作為參考就好哦。

實作與問題

之前在案件中,使用下面這段程式碼作為 workaround:

setTimeout(function() {
  window.location = scheme_link;
}, 25);
window.location = download_link;

註:其中 scheme_link 是 app 的 scheme,可以是單純開啟 App,或是直接進入 App 的某一個畫面。而 download_link 是下載 App 的 URL 連結,像是 Google Play 或是 App Store 的連結。

之前實測時,在裝置上大部分情況都能如預期的運作,但仍有特殊情況(如特定版本的 Chrome、Android Stock Browser)有點小問題。

而隨著瀏覽器版本更新,這次案件再實測似乎就會出現更詭異的情況了,例如同時打開 App 與 Google Play/App Store 的連結。

於是再度至 stackoverflow.com 尋找其他解決方案,找到 一個 2014 年 8 月左右被更新的解答

我針對該解答再做些微調後的 workground 整理說明如下:

繼續閱讀…

近況與 React 初體驗

Standard

好一陣子沒有更新部落格了,年初到現在依然在渾沌瞎忙碌中度過,讓人有些倦怠,暫時沒寫文的靈感。

不過這篇也不是技術文,就當給蜘蛛網密佈的部落格澆個水吧…。

那麼,這陣子除了工作之外,還做了什麼呢?


參加 Modern Web 2015

距離上次 WebConf 2013 也好久了,參加這樣的大型研討會對我來說就是吸收新知,了解一下現在職場上大家都玩些什麼東西。

社交嘛…個性低調的我對在社群 social 總覺得彆扭不自在 XD 還是跟同行的朋友聊聊、交換筆記就好。

  • 最喜歡的場次:
    • 唐鳳 的 《開源之道》
       非技術場,但講到一些社群中人與人間相處、溝通的觀念相當有感觸呢,同理心、分享、尊重等等,在職場、交友上也很受用。

  • 前端相關場次:

    • 阿當 的 Pinkoi 把手機版網站變好用了
       WebConf 2013 中阿當 分享的場次 相當有收穫,這場關於 Pinkoi 手機版網站優化的經驗分享依然如此。
       雖說有些我已經有在工作中實做過了(例如 RESS、pushState、PageSpeed),但也有許多細節未曾注意到。
       在與設計師合作、給使用者更佳的體驗、前端效能細節方面,前端還有好多部分可以努力的,希望自己也能繼續往這方面精進。

    • Chris 的 從技術角度看 Responsive Web Design
       講者分享了許多 RWD 實作技巧,而其中講到跟 PM、設計師溝通這部分特別讓我會心一笑啊 XD
       我覺得設計師、PM 能擁有網頁基礎概念的話…,嗯,應該說是無論職務,都能對彼此的領域有所涉略、了解彼此的難處與需求的話,在實做產品上能夠有很大的幫助啊。(消弭認知落差、找到彼此合作的最佳解)

    • Eric Chuang 的 當網頁遇上原生 App
       由於我目前待的公司主要產品是 App,也曾有人提過想用網頁技術來實做 App 中的內容頁,「用網頁來做,覺得這樣成本比較低」,但身為第一線網頁前端開發才會了解 – 實際上其中血淚與坑的成本並不會比較低 XD
       看到簡報中介紹各家手機廠自幹 ─ “Improve” ─ 原生手機瀏覽器導致的後果與靈異事件,真的是心有戚戚焉(哭)。

針對這些前端場次,我也在公司的開發者分享時間做了個大補帖式的分享了 XD

不過比起 WebConf 2013,個人覺得這次有點小失望呢,大概是門票價格跟我想聽的場次(跟我聽得懂的 XD)沒有成正比吧 Orz


不定期的週末技術小聚會

前同事牽線下,認識幾位前端、設計師朋友,分享彼此在工作上遇到的前端心得與疑難雜症,另外聽聽不同公司對於前端開發上的做法也滿有幫助的,無論是好是壞。

因為身為從來沒掛過前端工程師職稱的前端工程師,在公司想不斷針對前端開發、設計議題討論,總是有種難逢知音的感覺。

也許這種前端朋友間的交流是另一種解決方式吧…


React 初體驗

實做在公司專案上

覺得一直瞎忙很難進步啊,另外也想追一下前端圈滿熱門的 React,觀察到前端人力市場這個技術需求越來越常出現了。

所以抽空自己默默研究了 React,並在公司專案的某功能實做看看。從原本用 Python 接公司 API 再於 template 印出的方式,改寫為 React 元件。另外因為公司案子要兼顧 SEO,所以就在 Server 上透過 python-reactpython-webpack 跑專案的 React 程式,讓內容是可被搜尋引擎蒐錄的。

實做完的心得是 – 所有東西都元件化,拆解,然後被 React 規範該怎麼寫元件的原則下,寫起功能來挺能專注的,回頭看也比較清晰明瞭。


寫了兩個 React Components

手法還很拙劣,未來進步再來改進。

不過真的有包元件包上癮的感覺 XD


最近大概就是這樣,依然是在瞎忙 loop 中找些讓自己過得有趣一點的方式(遠目

啊,轉眼 2015 的一半就這樣過去了…