- フロントエンドFAQのルール
-
FAQ
- 1.ページのRailsルートはどうやって見つけるのですか?
- 2.
modal_copy_button
対clipboard_button
- 3.Pajamas Design Systemに準拠していない
gitlab-ui
コンポーネント - 4.送信後、送信フォームのボタンが無効になります。
- 5.バックエンドのエンドポイントを参照するときに、完全な URL (たとえば
gon.gitlab_url
) と完全なパス (たとえばgon.relative_url_root
) のどちらを使うべきでしょうか? - 6.フロントエンドはバックエンドのパスをどのように参照すべきでしょうか?
- 7.本番ビルドをローカルでテストするには?
- 8.バベルポリフィル
- 9.ダークモードでページが壊れるのはなぜですか?
フロントエンドFAQ
フロントエンドFAQのルール
- Frontend FAQについて話します。コンテンツが古くなったときに多くの人の目に留まるように、該当するときはいつでもリンクを共有してください。
- 短くシンプルにしてください。2文以上の回答が必要な場合は、ここにふさわしくありません。
- 可能であれば、背景を説明してください。関連するソースコード、イシュー/エピック、その他のドキュメントへのリンクは、答えを理解するのに役立ちます。
- 何か見つけたら、何かしましょう。古くなったコンテンツを見つけたら、すぐに削除または更新しましょう。
FAQ
1.ページのRailsルートはどうやって見つけるのですか?
page’データ属性を確認します。
最も簡単な方法は、問題のページでブラウザに次のように入力することです:
document.body.dataset.page
属性を設定するソースコードはこちら。
Railsルート
rails routes
コマンドを使うと、アプリケーションで利用可能なすべてのルートを一覧できます。出力をgrep
にパイプすることで、利用可能なルート一覧を検索できます。出力には利用可能なリクエストタイプ、ルートパラメータ、関連するコントローラが含まれます。
bundle exec rails routes | grep "issues"
2. modal_copy_button
対clipboard_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.本番ビルドをローカルでテストするには?
フロントエンドの本番ビルドが生成するものをローカルでテストする必要があることがあります:
- webpackを停止します:
gdk stop webpack
. -
gitlab/config
フォルダにあるgitlab.yaml
を開き、webpack
セクションまでスクロールダウンし、dev_server
をenabled: false
に変更します。 -
yarn webpack-prod && gdk restart rails-web
を実行してください。
本番ビルドの完了には数分かかります。この時点で変更されたコードは、上記の項目3を再度実行した後にのみ表示されます。
標準の開発者モードに戻るには:
-
gitlab
のインストールフォルダにあるgitlab.yaml
を開き、webpack
のセクションまでスクロールダウンして、dev_server
をenabled: true
に戻してください。 -
yarn clean
を実行し、本番用アセットを削除して空き領域を確保します(オプション)。 - 再度webpackを起動します:
gdk start webpack
. - 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
に追加してください。
どのポリフィルが使われているかを見るには
- マージリクエストに移動してください。
- マージリクエストのタイトルの下にあるセカンダリメニューで、パイプラインを選択し、表示したいパイプラインを選択すると、そのパイプライン内のジョブが表示されます。
-
compile-production-assets
ジョブを選択します。 - 右側のサイドバーで、ジョブアーティファクトまでスクロールし、ブラウズを選択します。
- webpack-reportフォルダを選択して開き、index.htmlを選択します。
- ページの左上で右矢印({chevron-lg-right})を選択し、エクスプローラを表示します。
-
モジュールの検索フィールドに
gitlab/node_modules/core-js
と入力すると、どのポリフィルがどこに読み込まれているかを確認できます:
9.ダークモードでページが壊れるのはなぜですか?
ダークモードのドキュメントをご覧ください