処理の共通化と

コンポーネントの分割/分類/粒度

Vue.js v-tokyo Meetup #10

2019/07/25

@nakajmg

じまぐ

@nakajmg

Frontend Engineer at PixelGrid Inc. + 副業

（元DMM.comラボ 7年前？

https://ponyhead.booth.pm/items/1028529

技術書典5でコンポーネント設計の本を出しました

「コンポーネント設計についてのお気持ち関係を聞きたいです」

話すこと

1. コンポーネント設計について

お気持ち語ります

1. 処理の共通化について
2. コンポーネントの分割/分類/粒度について

1. コンポーネントのmixin
2. storeのgetters

• 簡単に使えるが、コードの見通しが悪くなる
• 超便利mixinみたいな大きなものができがち
• 依存しているmixin自体はわかるが、どのプロパティに依存しているか把握が難しく、mixin側の変更の影響範囲が読みづらい

$routerなど、thisに生えるのが仕方ないものを共通化する目的で使うのだけは許容できるかな？というところ

mixinだけに限らず、thisに何かを生やすのは基本的によろしくない。

便利(簡単)な一方で、コードの見通しと変更しやすさを犠牲にしている。

• 特定のコンポーネントと1対1になるようなgetters
• gettersに処理があるせいでstoreを介さないと使えないコンポーネントが存在する
• ページAでは使うけどページBでは使わないgettersがある

• storeはapiの値をそのままstateで保持
• 値を整形する場合はページコンポーネントで

mixinでthisに生やす意味も、getters自体に整形処理を持たせる必要もない。関数で使い回せるようにしておけばもっと都合がよくなる

helperとかtransformerとか、用途ごとに名前をつけてディレクトリを切っておくと取り回しやすい

目先の楽さに流されない強い心と、先を見通す視点を持ちましょう。

• 迷わず分類できること
• 複数人の間で共通認識として機能すること
• 開発体験を損なわないこと

自分自信がなんの迷いもなく「これはこれ」と分類できる方法であること。

自分でできないなら他の人もできない

A「このコンポーネントはstoreを参照してないので

〇〇に分類しました。」

B「ビジネスロジックを含んでるからXXじゃない？

感覚的にもXXだと思う。あとそのコンポーネントもっと分割できそうじゃない？」

A「このコンポーネントの役割を考えると

　　　　　分類は〇〇でいいよね。」

B「そうだね。その役割なら〇〇だね。」

• 正しく分類されてるけど細かく分割されすぎてて使いづらい
• 特定のコンポーネントでしか絶対使わないのに分類上の都合で別のディレクトリにあってしんどい
• など…

分類するときだけでなく

コンポーネントを使用/変更するときの

ことが考慮されているかどうか

具体的な分類方法は？

Atomic Design？

Q. Atomic Designをもとにコンポーネントを分類したことがある人？

Q. 結構うまくいった経験がある方？

Atomic Designがもたらした分類には価値がある一方、フロントエンドに与えた混乱も大きい

Atom/Molecule/Organismのような単位で分割する手法が当たり前に行われるようになったのは素晴らしい

原子が分子を構成して〜的な、

だれでも理解できそうだけど

人の数だけ捉え方が異なるやつ

ボタン1つの分類で迷ったことありませんか？

捉え方が異なるのにあたかも

「共通認識が取れてます」という雰囲気で採用するとうまくいかない

Atomic Designの指標を再定義、もしくは追加しなければ共通認識として機能させることは難しい（多くの人達にとっては

あらゆるプロジェクトや

チームにフィットするような

万能な分類はない

• 迷わず分類できること
• 複数人の間で共通認識として機能すること
• 開発体験を損なわないこと

これらは人やチームによって異なるもの

おしまい