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
失敗から学ぶNuxt.jsプロジェクトでの作り込み事例
Search
kumamon_engineer
June 24, 2021
Technology
0
71
失敗から学ぶNuxt.jsプロジェクトでの作り込み事例
6/23 Nuxt道場
kumamon_engineer
June 24, 2021
Tweet
Share
More Decks by kumamon_engineer
See All by kumamon_engineer
Laravel_Slack通知で実践した_リアルタイムエラー共有開発
miyakeylab
2
1.4k
Other Decks in Technology
See All in Technology
FlutterアプリにおけるSLI/SLOを用いたユーザー体験の可視化と計測基盤構築
ostk0069
0
110
アジャイルでの品質の進化 Agile in Motion vol.1/20241118 Hiroyuki Sato
shift_evolve
0
170
DynamoDB でスロットリングが発生したとき_大盛りver/when_throttling_occurs_in_dynamodb_long
emiki
1
440
インフラとバックエンドとフロントエンドをくまなく調べて遅いアプリを早くした件
tubone24
1
430
CysharpのOSS群から見るModern C#の現在地
neuecc
2
3.5k
Application Development WG Intro at AppDeveloperCon
salaboy
0
200
OCI Network Firewall 概要
oracle4engineer
PRO
0
4.2k
OTelCol_TailSampling_and_SpanMetrics
gumamon
1
220
Zennのパフォーマンスモニタリングでやっていること
ryosukeigarashi
0
160
BLADE: An Attempt to Automate Penetration Testing Using Autonomous AI Agents
bbrbbq
0
320
なぜ今 AI Agent なのか _近藤憲児
kenjikondobai
4
1.4k
AWS Lambda のトラブルシュートをしていて思うこと
kazzpapa3
2
180
Featured
See All Featured
Done Done
chrislema
181
16k
Code Review Best Practice
trishagee
64
17k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
47
2.1k
Automating Front-end Workflow
addyosmani
1366
200k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
232
17k
Keith and Marios Guide to Fast Websites
keithpitt
409
22k
How to Think Like a Performance Engineer
csswizardry
20
1.1k
Building Applications with DynamoDB
mza
90
6.1k
The Illustrated Children's Guide to Kubernetes
chrisshort
48
48k
How STYLIGHT went responsive
nonsquared
95
5.2k
Why Our Code Smells
bkeepers
PRO
334
57k
Writing Fast Ruby
sferik
627
61k
Transcript
失敗から学ぶNuxt.js プロジェクトでの作り込み事例 Nuxt道場 2021.06.23 三宅 祐介
自己紹介
自己紹介 株式会社Hajimari / エンジニア 三宅 祐介 ※Twitter上はくまモンエンジニア(@miyakey7)です 新卒でSIer(C/C++,C#,VB...) 2018年にWEBエンジニアとして転職 (PHP(Laravel/CakePHP),Vue.js/Nuxt.js)
会社紹介
None
None
エンジニア募集中です!
History
History 2018年1月からの新規Projectで Nuxt.jsを採用 当時v1.0.0が出たばかりでリスクも あったが開発からリリースまでが長 かった事もあり導入した
History フロントエンド開発の知見を溜めなが ら開発は進み... 複数のNuxt.jsプロジェクトを引き継 いだ際に、あらゆる(小さな)事件が起 きていた
事例
事例 1.とりあえずclient-only 2.全入れVuex 3.画像がupload出来ないaxios 4.マスターデータ管理はどこ?
とりあえずclient-only
画面が真っ白です! 事件発生
The client-side rendered virtual DOM tree is not matching server-rendered
content. This is likely caused by incorrect HTML markup, for example nesting block-level elements inside <p>, or missing <tbody>. Bailing hydration and performing full client-side render. よく見るエラーが...
とりあえず client-onlyで解決
ハイドレーションエラー - クライアント側でレンダリングされた仮想 DOMツリーが、サーバー側でレンダリングさ れたコンテンツと一致しない (データのタイミングなど) - 不正なHTML(tbody抜け)
事象はVueのUIライブラリなどで特 定のコンポーネントを呼んだ際に起 きていました →制御できない事が多くclient-only で囲って解決した 今回の事象
Client-Onlyで挟む事でサーバー 側でレンダリングしなくなります のでこのエラーは無くなりました 解決
Client-Onlyで挟む事でサーバー 側でレンダリングしなくなります のでこのエラーは無くなりました 解決...?
どういう仕組みで client-onlyに なってるんですか?
これを期に理解しよう
Nuxt.jsにおけるClientOnlyの機能 はvue-client-onlyという外部のプラ グインを利用して実装されていまし た ClientOnlyを調査...
Nuxt.jsのコード的には...
features...?
nuxt.configファイルに features listを追加 し、fales設定にすると 不要な機能を抜いてビル ドする事が出来る featuresとは...?
そういえば<no-ssr>はどうなったのか 非推奨になっており、まもなく消える...
vue-client-only 本体 めっちゃシンプル
全入れvuex
全部vuexに入ってます 事件発生
Vuexが無法地帯
ヘッダー サイド メニュー ユーザーリストコ ンポーネント ユーザーメッセージコンポーネント 送信 とあるメッセージ画面
ヘッダー サイド メニュー ユーザーリストコ ンポーネント ユーザーメッセージコンポーネント 送信 全てのメッセージをvuexへ保存 名前 メッセージ
ID メッセージ Aさん 1 こんにちは 2 あああ 3 本当ですか Bさん 1 むむむ 2 本当ですか
ヘッダー サイド メニュー ユーザーリストコ ンポーネント ユーザーメッセージコンポーネント 送信 コンポーネント間で参照 名前 メッセージ
ID メッセージ Aさん 1 こんにちは 2 あああ 3 本当ですか Bさん 1 むむむ 2 本当ですか
ヘッダー サイド メニュー ユーザーリストコ ンポーネント ユーザーメッセージコンポーネント 送信 限界が来た... 名前 メッセージ
ID メッセージ Aさん 1 こんにちは 2 あああ 3 本当ですか Bさん 1 むむむ 2 本当ですか 容量 パンク!
Vuexとは...
Vuex Vuexアプリケーションの中心にあるも のはストアです "ストア" は、基本的にアプリケーショ ンの状態(state)を保持するコンテナ です
コンポーネント間で情報共有し やすいためコンポーネント間の 依存が減る
Vuex自体はリロードなどでクリアされてし まうためvuex-persistedstateなどを使って データを永続化することが多いと思います その場合、Vuexが持ちうる容量は - local storage...5M程度 - window session
storage...5M程度 - cookie...4K byte程度
ヘッダー サイド メニュー ユーザーリストコ ンポーネント ユーザーメッセージコンポーネント 送信 変えるべきは... 名前 メッセージ
ID メッセージ Aさん 1 こんにちは 2 あああ 3 本当ですか Bさん 1 むむむ 2 本当ですか ユーザーリストだけにする or ユーザーリストの今の取得 状態を持つ このコンポーネント で過去メッセージを 都度取得 このコンポーネント でメッセージを持た ない or 状態を見てAPIコール
画像がupload出来ない axios
画像がアップロード 出来ません 事件発生
axiosラッパーに何かあるぞ
axiosを使う際は全てservices/http.jsにあり 今回もそれを使ってアップロード....
実際のpostメソッド内でconfigなどが変わっ ており、画像アップロードを想定されていな かった
本来はリクエスト数削減 のためにAPIをまとめて 投げるために作られてい た機能で、汎用的に使う ものではなかった
http.jsだと汎用性あ りそうに感じてしま う
マスターデータ管理は どこ?
マスターデータの 管理どこだ? 事件発生
DB ID name 1 申し込み済 2 参加確定 3 選考漏れ 4
キャンセル マスターテーブル マスター取得API
DB フロントで定義
DB ビルド時にマスター取得API jsonファイル化
1. サーバーから最初に一度取得し保持しておく(Vuex) 2. 都度必要な際にサーバーへ取りに行く 3. ID,nameの組み合わせでフロントに定義 4. ビルド時にサーバーからAPIで取得しjsonファイル化 DBにあるmasterデータとクライアントで使いたい定義
どれが正解...?
▪基本 →サーバーから最初に一度取得し保持しておく(Vuex) ▪巨大なマスターデータがある時は →ビルド時にサーバーからAPIで取得しjsonファイル化 ▪フロントでカスタマイズなど →ID,nameの組み合わせでフロントに定義してもよい 指針を立てて運用
他にも...
• 画像URL変換共通処理の落とし穴 • PC/SP分離コンポーネント管理失敗 • 入れかけのatomic design • 置き去りにされた storybook
...etc
まとめ
client-only →Nuxtのコードを読むきっかけが生まれ SSR/client-onlyへの理解が深まった Vuex →API設計、component設計見直しのきっかけ axios →header理解/機能のわかりやすさ/命名 マスターデータ →SPA設計におけるデータ設計考慮
何か起こった時が深堀りのチャンス として学んでいく 事件を楽しもう でも何か起きないに越したことはない
Nuxt3の導入で事件が起きないように...🙏 Nuxt開発LIFEを楽しみましょう!
ご清聴ありがとうございました