フロントエンドFAQ

フロントエンドFAQのルール

  1. Frontend FAQについて話します。コンテンツが古くなったときに多くの人の目に留まるように、該当するときはいつでもリンクを共有してください。
  2. 短くシンプルにしてください。2文以上の回答が必要な場合は、ここにふさわしくありません。
  3. 可能であれば、背景を説明してください。関連するソースコード、イシュー/エピック、その他のドキュメントへのリンクは、答えを理解するのに役立ちます。
  4. 何か見つけたら、何かしましょう。古くなったコンテンツを見つけたら、すぐに削除または更新しましょう。

FAQ

1.ページのRailsルートはどうやって見つけるのですか?

page’データ属性を確認します。

最も簡単な方法は、問題のページでブラウザに次のように入力することです:

document.body.dataset.page

属性を設定するソースコードはこちら。

Railsルート

rails routes コマンドを使うと、アプリケーションで利用可能なすべてのルートを一覧できます。出力をgrep にパイプすることで、利用可能なルート一覧を検索できます。出力には利用可能なリクエストタイプ、ルートパラメータ、関連するコントローラが含まれます。

bundle exec rails routes | grep "issues"

2. modal_copy_buttonclipboard_button

clipboard_button は、ページロード時に初期化されるcopy_to_clipboard.js ビヘイビアを使用します。ページロード時に存在しないVueのクリップボードボタン(GlModal のものなど)は、クリップボードパッケージに関連付けられたクリックハンドラを持ちません。

modal_copy_button は、そのコンポーネントのインスタンスに固有のclipboard プラグイン のインスタンスを管理します。これは、クリップボードイベントがマウント時にバインドされ、ボタンが押されたときに破棄されることを意味し、上記のイシューを軽減します。また、GlModal によって作成されたフォーカストラップと連携するために、特定のコンテナまたはモーダル ID へのバインディングも利用できます。

3.Pajamas Design Systemに準拠していないgitlab-ui コンポーネント

gitlab-ui に実装されているPajamas Design System のコンポーネントの中には、Design System の仕様に準拠していないものがあります。これは、予定されている機能が不足していたり、スタイルが正しく設定されていないためです。Pajamasのウェブサイトでは、コンポーネント例の上にバナーが表示されています:

このコンポーネントは、デザインシステムで定義された正しいスタイルにまだ準拠していません。このコンポーネントのビジュアルを参照する場合は、デザインシステムのドキュメントを参照してください。

例えば、執筆時点では、チェックボックスのようなすべてのフォームコンポーネントにこの種の警告が表示されます。ただし、この警告はそのコンポーネントを使用すべきでないことを意味するものではありません。

GitLabは適切なコンポーネントが存在する場合、常に<gl-*> 。そうすることで、コードベースが統一され、将来のメンテナーやリファクタリングがより快適になります。

MRレビューの一環として、プロダクトデザイナーが不適合コンポーネントの使用をレビューするようにしてください。フォローアップイシューを作成し、パジャマデザインシステムのコンポーネントエピックにあるコンポーネント実装エピックに添付してください。

4.送信後、送信フォームのボタンが無効になります。

フォーム内部の送信ボタンはフォーム要素にonSubmit イベントリスナーをアタッチします。このコードでは、フォームが送信されると送信ボタンにdisabled クラスセレクタが追加されます。この動作を回避するには、ボタンにjs-no-auto-disable クラスを追加します。

5.バックエンドのエンドポイントを参照するときに、完全な URL (たとえばgon.gitlab_url) と完全なパス (たとえばgon.relative_url_root) のどちらを使うべきでしょうか?

フルURL よりもフルパスを使うほうが望ましいです。なぜなら、URL は GitLab で設定されたホスト名を使うため、リクエストと一致しない可能性があるからです。これは、この Web IDE の例のようなクロスオリジンリソース共有の問題を引き起こします。

使用例:

// bad :(
// If gitlab is configured with hostname `0.0.0.0`
// This will cause CORS issues if I request from `localhost`
axios.get(joinPaths(gon.gitlab_url, '-', 'foo'))

// good :)
axios.get(joinPaths(gon.relative_url_root, '-', 'foo'))

また、フロントエンドではパスをハードコードせず、バックエンドからパスを受け取るようにしてください (次のセクションを参照)。バックエンドの Rails のパスを参照する際には、*_url の使用を避け、代わりに*_path を使用してください。

使用例:

-# Bad :(
#js-foo{ data: { foo_url: some_rails_foo_url } }

-# Good :)
#js-foo{ data: { foo_path: some_rails_foo_path } }

6.フロントエンドはバックエンドのパスをどのように参照すべきでしょうか?

パスのハードコーディングによる余分な結合は避けたいものです。可能であれば、JavaScript で参照する DOM 要素のデータ属性としてパスを追加してください。

使用例:

// Bad :(
// Here's a Vuex action that hardcodes a path :(
export const fetchFoos = ({ state }) => {
  return axios.get(joinPaths(gon.relative_url_root, '-', 'foo'));
};

// Good :)
function initFoo() {
  const el = document.getElementById('js-foo');

  // Path comes from our root element's data which is used to initialize the store :)
  const store = createStore({
    fooPath: el.dataset.fooPath
  });

  Vue.extend({
    store,
    el,
    render(h) {
      return h(Component);
    },
  });
}

// Vuex action can now reference the path from its state :)
export const fetchFoos = ({ state }) => {
  return axios.get(state.settings.fooPath);
};

7.本番ビルドをローカルでテストするには?

フロントエンドの本番ビルドが生成するものをローカルでテストする必要があることがあります:

  1. webpackを停止します:gdk stop webpack.
  2. gitlab/config フォルダにあるgitlab.yaml を開き、webpack セクションまでスクロールダウンし、dev_serverenabled: falseに変更します。
  3. yarn webpack-prod && gdk restart rails-web を実行してください。

本番ビルドの完了には数分かかります。この時点で変更されたコードは、上記の項目3を再度実行した後にのみ表示されます。

標準の開発者モードに戻るには:

  1. gitlab のインストールフォルダにあるgitlab.yaml を開き、webpack のセクションまでスクロールダウンして、dev_serverenabled: trueに戻してください。
  2. yarn clean を実行し、本番用アセットを削除して空き領域を確保します(オプション)。
  3. 再度webpackを起動します:gdk start webpack.
  4. GDK を再起動:gdk restart rails-web.

8.バベルポリフィル

GitLab 12.8で導入されました

GitLabはBabelpreset-env オプションuseBuiltIns: 'usage'を有効にしました。これは、core-js ターゲットブラウザがサポートしていないJavaScript機能ごとに、 core-js適切なcore-js ポリフィルを一度だけ core-js追加するものです。手動でポリフィルをcore-js 追加 core-jsする必要はありません。

GitLabはブラウザの機能を拡張するために、core-js 以外のポリフィルを追加しています(GitLab SVGポリフィルなど)。<use xlink:href> を使うことで、SVGを参照できるようになります。これらのポリフィルは必ずapp/assets/javascripts/commons/polyfills.js に追加してください。

どのポリフィルが使われているかを見るには

  1. マージリクエストに移動してください。
  2. マージリクエストのタイトルの下にあるセカンダリメニューで、パイプラインを選択し、表示したいパイプラインを選択すると、そのパイプライン内のジョブが表示されます。
  3. compile-production-assets ジョブを選択します。
  4. 右側のサイドバーで、ジョブアーティファクトまでスクロールし、ブラウズを選択します。
  5. webpack-reportフォルダを選択して開き、index.htmlを選択します。
  6. ページの左上で右矢印({chevron-lg-right})を選択し、エクスプローラを表示します。
  7. モジュールの検索フィールドにgitlab/node_modules/core-js と入力すると、どのポリフィルがどこに読み込まれているかを確認できます:

    Image of webpack report

9.ダークモードでページが壊れるのはなぜですか?

ークモードのドキュメントをご覧ください