Atomic Designをやめてディレクトリ構造を見直した話｜食べログ フロントエンドエンジニアブログ
こんにちは。フロントエンドチームの金野と申します。 食べログでは現在、React+TypeScriptでフロントエンドのリプレースを進めています。 以前の記事で、食べログではAtomic Designをどのように取り入れているかの紹介をしました。 しかし、最近のリプレース作業では、Atomic Designとは異なるディレクトリ構造を採用しています。 今回の記事では、「なぜAtomic Designをやめたのか」という理由と、「どのようなディレクトリ構造にしたのか」を紹介します。 Atomic Designを導入したねらいと導入した結果 上記の記事で言及した通り、当初Atomic Designを導入したねらいは以下になります。 1. コンポーネントの責務がより明確になる 2. 見た目の粒度だけでなく、ロジックの責務も明確にできる 3. 「ドメインが入るか／入らないか」。「抽象的か／そうでな
原子の再定義 - Atomic ReDesign -
Atomic ReDesign とは 「Atomic ReDesign」 は、かの有名な「Atomic Design」の拡張概念です。React や Vue.js を用いたコンポーネント設計において、私たちはしばしば頭を抱えることがありました。UI 粒度の分類制約は、コンポーネント設計最適化を阻むことがあるからです。 「この粒度のコンポーネントはどこに属するものなのか？」という疑問に対し統一された解はなく、プロダクト毎の性質によって定める必要がありました。また、文脈が散在することにより、コードに対する集中力低下を招きました。 Atomic ReDesign は顕在化した 「Atomic Design とアプリケーション設計の乖離」 をとらえ、現実的な設計指針となることを目指します。 Atomic Design とアプリケーション設計の乖離 本家 Atomic Design はデザインシステ
React Component 視点でのアトミックデザインの解釈といくつかの疑問 - mizchi's blog
フロントエンドの中でも、JS書くプログラマと、CSSを書くマークアップと、デザインカンプを作るデザイナで、コンポーネントという概念がズレる。だいたいこれらが一人だったり兼任だったりで1~2レイヤーの開発ステップになるが、完全分業だったり人が多くなると混乱の元になる。 誰かが決定的に間違ってるというつもりはない。正直、どっちかというと本来のデザイナ側の用語定義に倒した方がいい気がしているが、プログラム上の都合もいろいろ混ざってきて、話が簡単ではない。 自分の理解が間違ってる可能性もある。この記事はレビューをもらうために書いている側面もあり、指摘されたら追記していく。 読んだもの。 Atomic DesignとCSS設計 - Atomic Designとは何か | CodeGrid Atomic Designの考え方と利点・欠点 – wkr. Atomic Design の大雑把な理解 基本的
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
