チームリーディング フロントエンドコンポーネントの指針に行ってきた #narusemi

Vue.js Atomic Design メモ

チームリーディング フロントエンドコンポーネントの指針に参加しました。今回はオンライン開催。簡単に所感をまとめます。

nrs-seminar.connpass.com

所感

前回のクリーンアーキテクチャに続き、今回はフロントエンド寄り、特に新しい技術を導入するときにどのようにチームをリードしたかという話。自分もかつてプロジェクトで Vue.js を採用した経験があるため、とても興味深い内容でした。メンバーに対してきちんと説明できるように自分の中で明確な基準を持つことが大事なのかなと思います。自分はここまでちゃんとできなかったけど...。Vue.js を採用したときのまとめなどはこちら。

Vue.js + Vuex + axios を使うときに考えたことや反省点など - kntmr-blog

メンバーにコンポーネント指向をどう根付かせるか、デザインからどうやってコンポーネントに落とし込むか、そのあたりの話が参考になりました。フォルダ構成は大事。自分は Vuex の examples あたりを参考にしたっけ。

ところで、JS フレームワークと jQuery の相性はよくないという話はよく聞くけど、個人的には適材適所かなと思っています。jQuery を Web フレームワークのように扱うと破綻するけど、DOM アクセスのユーティリティとして使う、豊富なプラグインを生かすことを考えれば、決して駆逐するほどではないかなって。ただ、「仮想 DOM など SPA の利点がなくなる」という点は確かにという感じ。

あと、Vuex のようにデータを1箇所にまとめることで「コンポーネントがデータ越しに依存する」という話は興味深かったです。イベントで繋がることで疎結合になる、と。なるほど。そうすると確かにコンポーネント間で emit する方が分かりやすいしメンテしやすくなる気がする。でも、Flux アーキテクチャってまさにこのあたりを解決するものではなかったっけ？ちがったっけ？もしくは Action の IF 設計とか、Store とコンポーネントに持たせるデータの種類にもよるか。

React は JSX が好きになれるかどうかなのかー。

以下、メモから抜粋。

https://youtu.be/sZA92l4XQsAyoutu.be

  • ゲーム業界に比べて Web 業界のコンポーネント指向は遅れてる
  • Atomic Design
  • JS フレームワークと jQuery の相性はよくない
    • 仮想 DOM など SPA の利点がなくなる
  • フレームワークを使う理由
    • 無意味に重複したコード
    • 意図が見えづらいコード
    • 解読が難しいコード
  • jQuery のコードは前提とする DOM の状態が実装者以外に見えづらい
  • フレームワーク + コンポーネント指向
    • モジュール性を高める
    • 小さく作って理解の範囲を狭める
  • Atomic Design
    • パーツ同士を組み合わせる
    • コンポーネント指向
    • どういう粒度で作ればいいかイメージできる
  • Atomic Design はデザイナー向けのデザイン手法ではない？
  • CSS フレームワークと Atomic Design の粒度は合わないかも？
  • オブジェクト指向は継承やポリモーフィズムなどのための仕組み
  • コンポーネント指向はパーツの取り外しがしやすいように疎結合にするための仕組み
  • ひとつのページを分析してみせる
    • これ以上分解できない要素はどれか (Atoms)
    • Atom を組み合わせる (Molecules)
    • Atom もしくは Molecules を組み合わせたもの (Organisms)
  • ページを担当分けしてみんなでやってもらう
    • 最初にやってみせることで参考になる
    • みんなでやってあとで集約する
    • みんなにやってもらう間にサンプル実装を作る
    • 構成サンプル☆
      • Atomic Design の要素に合わせて構成する
      • Atom の下でさらにフォルダを切ると見通しがよくなる
  • Templates はページレイアウト？
    • Templates や Pages はない場合もある
    • ステークホルダーと話し合うときに使うためでもある
    • コードに落とし込むかどうかはプロジェクト次第
  • Atomic Design とは別に pages フォルダを用意
  • 位置調整などはコンポーネントにしない
  • ボタンコンポーネントを分けたらボタンじゃなくなる
  • Atom を利用したら Molecules
  • Molecules を利用したら Organisms
  • 意味のある塊は Organisms
  • Organisms を利用した Organisms はあり
  • コンポーネント定義
  • データは親コンポーネントが持つ
  • Vuex のようにデータを1箇所に集めるとどこからデータが変更されるか分かりづらい
  • Playground の場を用意して実践してもらう
  • 共通化しすぎて内部で v-if が増える場合は分離するタイミング？
    • 別のものをあとから共通化するより、共通化したものを分ける方が簡単
  • API アクセスはページが担う
    • 共有されるパーツでは Organisms でも許可
  • Molecules が Organisms になることはある
    • Molecules と Organisms の違いは意味を持たせるかどうか
  • BFF のメリットは複数の API アクセスをまとめられること