投稿管理インタラクション改善とフロントエンドロジックの抽象化

ブログプロジェクトトリードを開発しながら、ユーザー体験(UX)の核心である投稿管理機能を高度化しました。既存のページ単位レンダリング方式から脱却し、非同期通信による動的UI更新と共通ロジックの外部化を通じてコード保守性を確保した過程を共有します。

1. 投稿レンダリングロジックの統合と抽象化

初期実装段階では、メインフィードページと投稿詳細ページでそれぞれ類似したJavaScriptロジックが重複して存在しました。投稿カード(Postcard)を生成してリストに追加する過程が断片化されていて、機能修正時に2箇所のコードを同時に変更する必要がある非効率がありました。

これを解決するためにpostmanager.jsを導入し、グローバル状態と共通関数を中央集中化しました。window.blogStateオブジェクトを通じてログイン状態、ユーザー識別子、いいねリストを管理することで、各ページは自分のデータと設定値のみを宣言すればよいように簡素化しました。

また、投稿リストを読み込む非同期関数であるloadPostsを一般化し、リクエストパスとコンテナID情報のみを渡せば、メインリストとコメント(リツリー)リストの両方で同じロジックを再利用できるよう設計しました。

2. ページ遷移のない動的CRUDインタラクションの実装

ユーザー体験を阻害するページリフレッシュを最小化するため、DOM操作ベースの更新方式を適用しました。

• 動的削除: 投稿削除リクエスト成功時、サーバーからのリダイレクトの代わりに200 OKレスポンスを受信し、JavaScriptで該当カード要素を即座に削除しました。この時、スムーズな遷移のために透明度アニメーションを追加して削除フィードバックを強化しました。

• 即時投稿: クイック作成ウィンドウで登録された新規投稿は、APIレスポンスデータを基に即座にPostcardインスタンスに変換されてリスト最上段に挿入されます。この過程で不要な全体リスト再照会を防ぎ、サーバー負荷を減らして体感速度を向上させました。

3. Hibernate遅延ロード(Lazy Loading)例外の解決

非同期APIリクエストを処理する過程でorg.hibernate.LazyInitializationExceptionが発生しました。投稿生成直後にDTOに変換する時点で、関連するユーザー(BlogUser)と親投稿(Post)情報が初期化されていないプロキシ状態だったためです。

この問題は、永続性コンテキストの範囲を超える時点で遅延ロードされたフィールドにアクセスしようとすると発生します。これを解決するために、エンティティのIDのみを取得するgetReferenceByIdの代わりに、必要な時点で明示的にジョインクエリを実行するか、実際のエンティティをロードするfindById方式を採択してデータ整合性を保証しました。

4. UI/UX細部最適化: フィードと詳細ビューの分離

リスト形式のフィードビューでは、投稿の長さを一定レベルに制限し、フェード効果を適用して可読性を高めました。一方、詳細ページ(Viewer)では投稿のすべての内容が一目で見えるべきなので、同じPostcardクラスを使用しながらもshowFullContentオプションを通じて高さ制限とフェード効果を条件付きで解除しました。

CSS面では、詳細ページ専用コンテナクラスを定義し、!importantキーワードと具体的なセレクタを組み合わせて既存のmax-height制限を確実に無効化しました。これにより、一つのコンポーネントで異なる要件を持つビューを効果的にサポートできました。

5. データマッピング同期イシューの解決

いいね(Like)機能実装時、サーバーのレスポンスオブジェクト構造とクライアントのデータ参照パスが一致せず、UIに値が正しく反映されない問題がありました。サーバーから返される共通レスポンスDTOであるResponseDto内の実際のデータ位置を把握し、JavaScriptロジックを修正しました。単純なクラストグル方式ではなく、サーバーが送信する状態メッセージ(liked/disliked)を基準にUIを同期することで、マルチデバイス環境でも一貫した状態を維持できるように改善しました。

今回の作業を通じて、フロントエンドロジックの結合度を下げ、バックエンドとクライアント間のデータフローを明確に定義できました。今後も技術的負債を先制的に解決しながら、完成度の高いサービスを構築していく予定です。