demoru.net でのサービス公開イメージ

demore.net とは、弊社で提供している SPA 体験サイトです。

SPA とは何か？ (アプリ利用者の目線)

Actor (アプリ利用者) にとってシングルページWebアプリケーション (以下 SPA) とは、いくつかの JavaScript ファイルと css ファイルで構成されている、ブラウザ上で動作するアプリです。

SPA は通常、ユーザ認証を行なってユーザを特定し、Web API を用いたさまざまな情報サービスを提供します。サーバサイドのデータベースやディスクスペースを利用することもありますが、これらのデータアクセスも例外はありますが Web API を用いています。

SPA ではない、従来のサーバサイドの Webアプリは、ボタンやリンクをクリックするごとに以下の動作を繰り返します。

ブラウザはサーバに情報取得要求 (リクエスト) を送出する (ex. 情報提供サーバに japan の covid-19 新規感染者数の日別データを要求する)
ブラウザはサーバからの応答 (レスポンス) を待つ
ブラウザはレスポンスを受信したらレスポンスに含まれる情報をブラウザ上に描画する
- 通常この描画はブラウザ全体を再描画する動作を伴う (ex. japan の covid-19 累計感染者数の時系列グラフを表示する)

ブラウザとサーバのやりとりは、このリクエストしてレスポンスを待ち、再描画するという「ギッコン、バッタン」スタイルで進んでいきます。

SPA は、必要なアプリケーションとデータを可能な限りまとめてブラウザに渡します。アプリの操作や、他のユーザからの操作によってブラウザ画面上の情報を変更する場合は、変更が必要な箇所だけを再描画する仕組みをもっています。「ギッコン、バッタン」スタイルから解放されることから UX は向上します。

SPA とは何か？ (開発者の目線)

いにしえの昔、SPA は javaアプレットや Adobe Flash などのブラウザプラグインに依存していましたが、現在は JavaScript を用いた実装になっています。2014年にオライリージャパンから「シングルページWebアプリケーション」(ISBN978-4-87311-673-0)という書籍が発行され、フロント (ブラウザ) 側だけでなく、バックエンド (サーバ) 側の Webサーバ (Node.js) とデータベース (MongpDB) もすべて JavaScript で実装するというアプローチが紹介されました。

しかしながら JavaScript でアプリを実装するというのは、小規模なものであれば実現可能でも、多機能かつ大規模なアプリ開発では非現実的と考えていました(個人の感想です)。しかし次のスタックを用いることによって、高品質なアプリをカジュアルに、なおかつ楽しんで開発できるようになりました。

重大な課題

弊社における SPA 開発には２点、課題があると思っています。

1点目、Google検索でヒットしない

SPA は JavaScript なので Google のクローラーは Webページとして認識してくれません。検索結果に反映されないので、SEO は別途検討する必要があります。

SPA でありながら、Google のクローラーにも評価してもらうには、Nextjs などを用いた、サーバサイドでの静的ページの生成が必要になります。Vercel社をはじめ、いくつかサービスがありますので SEO が重要な場合はこれらを選択することになります。

2点目、ブラウザの履歴が機能しない

SPA はなにも考慮していないと、ブラウザのリロードボタンを押すと、最初の状態に画面が戻ってしまいます。この動作がユーザに期待に反する場合には対応が必要になります。

解決策に複数ありますが、１点目の課題と同様に、Nextjs などを用いて、サイトURLが各アプリの画面を指すようにすることで、ユーザが期待する動作にすることが可能になります。

React + redux tool kit + TypeScript による開発

React

Facebook (現在 Meta) 社がつくってくれた JavaScript ライブラリで、2013年にオープンソースになりました。

コンポーネント単位での実装
- とかく複雑になりがちな UI 実装を、独立したコンポーネント単位に分割することができるようになり、地方分権を容易にしてくれた
- コンポーネントでは JSX という簡易 JavaScript 構文を使用することができ、複雑な JavaScript と同等の実装を HTMLタグのように簡潔に記述できるようになった
- React コンポーネントは JavaScript で実装することも可能だが、JSX で実装することによりプログラムの可読性が大きく向上する
フック (Hooks) の採用
- フックとは何か？　は後述
- React には組み込みのフックが用意されており、定番の処理を React らしく実装できる
- サードパーティが提供するフックが多く存在するので、難しい実装はこれらに任せることが可能になる
- カスタムフックの実装も容易でかつ実用性が高い
仮想 DOM の採用
- React は仮想 DOM を更新し、実際の (ブラウザの) DOM に対しては仮想 DOM との差分のみを反映することにより、効率のよい画面描画を実現している

フック (Hooks) とは何か？

フックは Reactコンポーネントをクラスを使わないで実装するための機能で、React 16.8 (2019年公開) より利用できるようになった。React コンポーネントの実装には、クラスコンポーネントと関数コンポーネントという２つの実装方式がある。Reactコンポーネントは、関数コンポーネント + フックを採用する方が容易でかつ簡潔に実装できる。

redux tool kit (RTK)

とても有用なライブラリであるが「アプリケーションの状態管理のためのライブラリ」というように簡単に紹介されてしまうことが多い。Reactフックを用いた実装になっており、2019年に公開されている。

state (ある状態、ステータス) を保持できる (ex. ログイン済、未など)
各コンポーネントは useSelectorフックを使って state の値を参照できる
各コンポーネントは useDispatchフックを使って state の値を更新できる
state の値は Redux Dev Tools でブラウザからいつでも参照することができる

RTK のおかげで複雑なデータ構造を持つ大規模アプリケーションであっても、データの見通しが悪くなることなく、快適かつ安全に開発を進めることができる。

TypeScript

TypeScript は、JavaScript の型定義を厳密にする「型付け」に特化した JavaScript のスーパーセット (JavaScript を拡張した言語) である。

TypeScript を用いることによって、コーディングにかかる工数は若干増加するものの、コーディングアップ時の品質が向上するので、トータルでの導入効果は高く「使わない手はない」環境といえる。ちなみに Web 上で見かけるサンプルコードも、TypeScript のものが圧倒的に品質が高い。

TypeScript は Microsoft社が開発した言語であるためか、VSCode との相性が良く、両者を採用することで最適な開発者体験が得られている。

開発環境イメージ

開発者のローカル環境に、プロジェクトごとの Dockerコンテナを立てて開発している
- イメージは node:current-slim という node.js 公式イメージを使用している
- docker-compose.yml は後述
プログラムコードは docker volume を使ってコンテナからローカルディスクをマウントした領域に配置している
このマウントした領域のフォルダをポイントして VSCode からコードを編集している
このマウントした領域は GitHub でホストされているリモートリポジトリになっている

ex. docker-compose.yml

$ pwd
/Users/r/Docker/unrwebpage
$ cat docker-compose.yml
version: '3'

services:
  node:
    image: node:current-slim
    container_name: 'unr_webpage'
    hostname: 'unr_webpage'
    ports:
      - '3001:3001'
    stdin_open: true
    tty: true
    working_dir: '/usr/src/app'
    volumes:
      - ./app:/usr/src/app
    networks:
      - dumynet
networks:
  dumynet:
    external: true

$

開発環境の構築手順

Mac (Intel chip) での開発に必要なツールのインストール
Docker container を用いた React + Redux Toolkit + TypeScript Webフロントエンド開発環境の構築

開発スタイル

現在は以下のスタイルで開発しています

slice をつくる
コンポーネントをつくる
テストする

まず slice をつくる

コンポーネントより先に slice をつくります。

slice とは state と、以下に示す reducer を用途 (ex. ログイン機能) ごとにまとめたものになります。

slice をつくることにより、以下が明確になります。

slice の名称 (ex. auth)
state の構造
- state の名称やデータ形を interface として定義することが多い (ex. ユーザID, ロール, displayName, アバター画像のURL など)
state の初期値
reducer の定義
- reducer とはコンポーネントから受け取るデータと、state を更新する論理を action (ex. login) として定義したもの
- コンポーネントは useDispatchフックを使って action を呼び出す
コンポーネントから参照可能な state の定義
- コンポーネントは useSelectフックを使って state を参照する

現実の開発スタイル

slice からつくって、次にコンポーネントをつくり、結合してテストする、というスタイルは、小人数で開発する際のスタイルだと思っています。現実には slice で定義されるデータ構造と action をドキュメント等に定義し、この定義に従って、

同時に開発する
slice はダミーコンポーネント (弊社で dumymain と呼んでいるもの) と結合してテストする
コンポーネントはモックと結合してテストする
単体でテスト済みの slice とコンポーネントを結合してテストする

という流れになるんだと思っています。

成果物

demoru.net

組織

unremoted.com