SHOWROOMの新規開発にHyperappを採用した話

こんにちわ、エンジニアのきむらです。現在は主にフロントエンドを担当しています。

今回は、SHOWROOMの新規機能開発にHyperappというJavaScriptフレームワークを採用したので、そのお話をします。

はじめに

SHOWROOMは、ターゲットのプラットフォームをPC / iOS / Androidとしていますが、 iOS / Androidではアプリ内でWebViewコンポーネントを利用しWebページを表示している画面がまだ数多くあります。

既存のページは以下のJavaScriptフレームワーク / ライブラリを使用しています。

JQuery（https://jquery.com/）
Underscore.js（https://underscorejs.org/）
Backbone.js（http://backbonejs.org/）
Marionette.js（https://marionettejs.com/）

数年前に流行ったBackbone.jsからなるクライアントサイドMVCを構成するためのモジュール群です。ですが、今の世の中の流れは完全に仮想DOM一色、SHOWROOMもこの流れに乗りより機能の変更に柔軟に耐えうる、低コストかつ高速描画の可能なフレームワークを採用することにしました。

f:id:hkmn:20180707121817p:plain:w256 ＜乗るしかないこのビッグウェーブに！

仮想DOMとは

仮想DOMは、VirtualDOM、VirtualNode、VDOM、VNodeなどとも呼ばれます。もうすでに数年前から仮想DOMに関しての記事は山程出ているため、いまさらこの記事で紹介するまでもないのですが

ものすごく簡単にご説明すると

「ブラウザ自体が画面の変更に対して行っていた処理を、JavaScriptで肩代わりすることで高速にレンダリングする技術」

です。

ブラウザは画面の構成要素をDOMという単位で管理しますが、これをJavaScriptで「仮想のオブジェクト」として管理することでブラウザ内で行われているDOMを直接操作することをせず、モデルとビューのデータバインディングを行うことができます。

仮想DOMを採用しているライブラリ

有名なものとして以下が挙げられます。

f:id:hkmn:20180710194228p:plain:w128

React.js（Facebook社製ライブラリ https://reactjs.org/）

f:id:hkmn:20180710193746p:plain:w128

Vue.js（Google社のEvan Youさん個人が開発したライブラリ https://jp.vuejs.org/index.html）

今回の開発で採用するにあたって

ここで一旦SHOWROOM自体の機能について一度ご説明すると、大きく分けて以下の２つで成り立っています。

配信を視聴するための画面（様々な画面要素が存在し、通信が頻繁に発生する）
それ以外の画面（簡単な設定変更のみを行うページや検索や記事的なページ）

今回新規で開発する画面は、後者であったため、複雑な処理は行う必要がありませんでした（実際に開発した画面の詳細は後述）。

そのため以下の点から、上記２つのライブラリは今回の開発には利用しないことにしました。

要件を満たすにはすこしオーバースペックである（機能は充実しているが、そこまで利用しない）
学習コストが高い（ライブラリ独自のお作法、周辺ライブラリの選定等、導入にあたって学習・検討しなくてはいけない内容が多い）
一度採用すると、そのライブラリを剥がしにくい（がっつりフレームワークに依存した処理が多ければ多いほど、書き換えコストも増大）

Hyperappについて

f:id:hkmn:20180710194336j:plain:w128

Hyperappは、JorgeBucaran（https://github.com/jorgebucaran）さんが開発している仮想DOMを実現しているライブラリです。

https://github.com/hyperapp/hyperapp

昨年末にIncrements社が運営するプログラマーコミュニティ「Qiita」において、ReactからHyperappに置き換えたことで話題になりました。 JorgeBucaranさんは、Qiitaの中のひと（2018年現在）で、独自に開発していたHyperappをオープン化しています。

今回、Hyperappを採用したのは以下の理由からです。

ライブラリ自体がとても軽量
学習コストが低い
ビューの管理にJSXをサポートしている

ライブラリ自体がとても軽量

ライブラリは１ファイルのみ、行数も４００行未満、とてもシンプルな実装で軽量です。自分で１からコードを読むのも全く苦ではないレベル、仮想DOMの考え方や実装を学ぶにもとてもよいライブラリだと思います。

学習コストが低い

先に述べた通りReactやVueは、学習・検討しなくてはいけない内容が多いのですが、Hyperappはこのライブラリ固有の考え方がとても少ないため導入が容易で、プロジェクトにあとから参加するメンバーがいても学習コストを低く抑えられます。

ビューの管理にJSXをサポートしている

同様にJSXをサポートしているReactに仮に置き換える必要がでたり、今後Reactで開発する必要がでてきて場合でも書き換えが容易であり、モジュールの共有がしやすいと考えました。

（JSXについて：https://facebook.github.io/jsx/）

以上から、Hyperappを今回採用しました。 Hyperappの利点は、QiitaにJorgeBucaranさんが記事をあげていますのでそちらも参照するとさらにわかりやすいかと思います。

Hyperappのアーキテクチャ

Hyperappは以下の３つのモジュールで構成されています。

State

プレーンなJavaScriptオブジェクトであり、アプリケーション全体の状態を管理します。

Actions

Stateを更新するための処理群を管理します。このオブジェクト配下にある処理のみがStateを更新できます。

View

仮想DOMを実現します。ActionsによってStateが更新されるたびにViewが再描画される仕組みになっています。

以上がHyperapp独自の考え方のすべてなので、学習コストはとても低いといえます。

実際の開発について

ここからは、実際に開発した画面について、どんな構成にしたのか、どんなところでハマったのか、等を共有できればよいなと思っています。

（コストが低いのにハマったのかよ、というツッコミはまあ初期導入は得てしてそんなものだということでご理解ください。。。）

開発した画面

SHOWROOMは、ユーザの分身をアバターで表現しています。仮想ライブ空間では、配信画面上にアバターがたくさん表示されており、いわゆる「ライブ感」を演出しています。

ユーザはアバターを頻繁に着替える機会があるのですが、着替えるための画面が使いにくいという声がユーザさんから多数上がっており、この画面をより使いやすいように改修することになりました。

機能は以下の通りです。

アバターのリストをページ送りで確認できるようにした。
条件で絞り込みできるようにした（使用した履歴 /「お気に入り」）。
アバターを「お気に入り」設定し、管理できるようにした。

画面イメージ：PC

f:id:hkmn:20180708005259p:plain:w512

画面イメージ：アプリ

f:id:hkmn:20180708001945p:plain:w256

実際の画面はログインが必要です。

（PCの場合）

https://www.showroom-live.com/

左メニューより、ログイン -> マイプロフィールアイコン -> アバター着替えはこちらバナーをクリック

（アプリの場合）

‎「SHOWROOM-ライブ配信ならショールーム」をApp Storeで

play.google.com

左メニューより、ログイン -> マイページ -> 編集 -> アバター着替えはこちらバナーをクリック

または、

配信画面で画面下自分のアバターをクリック -> アバター着替えはこちらバナーをクリック

ぜひ使ってみてください！

開発環境

以下のような構成にしました。

JavaScriptライブラリ

Hyperapp 1x（アプリケーション全体の管理）
Hyperapp router（ルーティングの管理、今回はページ送りで使用）
axios（非同期処理）

開発言語

TypeScript（https://www.typescriptlang.org/）

Flowでもよいのですが、現状TSをサポートしているライブラリのほうが多いのでこちらを採用。

JSX（TSX）

スタイルライブラリ

Bootstrap 4（https://getbootstrap.com/）

Showroom独自のコンポネントとテーマを適用しています。

タスクランナー

webpack 4（https://webpack.js.org/）

（既存の画面もwebpack 4を使っています）

ディレクトリ構成

.
├── dev
│   └── pages　（webpack-dev-serverのrouting）
├── src
│   ├── api　（非同期処理まわり）
│   ├── components　（共通コンポーネント）
│   ├── ext　（外部ライブラリ）
│   ├── icon　（SVGアイコン用tsx）
│   ├── img　（静的画像）
│   ├── pages　（ページ固有の処理）
│   │   └── UserAvatar
│   │       ├── actions
│   │       ├── components
│   │       ├── icon
│   │       ├── img
│   │       ├── index.tsx
│   │       ├── state
│   │       └── utils
│   ├── typings　（TypeScript型定義ファイル）
│   └── utils
├── tsconfig.json
└── webpack.config.js

開発する上でのルール

以下のようなルールを最低限のコーディング規約としました。

Actionsの命名規則

とくにHyperappによらない話で、Fluxを使った場合でも決めたほうが複数人の開発がスムーズになります。

今回Actionsの命名規則を、

「誰が」「どこを」「何をしたか」

で定義するようにしています。具体例は以下のような感じです。

// ユーザ操作
// ユーザが、アバター画像を、クリックした
userAvatarImageClicked: (id: number) => (state: State) => ActionResult<State>

// システム
// システムが、Appコンポーネントを、起動した
systemAppLaunched: () => (state: State, actions: Actions) => ActionResult<State>