UIコンポーネント統合によるフロントエンド保守性の改善

サービスの規模が大きくなるにつれて、ユーザーに表示されるUIコンポーネントの一貫性を維持することは、開発者にとって重要な課題となります。特にブログやSNSのように投稿カードがさまざまなページで繰り返し使用される場合、これを管理するロジックが断片化されると、わずかなデザイン変更にも膨大なコストが発生します。

本記事では、サーバーサイドレンダリング(SSR)とクライアントサイドレンダリング(CSR)に分かれていた投稿レンダリングロジックを一つのJavaScriptクラスに統合し、保守性を最大化した過程を共有したいと思います。

断片化されたロジックの限界

既存のシステムでは、投稿を表示するために2つの方法を併用してきました。

1. サーバーサイドレンダリング: 初期ページロード時にThymeleafフラグメント(postitem.html、postview.html)を使用してHTMLを生成しました。

2. クライアントサイドレンダリング: 「もっと見る」機能や新規投稿作成時に非同期でデータを取得し、JavaScript内部の文字列テンプレートを通じてHTMLを生成しました。

このような併用構造は以下のような明確な問題を引き起こしました。

• 重複コードの発生: HTML構造が変更されるたびに、Thymeleafテンプレートとjavascript内部コードを同時に修正する必要がありました。

• イベントバインディングの複雑性: いいね処理や「もっと見る」ボタンの動作などのインタラクションロジックが複数のファイル(like.jsなど)に散らばっており、フローを把握するのが困難でした。

• UIの不一致: 2つのロジックのいずれかが漏れた場合、ページごとに投稿の見た目や動作が微妙に異なる問題が発生しました。

解決策: Postcardクラスベースのコンポーネント化

投稿のHTML生成、データバインディング、そしてイベントを単一地点で管理するために、Postcardクラスを導入するリファクタリングを断行しました。

1. カプセル化による責任の統合

postcard.jsに定義されたクラスは、投稿データをコンストラクター(Constructor)で受け取り、そのデータに基づいたHTML生成からMarkdownレンダラー(Toast UI Editor)の初期化、そしていいね処理ロジックまですべて自ら管理します。

これにより、既存に別ファイルとして存在したlike.jsのグローバル関数はPostcard.handleLike()メソッドとして内在化され、グローバル汚染を防ぎ、凝集度を高めることができました。

2. テンプレートの一元化

すべてのページでPostcard.createHTML()メソッドを呼び出すように構造を変更しました。これにより、メインフィードでも、投稿詳細ページのコメント領域でも、同じクラスインスタンスを通じて一貫したUIが保証されるようになりました。

リファクタリングの過程と成果

今回のリファクタリングを通じて、プロジェクト全体にわたる大規模なコード整理が行われました。

• レガシーコードの削除: もう使用しないThymeleafフラグメントファイルと重複したいいね処理スクリプトを削除またはDeprecated処理し、プロジェクトの複雑度を下げました。

• 宣言的なレンダリング: index.htmlとviewer.htmlでは、複雑なHTML文字列の代わりにcard.render()という明確なコマンドでUIを構成するようになりました。

• 状態管理の最適化: いいね状態変更時にonLikeChangeコールバックを通じて外部状態と同期できるインターフェースを備え、データフローがより透明になりました。

おわりに

フロントエンドフレームワークを使用しない環境でも、クラスベースのコンポーネント設計はコードの品質を飛躍的に改善できる強力なツールです。今回の統合作業を通じて、「一つの機能を修正するために複数のファイルを探し回る」非効率から脱し、投稿カードという単一コンポーネントのライフサイクルを一箇所で制御できるようになりました。

技術的負債を解決していくプロセスは、結局より速い機能デプロイと安定したサービス運営につながることができます。