"use server"; でexportした関数が意図せず？公開される
Next.js AppRouterで利用できるReactのServer Actions機能。クライアントからサーバ上の処理を関数で呼び出せるので非常に便利ですが、 "use server"; のことをあまり知らず、誤った使い方をすると意図せず公開したくない関数が外部に公開されてしまうケースがあるので注意です（ほとんどこんなケースはないと思いますが、なくはないので注意喚起です）。 Server Actionsの例 Server Actions用の関数として宣言するためには "use server"; が必要です。それ以外は至って普通の非同期関数で大丈夫です。 "use server"; export async function someAction() { return { message: "Server Action", }; } 次に定義したServer Actionsの関数を呼び出
Next.jsを使い続けたい好きなトコロ
ムーザルちゃんねるのzaruです。今回はムーさんと、Next.jsを使い続けたい好きなトコロについて話しました。Next.jsが合うか合わないかは、正直プロジェクトとチーム体制や方針に大きく左右されます。僕たちが好きなトコロにピンときた方にはきっと合うと思いますのでぜひさわってみてください。 フロントとバックの境界線がなくなる フロントエンドとバックエンドの境界線がなくなるって、何、なくなるわけないだろ！と思うかもしれません。確かに実際には境界線がなくなるわけではなく隠蔽されているのが実態ではありますが、それによる開発体験の向上がとても好きです。 バックエンドの処理を簡単に実行できる Next.js（実態はReact）のServer Componentを使えば、コンポーネント内でSQLの実行などがそのままできます（以下のコードは例のために直接SQLを書いているので「うぇ？」と思うかもしれま
暗号化に対応した次世代dotenvツールdotenvxを使う
特に一番最後の暗号化サポートは非常に嬉しい進化です。dotenv単体で環境変数を運用すると、秘匿情報が含まれたdotenvファイル自体の管理に困ることや、デプロイする際にどうやって環境変数を提供するかが課題になることがありました。 現代ではクラウドプラットフォーム上にシークレットマネージャーのような仕組みが用意され、そこで中央管理するというのが一般的になっているかと思います。ただ、それだと変数のバージョン管理やレビューの仕組みを別途用意しないといけなかったりと完全ではありません（個人的主観です）。 dotenvファイル自体が暗号化され、Gitでバージョン管理でき、そのままデプロイして環境変数を適用できたら運用の手間が一気に減ります。
Next.jsのlayout.tsxで認証チェックすると情報漏洩するかも
Next.jsの認証チェックどこでするか問題 基本的には middleware.ts で行うと思うのですが、肥大化を避けたり、ちょっとした共通処理は layout.tsx に書くこともあるでしょう。今回は layout.tsx で認証チェックをした場合に、実装によっては意図せず認証ユーザにしか表示したくない情報が漏洩してしまうかもしれないケースを紹介します。 問題のあるコード import { redirect } from "next/navigation"; export const dynamic = 'force-dynamic'; function currentUser() { // ここでセッションデータから認証ユーザ情報を取得する関数 // デモ用にログインしていないユーザを再現したいのでfalseを返す return false; } export default fun
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
