Skip to main content

 

 

 

 

 

Template:OutSystems/Documentation_KB/Breadcrumb_New_Layout

 

 

Template:OutSystems/OSLanguageSwitcher

 

 

 

OutSystems

フロントエンドアーキテクチャのベストプラクティス

拡張性の高いフロントエンドアーキテクチャを構築するためのルール

  • 作業開始の骨組みとして、スタイルルールなしでHTMLレイアウト構造を定義します。
  • ビジネスロジックを使用せずに構築します。機能ロジックのみを使用します。
  • JavaScript内でアニメーションを使用しないようにします。簡単に上書きできるようにするため、CSS内で作成します。これにより、アニメーション処理はCPU内ではなくGPU内で実行されます。
  • 要素内でアトリビュートスタイルを操作しないようにします。その代わりにクラスを追加し、文書化します。この方法を使用すると、特定のシナリオでユーザーが望まない可能性のあるものを強制せず、すべてのアトリビュートを誤って消去しないようにすることができます。
  • 特定のケースに対応するためにのみ、構造を要素で損なわないようにします。代わりに、疑似要素を使用します。この方法を使用すると、異なるテーマで引き続き同じ構造を適用し、一部のテーマで擬似要素を使用して特定のケースに対応することができます。
  • CSSベースを制御します。
  • パターンを使用します。
  • 拡張性のための独自のルールを定義します。
  • プラットフォームを作成してすべての情報(スタイルガイドやドキュメント)を一元化します。

拡張性の高いパターンを作成するときに尊重すべき3つの禁止事項

以下の3つのルールは同じ基準に従っています。パターンを抽象化し、構造内でのみ考えます。

  1. 要素にインラインスタイルを追加しない。

    • スタイルに固執しないようにします。後で変更が必要になった場合、画面に移動して再度デプロイする必要があります。

    • ルールを上書きする場合、ルールに!importantを追加する必要があります(!importantは、常に無効になっている無効化されたボタンなどの実際のケースを確認するためにのみ使用します)。

  2. 色の名前(.Black)、大きさ(.Width20px)、スタイル(.Bold)、サイズ(.fontSize15)など、目的とする値のクラスを追加しない。

    • 将来、それらのクラスがプロジェクト内で適さなくなった場合、上書きする必要があります。たとえば、クラス.Boldルールでフォントの太さが普通であると記述されている場合、不自然に感じられます。
  3. ビジネスロジックをこれらのパターン内に配置しない。

    • これらはクリーンな状態にし、業務にかかわらずすべてのプロジェクトで使用できるようになっている必要があります。

    • 機能ロジックのAggregateは必要な場合にのみ実行します。