Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
僕のフロントエンド奮闘記コンポーネントで、すったもんだ
Search
nao-bt
February 24, 2018
Programming
1
1.1k
僕のフロントエンド奮闘記コンポーネントで、すったもんだ
We Are JavaScripters! @16th【初心者歓迎LT大会】の資料です。
https://wajs.connpass.com/event/78939/
nao-bt
February 24, 2018
Tweet
Share
More Decks by nao-bt
See All by nao-bt
そろそろWebpackと真剣に向き合ってみる
naotobt
9
5k
Other Decks in Programming
See All in Programming
Rubyでやりたい駆動開発 / Ruby driven development
chobishiba
1
730
AIともっと楽するE2Eテスト
myohei
6
2.6k
Team operations that are not burdened by SRE
kazatohiei
1
310
AI時代の『改訂新版 良いコード/悪いコードで学ぶ設計入門』 / ai-good-code-bad-code
minodriven
14
5.2k
The Modern View Layer Rails Deserves: A Vision For 2025 And Beyond @ RailsConf 2025, Philadelphia, PA
marcoroth
1
190
“いい感じ“な定量評価を求めて - Four Keysとアウトカムの間の探求 -
nealle
1
10k
データの民主化を支える、透明性のあるデータ利活用への挑戦 2025-06-25 Database Engineering Meetup#7
y_ken
0
360
AIと”コードの評価関数”を共有する / Share the "code evaluation function" with AI
euglena1215
1
170
PHPで始める振る舞い駆動開発(Behaviour-Driven Development)
ohmori_yusuke
2
390
たった 1 枚の PHP ファイルで実装する MCP サーバ / MCP Server with Vanilla PHP
okashoi
1
260
PHP 8.4の新機能「プロパティフック」から学ぶオブジェクト指向設計とリスコフの置換原則
kentaroutakeda
2
910
Systèmes distribués, pour le meilleur et pour le pire - BreizhCamp 2025 - Conférence
slecache
0
120
Featured
See All Featured
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
507
140k
A Modern Web Designer's Workflow
chriscoyier
695
190k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
Making the Leap to Tech Lead
cromwellryan
134
9.4k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
Raft: Consensus for Rubyists
vanstee
140
7k
KATA
mclloyd
30
14k
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.9k
Adopting Sorbet at Scale
ufuk
77
9.5k
The Pragmatic Product Professional
lauravandoore
35
6.7k
Transcript
僕のフロントエンド奮闘記 コンポーネントで、すったもんだ Nao-bt
自己紹介 文系出身・プログラミング歴は約5年目。 サーバーもフロントもやる人。 ※できるとは言っていない。日々勉強中。 JSに関しては 前の会社でAngularJsの1.4系を業務で利用。 徐々にJSの面白みを感じ、個人的にフレームワークを中心に 勉強しはじめる。 いまの会社では レガシーでローカル開発環境のない基幹システムを
Vueを利用してリプレースしてます(主にフロント担当)。
今日は、コンポーネントで すったもんだした話。
JSフレームワークを使った開発を これから始める人に参考になれば・・・。
コンポーネント指向って? 画面をUIパーツごとに 分割して作り、組み合わせる。 パーツごとに作るから、 再利用しやすく 分業やテストがしやすい。
コンポーネント間のやりとり props down(親→子), events up(子→親)
親 子 親は子が どんなプロパティを受け取り どんなイベントを返すかを知っている。 子は親を知らなくてもいい。 コンポーネントの階層が深くなれば バケツリレーのようにしていく。
親は子を必ず知っているが、 子は親を知らなくてもいい。 再利用可能なコンポーネントの肝
JSフレームワークを使うと コンポーネント指向に基づく 開発ができる
でも どんなふうに どれくらいの細かさで コンポーネントって区切るんだ??
サーバーサイドのMVCみたいな 目安になるような分け方の 基準はないのかなぁ
そんなときに巡り合ったのが・・・
Atomic Design
コンポーネントの単位を5つの大きさに分けて作る考え方。 Atoms(原子) Molecules(分子) Organisms(有機体) Templates(テンプレート) Pages(ページ)
引用元:http://atomicdesign.bradfrost.com/chapter-2/
なんとなくよさげだ これでいってみよう。
Vuexも使ってみよう
Vuexを使うことで アプリの状態(データや storeとよばれることも)を コンポーネントから分離することができる。 親子関係のないコンポーネント間でも 状態の表示や変更が可能。 わざわざバケツリレーを書かなくてもよくなる。 Vuex公式サイトより、 Vuex を使った最も基本的なカウンターアプリの例
バケツリレーしなくていいなんて 素敵! 実装がはかどる!!
そう、このとき、 私は浮かれていました・・・。
バケツリレーの代わりにコンポーネント内に Vuex用の記載が増えていった。 ※実際のソースは見せれないので Vuex公式のサンプルより
どんなAction、Mutationがあるかを知らないと 成立しないコンポーネントを大量生産
Vuexと蜜結合で再利用できない
Atomic Designの振り返り ・これ再利用するかな?って場合が多々ある。 ・回数制限を設けて、既定の回数同じのを書いたら、 コンポーネント化するとかもありでは? ・初期は大変だろうけど、どんどん開発が進むにつ入れて楽になる。 ・一般ユーザー向けの場合は、見栄えとか重要だから 同じようなコンポーネントがたくさんできそう。
・Pagesコンポーネントの階層に Vuexをまとめて、そこから下の階層に バケツリレーすべきだった。 ・でも急いで実装しないといけない時は Vuexは助かる。(でも麻薬だと思う) Vuexとの組み合わせについての振り返り
よく考えて実装しないと 大変なことになる・・・。 他の人達がどんな コンポーネント管理してるか気になる! 懇親会で 教えてください・・・。