APIもフレームワークも使わない!Appleコレクション紹介サイトの作り方

少し前から、私はApple製品のコレクションを始めました。10代の頃からAppleのハードウェア(そしてその美的センス)には憧れ続けてきましたが、当時はMacを買えるだけの資金がありませんでした。

初めてMacを手に入れたのは19歳のとき。機種は700MHzのiBookで、ブラジルのeBayのようなサイトで購入しました。資金源はあるFlashプロジェクトの報酬でした。

その後カナダに移住して数年が経ち、趣味にお金をかける余裕もできました。デバイスは主にCraigslist(北米の地域掲示板サービス)で個人から買い取っています。

何台かのノートブックとiOSデバイスを集めたところで、「自分のApple製品についての情報をちゃんと記録しておこう」と考えるようになりました。最初はGistにモデル名、シリアル番号、入手経緯、対応OSの最小/最大バージョンなどを書き連ねていたのです。

しかしリストは際限なく膨らみ、次第に見苦しい状態になっていきました。ならばこの情報をWebサイトとして公開すれば完璧では?と思い立ちました。幸い、開発者を雇う必要もありません:D

当初の構想はこうでした。まずデータをSQLデータベースに整理し、情報を複数のカラムやテーブルに分割。次にGraphQL APIを作成してUIに必要なデータを供給し、UIはReactで書いてBabelでトランスパイル、Webpackでバンドルする――そんな具合です。

先ほどの段落を音読してみてください。いかにも技術過多な響きでしょう。しかしこれでも、バックエンドの言語選定や、SASSやstyled-componentsといったUI周りの詳細にはまだ触れていません。「綺麗なデザインでアイテム一覧を表示したい」だけの目的に対して、あまりにも大げさすぎると感じたのです。

そこで私は考えました。以下のものを一切使わずに、このコンテンツを公開できないだろうか、と。

• APIやバックエンドの実装
• JavaScriptのフレームワーク/ライブラリ
• JSツール群(Webpack、Babelなど)
• CSSの記述

さらに、これらの制約に加えて次のようなストレッチゴールも掲げました。

• アクセシビリティに優れたサイトを作る
• 古いブラウザでも動作するサイトを作る(Mac OS 9.2が動くマシンや、iOS 3が動くデバイスを持っているため)

挑戦受諾です。index.html 1枚、素のJavaScriptファイル数個、独自CSSはゼロ。ここでは、そのサイト構築の経験を皆さんに共有したいと思います。

TL;DR:

• 完成したサイト
• ソースコード

それでは、各制約について順番に見ていきましょう。

制約1:APIもバックエンド作業も使わない

少し前に「Stein」というSaaSを見つけました。Googleスプレッドシート上でデータを作成すると、そのデータを返すエンドポイントを発行してくれるサービスです。付属のライブラリはHandlebarsのように動作し、私のユースケースにはまさにうってつけに見えました。

<div data-stein-url="https://api.steinhq.com/v1/storages/5cc158079ec99a2f484dcb40/Sheet1" data-stein-limit="2">
  <div>
    <h1>{{title}}</h1>
    <h6>By {{author}}</h6>
 
    {{content}}
 
    Read on <a href="{{link}}">Medium</a>
  </div>
</div>

制約2:JSフレームワーク・ライブラリ・ビルドツールを使わない

このプロジェクトのユースケースにはフレームワークもライブラリも不要だったため、導入しないことに決めました。ページ上のJSインタラクションはどれも非常に単純です(メニューの表示/非表示、モーダル画面の開閉、パーマリンクの処理程度)。

フレームワークやライブラリを使わないのであれば、WebpackやBabelも不要になります。プリセットやローダーの設定に悩む必要もありません。

補足:「create-react-appやNext.jsを選べば問題は全部解決するのでは?」という反論はあり得ますが、今回はあえて使いません。

制約3:CSSを一切書かない

実は私はCSSを書くのが好きで、特にSASSを使えるときは楽しいのですが、今回はCSSを一切書かないことにしました。理由はいくつかあります。

• デザイン案が特に頭になかった。そこそこ見栄えの良いものは作れるとはいえ、そこに時間と労力を割きたくなかった
• Tailwind CSSを使ってみたかった

Tailwind CSSを初めて耳にする方は、「Bootstrapの代替品でしょ?」と思わないでください。公式サイトにはこんな簡潔な説明があります。

多くのCSSフレームワークはやりすぎている。
……
Tailwindは、独断的な既製コンポーネントを提供する代わりに、HTMLから離れることなく完全にカスタムなデザインを構築できる低レベルのユーティリティクラスを提供する。

まさにその通りです。簡単に検索すれば、Tailwind CSSで「再現」された数々の有名Webアプリが見つかります。

• WhatsApp
• Telegram
• Facebook
• Reddit
• YouTube
• Slack
• Coinbase
• GitHub
• Trello
• Twitter
• Netlify

ストレッチゴール1:アクセシビリティに配慮したサイトにする

先月からDeque Universityでアクセシビリティの講座を受け始めました。内容がとても良く、「HTMLはデフォルトでアクセシブルである」という原則を改めて思い出させてくれました。セマンティックなHTML構造を使い、キーボードナビゲーションやカラーコントラストといった基本項目をテストするだけで、障害のある人をコンテンツから遠ざけてしまう多くの障壁を取り除けます。

私はアクセシビリティの専門家ではありませんが、このサイトのために取り組んだことは以下の通りです。

• スタイルシートの無効化確認:スタイルシートを無効にすることで、コンテンツが論理的・構造的な順序で読めるかを検証できます。
• VoiceOver:macOSとiOSに標準搭載のスクリーンリーダーです。操作はとても簡単なので、実際に試せば利用者の感覚をつかめます。
• モーダル:モーダルは扱いが難しい要素です。今回はIre Aderinokun氏のアプローチに従いました。
• axe:WCAG 2.0およびSection 508のアクセシビリティルールをチェックできる拡張機能です。

決して完璧ではありません。メインコンテンツへのスキップリンク追加など、対応しきれなかった部分もあります。興味のある方は、変更点をまとめたPull Requestをご覧ください。

ストレッチゴール2:古いブラウザでも動作するようにする

残念ながら、この目標は達成できませんでした。スクリプトやスタイルを自由にコントロールできなかったためです。ただし不可能ではないようにも思えます。気づいた点をいくつか挙げます。

• Steinのクライアント「Expedite」はfetchを使用していますが、fetchはSafari 10でようやく搭載された機能です。サーバーへのリクエストはXMLHttpRequestに置き換えられるかもしれません。
• Tailwindは多くの要素でFlexboxを使用していますが、SafariがFlexboxをサポートしたのはiOS 7からです。既存の要素にいくつかプロパティを追記すれば、そこそこの見た目を実現できる可能性があります。
• SSL証明書も古いブラウザでは問題になるかもしれません。

まとめ

このサイトを作るのは本当に楽しかったです。こうした個人的なサイドプロジェクトがあると、仕事では普段触れない技術を試す絶好の口実になります。将来的には、SteinやTailwind CSSが機能のプロトタイピングやハッカソンのプロジェクトで役立つかもしれません。

プロジェクトにあえて「制約」を課したことで、既成概念にとらわれない発想が求められました。すべての目標を達成できたわけではありませんが、個々の技術がどう連携しているのかをより深く理解するきっかけになりました。

同じような挑戦をして、さまざまな技術で遊んでみることを本当におすすめします。Appleコレクションである必要はありません。好きな本の一覧サイトでも、これまで歩いたおすすめのハイキングコースの紹介サイトでもいいでしょう。この場合、大切なのは目的地よりも旅の過程そのものです。

ちなみに、Clockifyで時間を計測してみたところ、コーディング、データ作成、テスト、この記事の執筆を含めて合計13時間かかりました。

本記事は私のブログにも投稿しています。Twitterでのフォローもぜひ。