タグ: フロントエンド
マイクロフロントエンド
優れたフロントエンド開発は困難です。大規模で複雑な製品に対して、多くのチームが同時に作業できるようにフロントエンド開発をスケーリングすることはさらに困難です。この記事では、フロントエンドのモノリスを、より小さく管理しやすい多くの部分に分割するという最近のトレンドと、このアーキテクチャがフロントエンドコードに取り組むチームの有効性と効率性をどのように向上させることができるかについて説明します。さまざまな利点とコストについて説明するだけでなく、利用可能な実装オプションについても説明し、この手法を示す完全なアプリケーション例を深く掘り下げます。
GUIアーキテクチャ
GUIアーキテクチャがどのように進化してきたかについての歴史的な概要。特に、Model-View-Controllerが長年にわたってさまざまなグループによってどのように見られてきたかに注目しています。歴史的な観点から、私のプレゼンテーションパターンと結びついています。
確立されたUIパターンを使用したReactアプリケーションのモジュール化
確立されたUIパターンは、UIデザインにおける複雑な問題を解決する上で効果的であることが証明されているにもかかわらず、フロントエンド開発の世界ではあまり活用されていません。この記事では、確立されたUI構築パターンをReactの世界に適用し、リファクタリングの過程のコード例を用いて利点を示します。レイヤアーキテクチャが、応答性と将来の変更を改善するためにReactアプリケーションをどのように整理するのに役立つかを重点的に説明します。
ヘッドレスコンポーネント: React UIを構成するためのパターン
React UIコントロールがより洗練されるにつれて、複雑なロジックが視覚的表現と絡み合ってしまう可能性があります。これは、コンポーネントの動作を理解しにくく、テストしにくく、異なる外観が必要な同様のコンポーネントを構築する必要があることを意味します。ヘッドレスコンポーネントは、すべての非ビジュアルロジックと状態管理を抽出し、コンポーネントの頭脳と外観を分離します。
プレゼンテーションロジックの整理
ユーザーインターフェースのパターンの概要を説明します。ドメインロジックをプレゼンテーションから分離する方法と理由、およびデータのレイヤーがどのように分離され、同期されるかについて説明します。
ツースタックCMS
私たちは、多くの場合、一般的なコンテンツ管理システム(CMS)を使用して、豊富なコンテンツを含む多くのWebサイトを構築しています。最近のプロジェクトでは、グローバルメーカーのマーケティングWebサイトがあり、高可用性とトラフィックニーズを備えた複雑なインタラクティブコンテンツが求められました。私たちの対応は、編集と公開の分離パターンを適用し、コンテンツの作成と配信のために2つの異なるソフトウェアスタックを構築することでした。このデッキでは、このアーキテクチャの概要と、スタック間の統合、ライブサイトの安全なプレビューの提供、システムの進化とスケーリングの処理に対する私たちの対応について説明します。
デモフロントエンド
開発者がAPIからのJSON出力を画面に次々と表示し、ユーザーが混乱して気を取られ、理解できない「デモ」に参加したことがありますか?開発中にAPIを使用しようとして、機能をテストするために正しいJSONペイロードとヘッダーの記述を見つけるのが難しいことにイライラしたことがありますか?デモフロントエンドは、このようなAPIのデモンストレーションと探索のための基本的な機能を提供するシンプルなUIです。
キーストーンインターフェース
ソフトウェア開発チームは、可能な限り頻繁に作業を統合すると、作業がはるかに楽になることに気づいています。また、本番環境に頻繁にリリースすることも重要です。しかし、チームは開発途中の機能をユーザーに公開したくありません。この緊張に対処するための有用なテクニックは、すべてのバックエンドコードを構築して統合しますが、ユーザーインターフェースは構築しないことです。この機能は統合してテストできますが、UIは、キーストーンのように機能を完成させるために追加され、ユーザーに公開されるまで、最後まで保留されます。
プレゼンテーションドメインの分離
私が発見し、従ってきた最も有用な設計原則の1つは、プログラムのプレゼンテーションの側面(ユーザーインターフェース)と残りの機能を適切に分離することです。私がこれを実践してきた長年の経験から、多くの利点を見てきました。
トランスメディアアプリケーション
モバイルアプリケーションは、過去数年間、ソフトウェア開発のホットなアイテムでした。多くのソフトウェア配信会社と同様に、Thoughtworksはクライアントからモバイルアプリケーションの構築を依頼されることがよくあります。しかし、ほとんどの場合、企業が私たち(または誰か)にモバイルアプリケーションの構築を依頼するとき、彼らは間違ったスタートを切っています。ほとんどの場合、ユーザーにモバイルデバイスと対話してもらいたい場合でも、**モバイルアプリケーションの構築を決して考えてはならない**と主張します。代わりに、モバイル、デスクトップ、タブレットなど、ユーザーが使用する可能性のあるあらゆるデバイスに表示される単一のアプリケーションを構築することを考える必要があります。