このデックでは、エラーレスポンス設計から考える、プロダクトの0→1開発におけるGraphQLへの向き合い方について紹介します。 旧タイトル: 「TypeScriptとGraphQLを活用した変化に強いプロダクト作り」。2024年9月9日(月) に更新しました。
エラーレスポンス設計から考える、0→1開発におけるGraphQLへの向き合い方
このデックでは、エラーレスポンス設計から考える、プロダクトの0→1開発におけるGraphQLへの向き合い方について紹介します。 旧タイトル: 「TypeScriptとGraphQLを活用した変化に強いプロダクト作り」。2024年9月9日(月) に更新しました。
TypeScriptの不要なexportを自動で削除するOSS「ts-remove-unused」を開発しました
こんにちは。メディアカンパニーに所属する鴻巣和司 (@kazushikonosu) です。普段はLINEスキマニのフロントエンドの開発をしています。業務をきっかけに、TypeScriptの不要なデッドコードを自動で削除するツール ts-remove-unused を開発し、GitHub上でOSSとして公開しました。本稿では、ts-remove-unusedが解決しようとしている問題や直近で行った大規模な変更について紹介します。 exportしていることで気づきにくい不要なコード TypeScriptを使っている場合、tsconfig.json の compilerOptions.noUnusedLocals を有効にすることで、ファイル内で参照がない不要な変数などの定義をTypeScriptコンパイラの実行時に検知することが可能です。また、ESLintなどの静的解析ツールを使い適切にルール
React 19の新機能まとめ — サーバーコンポーネントは全フロントエンドエンジニア必見
9月5日、Vercelの公式ブログで「What’s new in React 19 – Vercel」と題した記事が公開された。この記事では、React 19における重要な新機能や改善点について、詳細かつ実践的な内容が取り上げられている。これまでのReactのバージョンで導入されてきた実験的機能が、React 19で正式に安定化され、多くの開発者にとってさらなるパフォーマンスの向上と開発体験の向上が期待されている。 ここでは、同記事からポイントを絞って内容をご紹介する。 サーバーコンポーネント (Server Components) サーバーコンポーネントは、Reactの10年の歴史の中でも最も大きな変化の1つであり、React 19の新機能の基盤となるものである。この機能により、以下の点が大幅に改善される。 初期ページロード時間の短縮 サーバーコンポーネントを使用すると、クライアントに送
URLシェアを支える技術 lz-string
WebアプリでURLシェアを実装する際に、URLにすべての情報を持たせてしまいたい場合があります。そのとき、情報をそのままクエリ文字列に渡してしまうとURLの文字数制限に引っかかってしまうかもしれません(厳密にはURLに上限はないようですが、現実はいつもブラウザ実装依存)。 そんなときURLセーフな文字列形式で圧縮してくれるライブラリがあります。lz-sringです。 変換の例 ライブラリで compressToEncodedURIComponent というAPIが提供されているのでこれを使用します。標準のencodeURIComponentでURLセーフな文字列に変換した場合とサイズ比較をしてみましょう。 import lzstring from "lz-string"; const rawData = "Lorem ipsum dolor sit amet, consectetur a
Vitest公式になったeslint-plugin-vitestを導入して、適切なVitestのお作法を学んでみる
import vitest from "@vitest/eslint-plugin"; export default [ { files: ["tests/**"], // or any other pattern plugins: { vitest }, rules: { ...vitest.configs.recommended.rules, // you can also use vitest.configs.all.rules to enable all rules + // e.g. 'vitest/no-test-return-statement': 'error', + "vitest/max-nested-describe": ["error", { "max": 1 }] // you can also modify rules' behavior using optio
Node.jsで型安全な環境変数を扱うスニペット
Node.js で型安全な環境変数を扱うスニペットを作りました。 next devのようなアプリケーションの起動、Playwright でのテストなどコマンドごとに渡したい環境変数のセットが異なるケースがあります。 この場合に環境変数をまとめたものを定義して、それをコマンドごとに読み込むセットを変えたいことがあります。 次のようにベタ書きしてもいいのですが、渡したい環境変数が増えると管理が大変になります。 NEXT_PUBLIC_LOCALHOST_URL=http://localhost:3000 NEXT_PUBLIC_API_URL=http://localhost:3001 NEXT_PUBLIC_IS_TEST_MODE=false FOO="bar" next dev そのため、.envのような環境変数をまとめたファイルを使いたくなります。 Node.js は--env-fil
PrismaのTypedSQLがなぜアツイのか
Prisma界隈で話題沸騰中（自分調べ）のTypedSQLだが、自分の中ではかなりアツいと思っているので、その理由を語ろう。なおTypedSQLの機能とか仕組みについては記述しないのでドキュメントや以下の記事を参照するとよい。 Prismaの難しさ 複雑なクエリを組み立てるのが特に難しい。複雑といっても何10行もあるようなクエリとかではなく、joinとか集計関数がいくつかあるくらいで十分複雑になる。たとえば特定のユーザーに紐づく記事をコメントの数を含めて取得したいとする。クエリは雰囲気こんな感じ。SQLとしては全然難しくない。 SELECT posts.id, count(comments.id) AS cnt FROM posts INNER JOIN users ON posts.author_id = users.id LEFT JOIN comments ON posts.id =
Deno first でやっていく
去年末ぐらいから Deno を使う割合がグッと増えてきた。最近のJS関連は7割ぐらい deno 環境の VSCode でコードを書いている気がする。 今回はいくつかの実例を示しながら、実際に Deno 使えるじゃんというイメージを持ってもらうためのユースケースを紹介していく。 というか、 deno が普及してくれないと、自分が作ったツールの紹介を全部 deno のインストールから書かないといけなくなる。みんなインストールしといて。 最初に: なぜ Deno を使いたいか 一番の問題点、Node は新しいプロジェクトを一式整えるための手間が非常に重い。 とくに ts で書いたものを他の環境に渡すための方法が未だにしんどい。ある環境で動いたコードをそのままコピーしても、プロジェクト設定の非互換を踏む可能性が非常に高い。 deno にそういう側面がないとは言わないが、非常に少ない。とくに TS
JavaScript/TypeScriptからWebAssemblyやネイティブバイナリを生成するコンパイラ「Porffor」の開発が加速へ、開発者がフルタイムで取り組み
「Porffor」は、JavaScript/TypeScriptをWebAssemblyバイナリやネイティブバイナリへとコンパイルする実験的なツールであり、これまでにない2つの特徴を備えています。 1つ目はJavaScript/TypeScriptをコンパイルしてWebAssemblyバイナリやネイティブバイナリを生成しようとしている点です。 これまでもJavaScript/TypeScriptをWebAssemblyに変換するツールは存在していましたが、JavaScriptのコードとWebAssembly版のJavaScriptエンジンを1つにパッケージングするという手段で実現していました。 実行時には、パッケージ内部のJavaScriptコードをWebAssembly版JavaScriptエンジンで実行していたのです。そのため生成されたバイナリの大きさは比較的大きく、また実行速度はあく
「Deno 2」が間もなく登場。Denoにとって初めてのメジャーバージョンアップに
Node.jsの登場は、それまで比較的面倒だったノンブロッキングな非同期のネットワークプログラミングを容易にするAPIと、それをJavaScriptという非常に広く使われているプログラミング言語で利用可能にしたことで、サーバサイドにおけるJavaScriptランタイムという分野を新たに切り開くだけでなく、当時課題となっていたC10K問題の解決など、サーバアプリケーションの開発に大きな影響を与えました。 参考：Node.jsのコンセプトとは？ ライアン・ダール氏による東京Node学園祭 基調講演（前編） その上で、Node.jsはAWS Lambdaに代表されるサーバレスコンピューティング環境の基盤として採用され、新たな分散コンピューティング環境の革新にも寄与してきたと言えます。 ライアン・ダール氏の反省：NodeからDenoへ、 しかしNode.jsの開発者であるライアン・ダール氏は201
おまえら禁じられたインデックスアクセスを平気で使ってんじゃねえか！わかってんのか？『ランタイムエラー』が生まれたのは人間がコンパイラオプションに甘えたせいだろうがよ！
おまえら禁じられたインデックスアクセスを平気で使ってんじゃねえか！わかってんのか？『ランタイムエラー』が生まれたのは人間がコンパイラオプションに甘えたせいだろうがよ！ 2022.06.25 TypeScript 4.1 から noUncheckedIndexedAccess オプションが追加されました。このオプションは上記のような配列のアクセスやオブジェクトのプロパティのアクセスをより厳密にします。 具体的には、配列に対するインデックスアクセスやインデックスシグネチャを通じたプロパティのアクセスは常に `undefined` とのユニオン型となります。
TypeScriptで「選択肢」の定義をEnum的な定数にまとめる――satisfiesとSSoTもあるよ
ソート順の選択プルダウンがある一覧系ページを実装するとき、選択肢たちの管理方法に頭を悩ませることが多いと思います。 商品一覧ページの概要 ソート順プルダウンの選択肢たち 上の画像に示したような場合だと、 《クエリパラメータ》と《選択肢》の間の相互変換 ?sort=price&order=desc <--> 「価格が高い順」 《select の状態に使うための文字列》と《選択肢》の間の相互変換 <option value={id}>{label}</option> クエリパラメータが sort order の2つあり、それらをそのまま流用できないので 最低限でも、これらの変換ロジックを用意しておく必要がありますね。 この記事では、このような「選択肢と、それにまつわる変換ロジック群」を整理する方法を、高凝集・SSoT (Single Source of Truth; 信頼できる唯一の情報源)
ネストオブジェクトの罠 RE: TypeScriptで「選択肢」の定義をEnum的な定数にまとめる
この記事は、静的解析とビルドサイズ面で興味深いテーマでした。記事として自分の考えを書きます。 注意。あくまでビルドパフォーマンス視点での最適化です。強い意図があって、自分のドメインモデリングの方法論ではこれが最適なんだ、というなら元コードの方法論を止めるつもりはありません。 元記事のコードを minify するとどうなるか 元コードを参考に、それにアクセスするサンプルコードを書いてみます。 const sortingOptions = { priceDesc: { id: "priceDesc", sort: "price", order: "desc", label: "価格が高い順", }, priceAsc: { id: "priceAsc", sort: "price", order: "asc", label: "価格が安い順", }, ratingDesc: { id: "ra
process.getBuiltinModule(id) は TypeScript を ESM 化させるか？
こんにちは teppeis です。普段は開発本部長をやってますが、ブログフェスに駆り出されました！ 本日は Node v22.3.0 に続いて v20.16.0 にもバックポートされた process.getBuiltinModule(id) について解説します。 問題: 同期的な条件付き require を ESM 化できない Node v22 にて、フラグ付きで CJS (CommonJS Modules) から ESM を require できるようになりました。いわゆる require(esm) です。これにより、今までは互換性の懸念で ESM 化を足踏みしていた著名ライブラリも ESM 化を試みる動きが出てきました。 TypeScript もその一つで、TypeScript チームは TypeScript 自体を ESM 化しようと試みました。しかしながら、今回の主題である条件付
export {}; が使われるTypeScript特有の事情
TypeScriptのコードでは、export {}; という記述を見かけることがあります。これはECMAScriptの構文ではあるものの、これが使われる背景にはTypeScript特有の事情があります。この記事では、export {}; がなぜ使われるのか、どのような効果があるのかを解説します。 export {}; とは この構文は、exportというキーワードから分かるように、モジュールに関連する構文です。 一般に、export { ... };という構文は、既存の変数をモジュールからエクスポートするために使われます。例えば、次のようなコードが考えられます。 const foo = 42; const bar = "hello"; const banana = "banana"; export { foo, bar as hello, banana as "🍌", }; 変数をエク
TS 5.6のiterator helpersサポート――BuiltinIteratorsのwhat & whyを知る - Qiita
先日、TypeScript 5.6 Betaが公開され、あわせてリリースノートも出ました。 この記事では、TS 5.6の新機能の中でもIterator helpersに注目します。特に、Iterator helpersのサポートに合わせて型定義に追加されたBuiltinIteratorsやBuiltinAsyncIteratorsについて解説します。 Iterator helpersとは Iterator helpersは、ECMAScriptのプロポーザルのひとつであり、この記事の公開時点ではStage 3という完成目前の状態にあります。TypeScriptではStage 3に到達したプロポーザルが実装されるので今回これが実装されることになりました。 ランタイムの実装としては、この記事公開時点ではGoogle Chrome 122, Node.js 22.0.0, Deno 1.42など
unjs/unbuildに入門してみた - くらげになりたい。
pnpm workspace+TypeScriptなmonorepoで、 Cloud Functions for Firebaseを開発していたときに、 unjs/unbuildでビルドしてみたときの備忘録(*´ω｀*) 少ない設定でビルドができて便利(*´ω｀*) unbuildとは unjs/unbuild: 📦 A unified JavaScript build system 「A unified JavaScript build system」らしい。 Viteがフロントエンド用のビルドに対し、 unbuildはライブラリなどによさそうな印象 少ない設定でESM/commonjs+型定義を生成できる package.jsonからビルド設定を自動で取得 package.jsonの設定やdependenciesの過不足を自動チェック ビルドする方法は2つあり、rollupとmkdi
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TypeScriptで 負荷テストを書こう 〜k6のシングルバイナリの秘密〜
React 19を概念から理解する
tsconfig.jsonの設定を見直そう！�フロントエンド向け 2024夏
