🌊

Reactでの変数名・関数名の付け方についての個人的まとめ

2021/11/24に公開
3

はじめに

Reactに限らずそうですが、コーディングしていると、変数名・関数名で「ん??」ってなることがたまにあります。
新規作成と編集ができるComponentがあったとします。そのprops新規作成か編集かのフラグが、定義する人によってisCreateだったりshouldEditだったりで、同じ意味なのにばらつきが出たりすると、コーディング中に無駄な意識を使わされます。

よく使う変数名・関数名には、名前の付け方を決めて置いたほうがいいと思います。
ブレを少しでも減らすために、悩んできたものを中心に個人的なベストな変数名をまとめました。参考になれば幸いです。
まだ少ないので、随時更新していく予定です。
※ 2021/11/27 13:00時点で、@ryoryo16さんよりコメントいただいた点を修正しております。

変数名・関数名

Componentのprops

名前 意味 備考
checked チェックされているかどうか
closable 閉じれるかどうか can{動詞}よりも、{動詞}able で統一している。
disabled 無効かどうか
description 文章的な説明
editable 編集可能かどうか
fetchList 配列のデータを取得する関数 fetch○○Listという形もあり。
fetchDetail 一つのデータを取得する関数 fetch○○Detailという形もあり。
item その文脈で使いたいモデルのデータ dataだと抽象的すぎるためitemにしている。配列の場合はitemsにする。
label 小さな要素の名前 titleとは、サイズ感が違う
loading ローディング中かどうか 複数ある場合は、isLoadingListやisLoadingDetailなどで、動詞→目的語の順にするのが英語的に自然。
onCancel モーダルなどを、キャンセルで閉じるときに呼ばれる関数
onClick クリックしたときに呼び出される関数
onChange 要素が変更された時に呼び出される関数 onEditよりも広義
onEdit テキストや複数の要素などが変更された時に呼び出される関数
onSubmitCreate 新規作成画面で保存ボタンが押された時に新規作成のリクエストする関数
onSubmitEdit 編集画面で保存ボタンが押された時に編集のリクエストする関数
onSubmittedCreate 新規作成のリクエストのレスポンスを受け取った後に呼び出される関数
onSubmittedEdit 編集のリクエストのレスポンスを受け取った後に呼び出される関数
onOk モーダルなどを、Okで閉じるときに呼ばれる関数
onOpenView 画面が開かれる時に呼ばれる関数
title 大きな要素や複数のまとまりにつく名前 labelとは、サイズ感が違う
visible ボタンなどが見えるかどうか showとhideを使うと、どちらを使うか悩むので、visibleを使っている。

名前 意味 備考
CreateInput Formから入力された新規作成の値の型 Reactのformで入力されたデータを加工して、バックエンドに送ることもあるため、CreateInputとCreateSubmitで型を分けている。モデルごとにnamespaceをきって、User.CreateInputなどでよく使う。
CreateSubmit 新規作成の入力値をリクエストするために加工した型 同上
EditInput Formから入力された編集の値の型 同上
EditSubmit 編集の入力値をリクエストするために加工した型 同上
SearchInput Formから入力された検索の値の型 同上
SearchSubmit 検索の入力値をリクエストするために加工した型 同上

ReduxのAction

名前 意味 備考
openView 画面を開くAction
savePage ページングを状態として保存するAction
submitCreate 新規作成のリクエストするAction
submitEdit 編集のリクエストするAction
submitPage ページングのリクエストをするAction
submittedCreate 新規作成のリクエストのレスポンス完了時のAction
submittedEdit 編集のリクエストのレスポンス完了時のAction

最後に

個人的に、antd が好きなので、そこを主に参考にして名前をつけています。
今後は、この記事を随時更新していくのと、どこまでできるかわからないですが、typescript-eslint/naming-conventionなどで、変数名・関数名の付け方をチェックできたらなと思います。
ありがとうございました。

Discussion

ryoryoryoryo

booleanでもpropsではisを頭につけないことが多いような気がするのですが、isをつけたほうが良いということでしょうか?
自分は変数定義時はisをprefixとしてつけますが、propsの場合はつけていません。
常にtrueの場合は下記のようになるので、isがあると分かりづらくなるような気がします。

// isあり
<MyComp isDisabled />
<MyComp isDisabled={isDisabled} />


// isなし
<MyComp disabled />
<MyComp disabled={isDisabled} />

また、openが「モーダルなどの要素を開く関数」とありますが、他の関数系がon〇〇やfetch〇〇に対してこれだけopenのみなのが気になりました。
(onOpen?ただon〇〇はなにかアクションのハンドラ的なものの気がするので少し違いますかね)
もしダイアログを開く関数であればopenDialogとかにするのが統一感があるように思います。
自分はダイアログを開くため関数を外から渡すということがなかったのでイメージしづらいのですが。。。
なにかのアクションにつられてダイアログが開くのであれば、onClick等の中にダイアログを開く処理を入れます。

個人の好みの問題ですかね笑

z9nekoz9neko

コメントいただきありがとうございます。

booleanでもpropsではisを頭につけないことが多いような気がするのですが、isをつけたほうが良いということでしょうか?

これは個人的な趣味の設定の影響でそうなってしまいました。
一般的な形にして、propsからprefixのisを外して起きます。ご指摘助かります。

ちなみに、個人的な趣味の設定は、以下の2点です。

  1. .esrintrc.js内で、@typescript-eslint/naming-conventionに以下を設定しています。こちらは、let, const, varで宣言した変数がboolean型のとき、prefixにisもしくはshouldがないとErrorになる規則です。
'rules': {
	...
	"@typescript-eslint/naming-convention": [
	    "error",
	    {
	        "selector": "variable",
	        "types": ["boolean"],
	        "format": ["PascalCase"],
	        "prefix": ["is", "should"]
	    }
	]
}
  1. Component内で、propsから変数を取り出して利用したほうが見やすいと思っているので、以下のようにpropsを取り出して利用します。
const {isChecked} = props

そうすると、eslintでErrorが発生してしまうので、propsのbooleanにisつけてもいいかなとなっておりました。
変わった使い方をしていたために発生したので、一般的な方にあわせてしまおうと思います。

また、openが「モーダルなどの要素を開く関数」とありますが、他の関数系がon〇〇やfetch〇〇に対してこれだけopenのみなのが気になりました。

こちらは、おっしゃるとおり、openで渡すことは無いですね。
ReduxのActionを書いているときに、紛れ込んでしまったのかもしません。
投稿前に確認が足りず、申し訳ないです。こちらは消しておきます。

ryoryoryoryo

返信ありがとうございます。

これは個人的な趣味の設定の影響でそうなってしまいました。
一般的な形にして、propsからprefixのisを外して起きます。ご指摘助かります。

isをつけないというのは自分がそちらのほうがよく目にするというもので、一般的かどうかはわからないです!
勘違いさせてしまい申し訳ありません。
なので、is付きのほうが好みということであればそのままで無理に合わせる必要はないかと思います。

そうすると、eslintでErrorが発生してしまうので、propsのbooleanにisつけてもいいかなとなっておりました。

変数としてbooleanを扱う場合はisをつけるのは自分も賛成です。
自分はpropsであればそのまま使ってしまいますが、eslintのルールをそのまま使うであれば

const { checked: isChecked } = props

という書き方もできるかなと。

自分とは違ったので質問させていただいただけで、
個人の好みが出ててもコード内で一貫性があればよいと思います!