Tag: アトミックデザイン

  • アトミックデザインをやめて、ディレクト構造を見直す

    atma株式会社では、週2回、フロントエンド・バックエンドに分けて勉強会をしています。 今回は、フロントエンド勉強会で発表した、「アトミックデザインからの脱却」をこちらでも公開します。 そもそもアトミックデザインって何 アトミックデザインとは、Brad Frostさんが提唱した、フロントエンドのコンポーネント設計についてのデザインシステムです。 Brad Frostさんがアトミックデザインについて提唱している記事 大抵のアトミックデザインの解説では以下の画像が使われています。Brad Frostさんの記事で紹介のため使われている画像なので、多くの方に使われているようですね。 出典: https://bradfrost.com/blog/post/atomic-web-design/ アトミックデザインについて要約すると、 デザインシステムを考えに考え、考えぬいたら、化学に行き着いた。UIも地球上に存在するすべての物質のように、原子、分子、有機体、、のようにできてるのでは?? というような感じです。 実際の現場では、コンポーネントを5つのディレクトリに分けることで、採用されていることが多いと思います。 Brad Frostさんも言っている通り、templates, pagesは、化学的ではないですが便宜上便利なので入れているらしいです。 なんでアトミックデザイン使うの? これは、調べても僕の力では見つけられなかったです。 https://design.dena.com/design/atomic-design-を分かったつもりになる 有名な記事はいくつかあるのですが、これといった決定打はないようです。 「アトミックデザイン最近(2018~)はやってる」「アトミックデザイン便利そう」 みたいな感じかなと思っています。 アトミックデザイン本当に便利?? ここからが、今日話したいことになります。 結論を述べると僕は、アトミックデザインが非常に分かりづらいものだと思っています。 前職で大きなプロジェクトで1回、社内では2回利用しています。 何が分かりづらい?? 1. そもそもatomicとかmoleculesとかパッと見よくわからない シンプルに馴染みのない単語ですし、何を指しているのか分かりづらいです。moleculesとorganismsとかほぼ違いが分からないです。 また、moleculesとorganismsの範囲が案件によってかなり違います。 デザインにおける共通言語としては、atomicsしか定着してないと勝手に思ってます。 2. そもそも、何でもかんでも共通化できるものではない アトミックデザインを採用すると、原則として、必ず、atomic・molecules・organismsのいずれかのディレクトリにコンポーネントを作らいないと行けないです。 例えば、お問い合わせフォームのコンポーネントを考えると、フィールドはatomicとわかります。 では、フィールドの結合は?submit処理はどこに?エラー処理はどこに? 採用するフレームワークによっては、完全に分離ができないこともあります。 実装によっては、ほとんどがpagesに入ってしまい、pagesが肥大化してしまう可能性もあります。 3. pagesの肥大化を恐れて、コンテキスト込のorganismsが増える 上記とも被りますが、特定のページでしか使わないけど、共通化も面倒なとき、一旦organismsに orgnisms/contact/contactForm.tsx (.vue) のようになったりしがちです。 まとめると アトミックデザインという、デザインシステムを維持するのは、かなり難しいのと、そのコストが高いと思っています。 もちろん、しっかりと定義がされたアトミックデザインは、強いと思いますし素晴らしいと思うのですが、僕の感覚では、上記3点の理由であまりそうならないと思っています。 じゃあ、どんな構造でコンポーネントを設計していけばいいの? いくつかのタイミングで、紹介していますが、僕は以下の記事の考え方がアトミックデザインからの脱却のための近道だと思っています。 Atomic Designをやめてディレクトリ構造を見直した話|食べログ フロントエンドエンジニアブログ 食べログの解決策は?…