2019/6/1 初夏のJavaScript祭りで使用したスライドです。 Atomic Designの考え方をNuxt.jsのコンポーネント分割に取り入れてサービス開発してみました。フロントエンドエンジニア、デザイナー両面からの視点でやってみて良かったことやハマりどころをご紹介します。
![Nuxt.js × Atomic Designのサービスデザインフロー](https://cdn-ak-scissors.b.st-hatena.com/image/square/47ea953354ca807d331a402973066353c2b2e730/height=288;version=1;width=512/https%3A%2F%2Ffiles.speakerdeck.com%2Fpresentations%2F3f7f3cb1c414410d8e44c1469c03404c%2Fslide_0.jpg%3F12714104)
2019/6/1 初夏のJavaScript祭りで使用したスライドです。 Atomic Designの考え方をNuxt.jsのコンポーネント分割に取り入れてサービス開発してみました。フロントエンドエンジニア、デザイナー両面からの視点でやってみて良かったことやハマりどころをご紹介します。
背景筆者が個人的に仕事を受けはじめた会社のフロントエンドのプロジェクトを立ち上げることになりました。 そこでせっかく新しく作る機会があるならコンポーネントの分割の仕方(コンポーネント設計)を明確に定義したいと思いました。 そもそもなんで分け方を定義したいとなったかというと、後からメンバーがプロジェクトに入ってきたときに、スムーズにプロジェクトに入ってもらうためです。 今まで作ってきたプロジェクトでのコンポーネントの分け方は、「2,3回使う場合はコンポーネントに分ける」 「長くなって見通しが悪いコンポーネントは分ける」など曖昧なところもありますがシンプルなものでした。 ただこの分け方をするとコンポーネント自体が大きくなりがちでした。 今のところプロジェクトに関わる人数も少なく、個々のメンバーのレベルも高いため運用できていますが、人が増えた場合や他のメンバーとなった場合は「苦しいのではないか?
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く