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本格導入で遠回りしないためのTips
Search
Shinji Yamada
October 04, 2017
Programming
7
2.8k
Nuxt.js本格導入で遠回りしないためのTips
Nuxt.jsを本格的に使ってみようと考えている人のための資料です
Shinji Yamada
October 04, 2017
Tweet
Share
Other Decks in Programming
See All in Programming
条件判定に名前、つけてますか? #phperkaigi #c
77web
2
430
AIに任せる範囲を安全に広げるためにやっていること
fukucheee
0
150
エンジニアの「手元の自動化」を加速するn8n 2026.02.27
symy2co
0
170
[PHPerKaigi 2026]PHPerKaigi2025の企画CodeGolfが最高すぎて社内で内製して半年運営して得た内製と運営の知見
ikezoemakoto
0
190
生成 AI 時代のスナップショットテストってやつを見せてあげますよ(α版)
ojun9
0
270
エラーログのマスキングの仕組みづくりに役立ったASTの話
kumoichi
0
260
野球解説AI Agentを開発してみた - 2026/02/27 LayerX社内LT会資料
shinyorke
PRO
0
350
go directiveを最新にしすぎないで欲しい話──あるいは、Go 1.26からgo mod initで作られるgo directiveの値が変わる話 / Go 1.26 リリースパーティ
arthur1
2
570
AIコードレビューの導入・運用と AI駆動開発における「AI4QA」の取り組みについて
hagevvashi
0
510
Go 1.26でのsliceのメモリアロケーション最適化 / Go 1.26 リリースパーティ #go126party
mazrean
1
420
Redox OS でのネームスペース管理と chroot の実現
isanethen
0
280
Linux Kernelの1文字のミスで 権限昇格ができた話
rqda
0
1.9k
Featured
See All Featured
GraphQLとの向き合い方2022年版
quramy
50
14k
Redefining SEO in the New Era of Traffic Generation
szymonslowik
1
250
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
54k
Organizational Design Perspectives: An Ontology of Organizational Design Elements
kimpetersen
PRO
1
640
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.6k
Why You Should Never Use an ORM
jnunemaker
PRO
61
9.8k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
231
22k
コードの90%をAIが書く世界で何が待っているのか / What awaits us in a world where 90% of the code is written by AI
rkaga
60
43k
Leadership Guide Workshop - DevTernity 2021
reverentgeek
1
240
Build The Right Thing And Hit Your Dates
maggiecrowley
39
3.1k
Digital Ethics as a Driver of Design Innovation
axbom
PRO
1
230
Lightning talk: Run Django tests with GitHub Actions
sabderemane
0
150
Transcript
Nuxt.js本格導入で遠回りし ないためのTips
自己紹介 名前: Yamada Shinji (devneko) GitHub: dotneet (chromy, bpush)、Twitter: santa128bit
ウェブアプリやスマホアプリの開発をするフリーランス。 小さいチームでの仕事が多くフロントもバックエンドも両方やることが多いです。 Nuxt.js歴: 半年くらい。個人でも業務でも積極的に活用中。
発表内容 ・業務でNuxt.jsを使ってみた感想 ・Nuxt.js本格導入で遠回りしないためのTips ・ちょっとした黒魔術のご紹介
業務で使用した感想① ・業務での活用 - 記事を読ませる系サイト - 会員機能やユーザー投稿もあるそこそこな規模のサイト(開発中) ・技術スタック - Nuxt.js -
Ruby on Rails(api mode) - MySQL
業務で使用した感想② ・本当に簡単にSSRできる。 ・SSRならではの問題はあるていど起きる。しかし、回避できない致命的な問題は発生 していない。 ・Nuxt.js自体のバグで困っていることは特にない。現時点で十分な品質だと感じてい る。何度か問題は発生したが自分が遭遇したものは現時点ですべて修正済み。
TIPS 1. まずドキュメントを読む Vue/Nuxtの良いところのひとつは、全体をよく知らなくても少し ずつ利用の幅を拡げていけるところ。 でも、それなりに大きいアプリケーションを書くなら 最初にドキュメントを良く読みましょう 結局ほとんどの機能にお世話になります。ガイドだけでなくFAQも読みましょう。
TIPS 2. チェックしておきたいページ① ・nuxt-community/awesome-nuxt https://github.com/nuxt-community/awesome-nuxt テンプレートやサンプルなどの一覧
TIPS 2. チェックしておきたいページ② ・nuxt-community/modules https://github.com/nuxt-community/modules 便利な小粒のプラグインがたくさんある。 axios, pwa, analytics, firebase,
toast 便利なライブラリへの橋渡し的なものがほとんど。敢えて自分で 書く必要がなければ使った方が楽。
TIPS 3. SSRで発生する問題と解決方法① SSR(初回レンダリング)のときだけこけることがある。 => だいたいwindowやdocumentオブジェクトへのアクセスが原 因 SSRを考慮していないVueのライブラリなどでよく発生する。importやVue.use()時の初 期化処理のときにwindowやdocumentにアクセスしてエラーとなる。
TIPS 3. SSRで発生する問題と解決方法② 1.process.BROWSER_BUILDを使う(FAQに書いてある) if (process.BROWSER_BUILD) { import(‘hoge’) } 2.nuxtのプラグインの場合ssrオプションをfalseにする。
nuxt.config.js の plugins にて {src: '~/plugins/my-plugin.js', ssr: false}, … ] 3.OSSのライブラリならIssueをssrやnuxtで検索する。
TIPS 4. babel/eslint を適用させない方法① ・node_modules外のJSはすべてbabelとeslintが適用される ・npm管理外のライブラリなどを単純にコピーしたいとき困る => 設定ファイルでbabelやeslintの適用除外のディレクトリを作 成
TIPS 4. babel/eslint を適用させない方法② nuxt.config.js の build.extend で自由にwebpackの設定をカス タマイズできる。 vendorディレクトリを適用babelの対象外にする例
TIPS 4. babel/eslint を適用させない方法③ vendorディレクトリを適用eslintの対象外にする例 (excludeにvendorを追加)
TIPS 5. JSのサイズを小さくするために① ・何も考えずにライブラリをどんどん導入すると初期レンダリング に必要なJSのサイズが肥大化する ・導入するライブラリのファイルサイズを気にする ・UIライブラリは便利だがファイルサイズが大きい ・Nuxtは300KBで警告を出す。この基準は意外と厳しい
TIPS 5. JSのサイズを小さくするために② nuxt build --analyze コマンドをすると一目で大きいライブラリが わかる。
TIPS 5. JSのサイズを小さくするために③ pagesディレクトリの.vueファイルから読み込むライブラリに注 意。デフォルトでは各ページごとにライブラリが取り込まれてしま う nuxt.config.js の build.vendor に指定すると共通のJSファイルに取り込まれる。
build: { vendor: [‘axios’] }
TIPS 5. JSのサイズを小さくするために④ ・build.extractCSS を設定してCSSをJSから分離する ・非同期コンポーネントとWebpackのcode splittingを使う export default {
components: { ‘el-select’: _ => import(‘element-ui/lib/select’) } }
TIPS 6. WebStormで型を使って楽をする① ・jsdoc形式で型を指定しておくと入力補完できる。 ・TypeScript用の型定義(index.d.ts)を置いておくとTypeScriptじゃなくても認識してく れる。vueや公式のライブラリのリポジトリから定義を持ってきてindex.d.tsにコピペし て、jsdocコメントで型指定しておくと補完が効いてちょっと嬉しい。 /** @param {ActionContext.<any,any>}
context */ async find(context) { }
TIPS 6. WebStormで型を使って楽をする② ・SFCのテンプレートでも下記のように<script>に書いておけば補完できる。 /** @property {Hoge} hoge */ ・Nuxtでは@や~がwebpackのエイリアスになっていてソースのルートを指定できる。
しかし、WebStormがこれを認識しないため、使うと入力補完が効かなくなる。何か回 避方法がありそうな気もするが分からなかったので、自分のプロジェクトでは@と~は 使わないことにした。最新版のWebStormはエイリアスに対応したらしいが@と~は認 識できない。
黒魔術のご紹介① Nuxtで不便に感じたところ 1.asyncData() はmixinでマージされない。 2.asyncData()内とmethods内でvuexのアクションの呼び出し 方が違う
黒魔術のご紹介② 1.asyncData() はmixinでマージされない。 const mixinA = { async asyncData() {
return {a: ‘aaa’} } export default { mixins: [mixinA], async asyncData() { return {b: ‘bbb’} } => { a: ‘aaa’, b: ‘bbb’ } ってなって欲しい。
黒魔術のご紹介③ 黒魔術(nuxtend)で解決 https://github.com/dotneet/nuxtend ・mixinのasyncData()も呼ばれる ・結果はマージされる。(data()と同じ)
黒魔術のご紹介④ 2.asyncData()内とmethods内でvuexのアクションの呼び出し 方が違う ・asyncData(context)の場合 context.store.dispatch(‘books/findAll’) ・methodsの場合 this.findAllBooks() // mapActions() で定義しておく
黒魔術のご紹介⑤ 黒魔術(nuxtend)で解決 asyncData() から this を使って methodsの関数を呼べる
まとめ ・ドキュメントをまずしっかり読みましょう。FAQも見ましょう。 ・nuxt-community/modules を見ておきましょう ・nuxt.config.js を研究しておきましょう ・JSのサイズに気を配りましょう(build --analyzeが便利)