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
tic40
October 24, 2018
Technology
4
2.8k
Nuxt.js移行プロジェクトの話
note engineer meetup#1
2018/10/23
tic40
October 24, 2018
Tweet
Share
Other Decks in Technology
See All in Technology
DevIO2025_継続的なサービス開発のための技術的意思決定のポイント / how-to-tech-decision-makaing-devio2025
nologyance
1
400
【NoMapsTECH 2025】AI Edge Computing Workshop
akit37
0
150
ブロックテーマ時代における、テーマの CSS について考える Toro_Unit / 2025.09.13 @ Shinshu WordPress Meetup
torounit
0
130
【実演版】カンファレンス登壇者・スタッフにこそ知ってほしいマイクの使い方 / 大吉祥寺.pm 2025
arthur1
1
850
Evolución del razonamiento matemático de GPT-4.1 a GPT-5 - Data Aventura Summit 2025 & VSCode DevDays
lauchacarro
0
190
Firestore → Spanner 移行 を成功させた段階的移行プロセス
athug
1
480
CDK CLIで使ってたあの機能、CDK Toolkit Libraryではどうやるの?
smt7174
4
180
Rustから学ぶ 非同期処理の仕組み
skanehira
1
140
研究開発と製品開発、両利きのロボティクス
youtalk
1
530
Generative AI Japan 第一回生成AI実践研究会「AI駆動開発の現在地──ブレイクスルーの鍵を握るのはデータ領域」
shisyu_gaku
0
260
KotlinConf 2025_イベントレポート
sony
1
140
LLMを搭載したプロダクトの品質保証の模索と学び
qa
0
1.1k
Featured
See All Featured
Code Review Best Practice
trishagee
70
19k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
131
19k
Embracing the Ebb and Flow
colly
87
4.8k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
44
2.5k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
Build The Right Thing And Hit Your Dates
maggiecrowley
37
2.9k
Java REST API Framework Comparison - PWX 2021
mraible
33
8.8k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
Building Flexible Design Systems
yeseniaperezcruz
328
39k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
Faster Mobile Websites
deanohume
309
31k
GraphQLとの向き合い方2022年版
quramy
49
14k
Transcript
Nuxt.js移行プロジェクトの話 Taishi Inoue note engineer meetup #1
Taishi Inoue / @tic40 2018/06〜 piece of cake, inc note.muの
フロントエンドリプレイスを担当 Who am I
In progress
note.mu/konpyu/n/n9b7bf4343514 Background
Agenda プロジェクト開始から今日までの取り組み/TIPSを紹介 ・フロントエンドのキャッチアップ ・コードの秩序を保つ ・コンポーネント設計方針を決める ・SSR起因のエラーを解消する ・コンポーネントを管理する ・パフォーマンス向上への取り組み
> フロントエンドのキャッチアップ ・コードの秩序を保つ ・コンポーネント設計方針を決める ・SSR起因のエラーを解消する ・コンポーネントを管理する ・パフォーマンス向上への取り組み
チーム体制 ・エンジニア3名(リモート2、オフィス1) ・UI周りの調整には都度デザイナーも加わる ・Vue.js、Nuxt.jsの社内知見は少ない。 フロントエンドキャッチアップの必要性
フロントエンドのキャッチアップ ・社内ハンズオンの開催 es2015復習-Vue.js入門-Nuxt.js入門ハンズオンを社内開催 ・社外交流 社外から知見のある人物を招いて情報交換、レビュー ・知見の共有 得られた知見は社内wikiへ集約
・フロントエンドのキャッチアップ > コードの秩序を保つ ・コンポーネント設計方針を決める ・SSR起因のエラーを解消する ・コンポーネントを管理する ・パフォーマンス向上への取り組み
コードの秩序を保つ 開始当初はVue.jsのスタイルガイドに沿っていないコードが散見 されていた。 ← v-forの要素に対して v-bind:key が指定されていない。 *ref: jp.vuejs.org/v2/style-guide/
コードの秩序を保つ ・ESLintに `vue/recommended` ルールを適用 ・CIで自動化、Vue.jsスタイルガイド違反のコードを撲滅 .eslintrc.js
・フロントエンドのキャッチアップ ・コードの秩序を保つ >コンポーネント設計方針を決める ・SSR起因のエラーを解消する ・コンポーネントを管理する ・パフォーマンス向上への取り組み
コンポーネント設計 状態管理にVuex コンポーネントデザインにAtomic Designを採用
コンポーネント設計の揺らぎ デザインパターンを取り入れたとはいえ、実装者によって設計に 差があった。 ・単一コンポーネントの再利用性と責務 ・atom vs molecule、molecule vs organism ・状態管理(vuex
state/コンポーネント内data/$emit)使い分け
設計の揺らぎをなくす 揺らぎがある部分は明確にガイドライン化 ・単一コンポーネントの再利用性と責務 再利用性のために責務を増やさない。責務が増える場合はコンポーネント を分割する ・atom vs molecule、molecule vs organism
atomは他のコンポーネントを含まない、stateless、vuexを参照しない... 等々
・フロントエンドのキャッチアップ ・コードの秩序を保つ ・コンポーネント設計方針を決める > SSR起因のエラーを解消する ・コンポーネントを管理する ・パフォーマンス向上への取り組み
SSR起因のエラー コードをそのまま移行するとSSR(server-side-rendering)起因のエラーが 多発してしまった ・window is not defined SSR時には、window関数をはじめクライアントサイドの リソースにはアクセスできない。 ・cookieの参照
これも上記と同じくSSR時に参照できないので嵌った。
エラーログの収集 sentry-moduleプラグイン github.com/nuxt-community/sentry-module slack連携してエラーが起きたら通知。クライアントサイドで予想外なことが 起こっていないかチェック
・フロントエンドのキャッチアップ ・コードの秩序を保つ ・コンポーネント設計方針を決める ・SSR起因のエラーを解消する > コンポーネントを管理する ・パフォーマンス向上への取り組み
コンポーネント把握できない問題 ← 再利用可能なコンポーネントが増 え、もはや把握ができなくなってしまっ た開発者
コンポーネントカタログの導入 Storybook: github.com/storybooks/storybook ・運用コストはかかるが、 コンポーネントが把握できなくなることによる弊害 > 運用コスト *Nuxt v2で Storybook
v3.xが動かなくなる問題があったが、現在はStorybook v4.0rc バージョンを使うことで回避
・フロントエンドのキャッチアップ ・コードの秩序を保つ ・コンポーネント設計方針を決める ・SSR起因のエラーを解消する ・コンポーネントを管理する > パフォーマンス向上への取り組み
パフォーマンス計測 gas-webpagetest: github.com/uknmr/gas-webpagetest webpagetestで定期的に自動計測 > data studioでログの可視化 *SpeedCurveも検討(将来的には導入したい)
bundleファイル分析 ・webpack-bundle-analyzerを活用 ・モジュール単位のファイルサイズを可視化。ファイルサイズの大きいも のから最適化
まだまだあります高速化施策 パフォーマンス向上は地道な取り組み ・画像サイズの最適化 ・リソースの遅延ロード ・リクエスト数を減らす ・PWA対応 ・APIパフォーマンスの向上 高速なnoteを目指して、 継続してチューニングしていきます
最後に
リリースノート公開中 note.mu/noteeng/m/me7637ba82821
; Vue Fes Japan@11/3 https://vuefes.jp/
ありがとうございました