コンポーネントって、大きくつくって細かく砕きますか？細かくつくって大きく組みますか？

[ahomu]

質問をしたいAMAブース

• [ ] Web Payments / Payment Request API について何でも訊いて下さい by えーじ
• [ ] AbemaTVだけど質問ある？（AbemaTV関係ない質問でもいいです）by Kenichi Kato, Tetsuharu OHZEKI, and Shota Kubota
• [ ] 日経電子版の高速化について何でも聞いてください by sisidovski and cssradar
• [ ] Fastly のエッジクラウドについて何でも聞いてください by Fastly
• [ ] Web パフォーマンスについて何でも訊いて下さい by Ayumu Sato and Shogo Sensui
• [ ] freeeのアクセシビリティ、いまとこれから by 伊原 力也
• [ ] 現場の ES201x とアーキテクチャの変遷と未来 by mizchi
• [ ] デザインとエンジニアリングのワークフローについて語りましょう by Hidemi Atarashi, Kensuke Takada, Masanari Hamada
• [x] コンポーネント座談会 by pirosikick, 伊藤康太, 加藤佑典

質問

表題の通りです。ケースバイケースなようにも思いますが傾向としてどんな感じでしょうか...。使用するライブラリ間の傾向に違いがあったら面白いかも。

[p1xb1t]

回答

穴井さん： Vue.jsの場合、子要素がshallow()でテストできない。そのため、テストベースで考えるなら大きいコンポーネントを作って、必要に応じて共通化できるところを分ける感じが合っているのでは。Reactは細かくても良い気がする。
加藤さん： デザイナーは先にモックを見せなきゃいけないので、実装の段階ですでにデザインカンプという大きいものが出来上がっている状態。それをエンジニアとデザイナーで相談しながら細かく分けていく。
伊藤さん： デザイナーと相談しながら大きいところから崩して共通化していく。細かく共通化しようと思っても、意外と共通化できることは少ない。
加藤さん： 見た目は同じだけどビジネス要件的には、やってる振る舞いは全く違うみたいなことがある。AtomicDesignなどを活用して、共通化できるものは共通化しようとしていたが、ビジネス要件的なものに縛られて共通化できない場合が多く、無理に共通化するよりも、大きいものを崩すほうが結果的にコスト小になる。
伊藤さん： フロントエンドエンジニアとデザイナーで共通化したいものが違うというのも難しいところ。そこを別の仕組みで管理したいという欲求はある。