React Server ComponentでもContextで状態を共有する | フューチャー技術ブログ
Next.jsの最近の大きな目玉機能はReact Server Component(以下サーバーコンポーネント)です。パフォーマンスアップに有効だったり、gRPCだRESTだGraphQLだ論争を終わりにするServer Actionsなど盛りだくさんです。 一方で、サーバーコンポーネントはコーディング上の制約がいろいろあります。 サーバーコンポーネントではhooksが使えない サーバーコンポーネントのソースからクライアントコンポーネントはimportできるが逆はできない。レンダーツリーを工夫すればクライアントコンポーネントの下にサーバーコンポーネントを配置することは可能 サーバーコンポーネントでは非同期コンポーネントを作成でき、fetchでサーバーから情報をとってきたり、DBアクセスした結果を利用できます。しかし、最近のモダンReactの場合、状態管理などはすべてhooksに寄せるので大
管理画面等でNext.jsをBetter Reactとして使う | フューチャー技術ブログ
最近、Next.jsが複雑になりすぎて、単なるウェブ画面を作る用途にはNext.jsは重すぎるので別のものが良いとか、Vercel統合のための機能が多いんでしょ、みたいな感想を見かけることが増えた気がします。特に管理画面とか社内システムとかですね。B2Cでも設定画面系とかは当てはまるかもしれません。 ホンダ時代に、タイプRを買っても実際にサーキットとかに走らせに行く人は1/10ぐらい、という話を聞いた気がしますが、必ずしも、そのすべてのパフォーマンスを引き出さないのはダメとかなくて、単にかっこいいからとか、一部のメリットでも自分にあえば良いのです。 Next.jsも、たくさん機能がありますが、ミニマムな使い方もできます。 ほぼNext.jsの機能をオフにした使い方たぶんNext.jsを最低限で使うライン・メリットはここかな、と思います。 基本的に全部CSR(Client Side Rend
スキーマファースト開発のためのOpenAPI（Swagger）設計規約 | フューチャー技術ブログ
はじめまして。TIG DXユニット 1の亀井です。 はじめに みなさん、Swagger使ってますか？ Swaggerや周辺ツールについては 某先輩の記事 にて丁寧に解説されていますので、 本記事では実際にSwaggerのスキーマ定義を設計していく上で取り決めた規約について書いてみたいと思います。 前提私が在籍しているプロジェクトでは、REST APIは golang でフロントエンドを Vue.js + TypeScript で構築しています。 短期間・高品質での構築を実現するためにSwaggerを設計ドキュメントとしてだけではなく、コード自動生成やモックサーバーに活用させることで徹底したスキーマファーストな開発を行ってきました。 というわけで、今回は下記のツールを利用することを前提として規約を作成しています。 go-swagger: Goアプリケーションのハンドラ、リクエスト/レスポンス
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
