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
68
失敗から学ぶ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.3k
Other Decks in Technology
See All in Technology
The XZ Backdoor Story
fr0gger
0
3.6k
「自動テストのプラクティスを効果的に学ぶためのカードゲーム」 ( #sqip2024 )
teyamagu
PRO
2
180
Functional TypeScript
naoya
11
4.8k
GC24 Recap: Interface Internals
task4233
0
150
PDF Viewer作成の今までとこれから
hunachi
0
470
忙しい人のためのLangGraph概要まとめ
__ymgc__
1
190
Swift Testingのconfirmationを コードリーディング/Dive into Swift Testing confirmation
laprasdrum
2
260
ロリポップ! for Gamersを支えるインフラ/lolipop for gamers infrastructure
takumakume
0
130
サーバー管理しないサーバーサービスManaged DevOps Pool
kkamegawa
0
130
20240911_New_Relicダッシュボード活用例
speakerdeckfk
0
110
Technical Writing Meetup vol.35
soracom
PRO
2
120
技術的負債解消の取り組みと専門チームのお話
bengo4com
0
330
Featured
See All Featured
Reflections from 52 weeks, 52 projects
jeffersonlam
346
20k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
26
1.9k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
24
610
Atom: Resistance is Futile
akmur
261
25k
What's new in Ruby 2.0
geeforr
340
31k
The Straight Up "How To Draw Better" Workshop
denniskardys
230
130k
The Language of Interfaces
destraynor
153
23k
Let's Do A Bunch of Simple Stuff to Make Websites Faster
chriscoyier
502
140k
How GitHub (no longer) Works
holman
310
140k
4 Signs Your Business is Dying
shpigford
179
21k
Learning to Love Humans: Emotional Interface Design
aarron
270
40k
BBQ
matthewcrist
83
9.2k
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を楽しみましょう!
ご清聴ありがとうございました