Vercel を使うとここに挙げたようなことについて気にしなくても良くなる。 まず手軽に始めるなら、個人的には Vercel 使うのが初手としてはおすすめだと思う。 考慮しておくとよさそうなこと Next.js ドキュメント Going to Production | Next.js Deployment | Next.js Dockerfile https://github.com/vercel/next.js/blob/canary/examples/with-docker/Dockerfile standalone モード Next.jsのスタンドアロンモードでビルドしたイメージを Cloud Run へデプロイする standaloneモードを利用してNext.jsのデプロイ速度を改善した話 - バイセル Tech Blog CDNキャッシュ ZOZOTOWNのWebホーム画面をN
免責事項 社内向けに展開するように雑にまとめました Next.jsの知見が深くない人がリードしてPoCを立ち上げなきゃいけなくなったが、社内的にはNext.jsを推奨しているみたいな場面を想定しています なので自信ないところも多いですが割と断言するように心がけて書いています PoCの立ち上げ想定なので、jest/Storybookなど内部品質面についてあまり深く書くことを避けています ほぼ自分の知識だけで書いており私見も多いですし、そもそも自分自身がトップクラスの知識や視座を有しているわけでもないので、まずは以下の話を理解はした上で、踏襲するかどうかは別途他記事やGitHub、公式ドキュメントなどを漁って判断することを推奨 App RouterかPages Routerか 2023年末現在まだApp Routerは技術記事が足りてきている印象ではないため、社内でノウハウを積極的に貯めていく
2023/05/05 追記 v13.4.0 をもって App Router は安定版になりました! https://nextjs.org/blog/next-13-4 公式ドキュメントもベータ→正式版にマージされました。 内容が充実してきている様子ので、そちらを確認してください。 https://nextjs.org/docs 加えて、公式ドキュメントの改善で分かったポイントもいくつか修正しています。 Next.js v13 から App Router 機能 (app ディレクトリ) が新しく追加されました。 (v13.3.0 現在はベータ版です。 v13.4.0 をもって安定版になりました!) ファイルベースの Layout 機能 処理の一部を Server Component に移しバンドルサイズを削減できる 例: remark を利用した Markdown のパース が有名なところだ
Next.js の v12.2.0 では、SWC plugin がサポートがされました 🎉 元々 Babel plugin や ESLint plugin などを作るのが好きで、これを機に SWC plugin を作成して Next.js に適用してみたので、それについて記事を残そうと思います。 作成する SWC plugin 今回は、babel-plugin-react-native-web を SWC plugin に置き換えて、Next.js の React Native for Web 用の公式サンプルを動かせるようにすることを目標にしました。babel-plugin-react-native-web は、次のような import/export 文の変換を行うプラグインです。 + import ReactNative from "react-native"; // 変換前 - i
動機と目的 普段、Next.jsでアプリケーションを開発しています。当初は Next.js にも TypeScript にも慣れていなかったため、ページのパスを定数で定義し、Link コンポーネントで呼び出していました。 // constants/path.ts export const TOP_PATH = '/' export const USERS_PATH = '/users' // ...
Next.js Commerce Vercelの公式なNext.jsプロジェクト。 components配下は、 第一階層のディレクトリ名は小文字 第二階層以下のディレクトリ名はパスカル コンポーネントのファイル名はパスカル indexだけは小文字 components以外はケバブな感じ。 / ├── README.md ├── assets │ ├── base.css │ ├── chrome-bug.css │ └── .... ├── components │ ├── auth │ │ ├── ForgotPassword.tsx │ │ ├── LoginView.tsx │ │ ├── SignUpView.tsx │ │ └── index.ts │ ├── cart │ │ ├── CartItem │ │
The Next.js team at Vercel released the Layouts RFC a few months ago outlining the vision for the future of routing, layouts, and data fetching in the framework. The RFC is detailed and covers both basic and advanced features. This post will cover the most important features of the upcoming Next.js changes landing in the next major version that you should be aware of. Creating RoutesIn the new app
いろいろ参考にする components/ 全ページ共有、ページ固有のコンポーネントを分ける pages/ componentを呼び出す services/ ユーザーのアクションに応じて、データの加工(結合や集計など)を行うコードを置いておきます。 加工元となるデータ取得は、repositories配下の関数を呼び出す ユーザーの1アクションに対して、1つのサービス関数を作るイメージ repositories/ DBやSaaSにアクセスする models/ entities/ servicesで加工したデータと、repositoriesで取得したデータの区別が付きやすいように、servicesで生成するオブジェクトについては、モデル名にXXXDataのようなサフィックスをつけるようにしています libs/ 使用しているライブラリ固有のコードで、初期化や設定のコードなど、データ取得に絡まない
近日連投していた Next.js 記事のサンプルコードを公開しました。このサンプルコードを元に、私のフロントエンドディレクトリ構成・テスト観点を紹介します(あくまで執筆現在の脳内アウトプットになりますのでご了承ください) フロントエンドディレクトリ構成の事情 タイトルの「フロントエンドディレクトリ構成」をさす「Components」のディレクトリ構成は、いつも悩みのタネです。このモジュールシステムは「デザインシステム観点・アクセシビリティ観点・フロントエンド実装観点」の 3 つの観点が混在するため事情が複雑です。どうせ作るのなら「デザイナー・フロントエンド」どちらの開発基盤にもなりえる、盤石なモジュールシステムを目指したいですよね。 "AtomicDesign やめました"という声をたまに聞くのですが「デザインシステム的に捨てていいの?」と思うこともあるので、とくに要望がなければ、筆者は「
ZennではフロントエンドにNext.jsを使っています。もともとはVercelで動かしていたのですが、2021年3月にGoogle Cloudに移行しました。今回は移行を決めた理由や、具体的な構成、移行作業などについて書きたいと思います。 なぜ移行したのか Next.jsのデプロイ先としてVercelは圧倒的に優れています。ISRやImage OptimizationといったNext.jsの強力な機能をサーバー側の追加設定なしで使用できますし、CDNでの静的ファイルのキャッシュなども特に意識しなくてもいい感じにやってくれます。 Vercel以外にデプロイするとなると、Next.jsの一部の機能がうまく動かなかったり、パフォーマンス・チューニングを自分で頑張る必要があったりと自分で面倒を見なければならない部分が多くなります。 しかし、Zennのケースでは以下のような理由からVercelから
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く