🌊

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

ryoryo

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等の中にダイアログを開く処理を入れます。

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

z9neko

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

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

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

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

.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"]
	    }
	]
}

Component内で、propsから変数を取り出して利用したほうが見やすいと思っているので、以下のようにpropsを取り出して利用します。

const {isChecked} = props

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

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

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

ryoryo

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

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

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

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

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

const { checked: isChecked } = props

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

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