Zenn uhyo

Zenn uhyo

zenn.dev/uhyo
10
Articles
11月10日 23:01
Last updated
Web Locks APIでマルチタブのアクセストークン更新競合を防ぐ【AI生成】

Web Locks APIでマルチタブのアクセストークン更新競合を防ぐ【AI生成】

この記事では、Web Locks APIを使用して、シングルページアプリケーション(SPA)におけるマルチタブ環境でのアクセストークンの重複更新を防ぐ方法を紹介しています。アクセストークンは定期的に更新される必要がありますが、複数のタブが同時に更新を試みると、サーバーに過剰なリクエストが送信され、トークンの不整合が生じる可能性があります。従来の解決策にはBroadcastChannelやlocalStorageイベントがありましたが、タイミングの問題がありました。Web Locks APIを利用することで、タブ間での排他制御が可能になり、トークン更新のリクエストを一つのタブに限定することができます。具体的な実装方法も示されており、ロックを取得した後にトークンの有効期限を確認することで、無駄な更新を避けることができます。 • マルチタブ環境でのアクセストークン更新の重複問題を解決する必要がある。 • Web Locks APIを使用して、タブ間での排他制御を実現する。 • 従来の方法ではタイミングの問題があり、複数タブでの更新が重複する可能性があった。 • Web Locks APIを使うことで、ロックを取得したタブだけがトークン更新を実行できる。 • トークン更新の前にロックを取得し、他のタブが更新済みかを確認することで無駄なリクエストを防ぐ。

Zenn uhyo
api tool
eslint-plugin-import-accessのpackageDirectoryオプション

eslint-plugin-import-accessのpackageDirectoryオプション

この記事では、ESLintプラグインeslint-plugin-import-accessの新バージョン(v3.1.0)で追加されたpackageDirectoryオプションについて説明しています。このオプションにより、どのディレクトリをパッケージとして扱うかを指定でき、インポートの制限を柔軟に設定できるようになります。従来は全てのディレクトリがパッケージとして扱われていましたが、packageDirectoryを使用することで特定のディレクトリを除外したり、特定のパターンに基づいてパッケージを定義することが可能になります。これにより、プロジェクト内のファイル整理が容易になり、defaultImportabilityオプションとの組み合わせで、過度な制限をかけることなく秩序を保つことができます。 • 新オプションpackageDirectoryにより、特定のディレクトリをパッケージとして扱うことが可能になる。 • 従来のルールでは全てのディレクトリがパッケージとして扱われていた。 • packageDirectoryを使用することで、特定のディレクトリを除外したり、パターンに基づいてパッケージを定義できる。 • defaultImportabilityオプションと組み合わせることで、インポートの制限を柔軟に設定できる。 • プロジェクト内のファイル整理が容易になり、秩序を保つことができる。

Zenn uhyo
library tool
自己補正するコンポーネント: レンダリング中に状態更新する公式テクニックの解釈

自己補正するコンポーネント: レンダリング中に状態更新する公式テクニックの解釈

この記事では、Reactにおけるレンダリング中に状態を更新するテクニックについて解説しています。公式ドキュメントの「そのエフェクトは不要かも」に基づき、propsが変更された際にstateを調整する方法を紹介しています。具体的には、useEffectを使用せずにレンダリング中に状態を更新することで、パフォーマンスやユーザー体験を向上させることができると述べています。従来の方法では、useEffectを使って状態を更新することが推奨されていましたが、これには不整合な状態が発生するリスクがあるため、レンダリング中に直接状態を更新する方法がより適切であると説明されています。 • Reactの品質を高めるためには、公式ドキュメントに従ったコードを書くことが重要である。 • レンダリング中に状態を更新するテクニックは、propsが変更されたときにstateを調整するための方法である。 • useEffectを使うと、レンダリング後に状態が更新されるため、一時的に不整合な状態が発生する可能性がある。 • レンダリング中に状態を更新することで、パフォーマンスやユーザー体験が向上する。 • 公式ドキュメントの内容を批判的に理解することが重要である。

Zenn uhyo
framework tool
Reactのデータ再取得、タイムスタンプで管理すると宣言的になる話【AI生成】

Reactのデータ再取得、タイムスタンプで管理すると宣言的になる話【AI生成】

この記事では、Reactにおけるデータ再取得の実装方法について、タイムスタンプを用いた宣言的なアプローチを提案しています。従来の命令的な方法では、ボタンを押してrefetch()を呼び出す流れが手続き的であり、Reactの宣言的なUI思想に反していると指摘しています。代わりに、タイムスタンプをstateとして持ち、これを更新することでデータを再取得する方法を示しています。このアプローチにより、UIのバージョンを管理し、Suspenseと組み合わせることで、より自然なデータ取得が可能になると述べています。 • Reactでのデータ再取得は通常命令的であり、宣言的なUI思想に反することがある。 • タイムスタンプをstateとして持つことで、データ再取得のトリガーを状態として表現できる。 • この方法により、UIのバージョンを管理し、データ取得を宣言的に行える。 • Suspenseと組み合わせることで、ローディング状態の管理が容易になる。 • 複数の更新トリガーを統一的に扱うことができる。

Zenn uhyo
framework tool
AIに技術記事を書かせる:9回の反復で到達した「完璧すぎる」という逆説

AIに技術記事を書かせる:9回の反復で到達した「完璧すぎる」という逆説

この記事では、AIに技術記事を書かせる試みについて述べられています。著者は、Claude Codeを使用して、記事生成、レビュー、スタイルガイドの改善を繰り返すシステムを構築しました。最初は品質が7〜8割程度と予想していましたが、9回の反復を経て9.0/10の評価に達しました。特に、完璧すぎる記事が逆にAIらしさを感じさせるという「完璧すぎる逆説」に直面しました。システムは3つのエージェント(Writer Agent、Reviewer Agent、Style Guide Updater)で構成され、各エージェントは独立して機能します。反復を重ねる中で、メタ認知的シフトや不完全さの重要性が明らかになり、最終的には人間らしい不完全さを取り入れることで、より自然な記事が生成されるようになりました。 • AIに技術記事を書かせる試みの目的は、人間と区別できないレベルの品質を目指すこと。 • Claude Codeを使用し、記事生成、レビュー、スタイルガイド改善のサイクルを構築。 • 反復を重ねる中で、品質が向上し、最終的に9.0/10の評価を得る。 • 完璧すぎる記事が逆にAIらしさを感じさせるという課題に直面。 • システムは3つのエージェント(Writer、Reviewer、Style Guide Updater)で構成され、各エージェントは独立して機能。 • メタ認知的シフトや不完全さの重要性が明らかになり、自然な記事生成に寄与。 • 不完全さを取り入れることで、より人間らしい記事が生成されるようになった。

Zenn uhyo
api library tool
小手先に見えるテクニックでも、実はReact的に考えられる

小手先に見えるテクニックでも、実はReact的に考えられる

この記事では、ReactにおけるuseEffectの適切な使用法と、keyを使ったテクニックについて解説しています。特に、親コンポーネントから渡されるpropsが変更された際に、コンポーネントのステートをリセットする方法としてkeyを利用することが提案されています。従来の考え方では、useEffectを使ってステートを更新することが一般的でしたが、これはReactの宣言的UIの原則に反する可能性があります。keyを使うことで、コンポーネントが新しいインスタンスとして再生成され、ステートが初期化されることが明確に示されます。これにより、Reactの基本的な考え方に沿った形で、より効率的にコンポーネントを管理できるようになります。 • useEffectの不適切な使用法を避けるためのkeyを使ったテクニックの提案 • propsが変更された際にコンポーネントのステートをリセットする方法 • keyを使うことでコンポーネントが新しいインスタンスとして再生成される • Reactの宣言的UIの原則に基づいた理解の重要性 • keyの使用がReactの基本的な考え方に合致することの説明

Zenn uhyo
framework tool
Biome v2の型推論を試して限界を知る

Biome v2の型推論を試して限界を知る

この記事では、Biome v2の型推論機能について詳しく説明しています。Biome v2は、TypeScriptコードに対するlint機能を提供し、型情報を利用したlintingを行います。従来のTypeScript-ESLintはTypeScriptコンパイラに依存しており、パフォーマンスに課題がありましたが、Biomeは独自の型推論を実装しています。ただし、TypeScriptコンパイラの複雑さから、完全な再現は不可能であり、Biomeの型推論は75%のケースを検知できるとされています。具体的な例として、Promiseを返す関数に対するlintエラーの検知能力を試し、型注釈の有無による影響を検証しています。最終的に、型注釈を明示することで、Biomeの型推論が正しく機能することが示されています。 • Biome v2はTypeScriptコードに対するlint機能を提供する。 • 従来のTypeScript-ESLintはTypeScriptコンパイラに依存しており、パフォーマンスに課題があった。 • Biomeは独自の型推論を実装しているが、完全な再現は不可能。 • noFloatingPromisesルールを用いて、Promiseがawaitされていない場合の検知能力を試した。 • 型注釈を明示することで、Biomeの型推論が正しく機能することが確認された。

Zenn uhyo
library tool
.d.tsファイルをちゃんと使うために必要な知識

.d.tsファイルをちゃんと使うために必要な知識

この記事では、TypeScriptにおける.d.tsファイル(型定義ファイル)の正しい使い方について解説しています。.d.tsファイルは、既存のライブラリやモジュールの型シグネチャを記述するもので、実装の詳細は含まれません。TypeScriptのプロジェクトでは、手動で.d.tsファイルを書く必要はなく、--declarationオプションを使って自動生成することが推奨されています。また、.d.tsファイルは、対応する.jsファイルが存在する場合にのみ意味を持ち、誤った使い方として、TypeScriptプロジェクトで手動で.d.tsファイルを書くことが挙げられています。さらに、TypeScript 5.0以降では、.d.tsファイルをimport typeでインポートすることが可能になり、これが従来の理解と矛盾する点についても触れています。 • .d.tsファイルはTypeScriptにおける型定義ファイルであり、ライブラリの型シグネチャを記述するために使用される。 • 手動で.d.tsファイルを書くのではなく、--declarationオプションを使って自動生成することが推奨される。 • .d.tsファイルは対応する.jsファイルが存在する場合にのみ意味を持つ。 • 誤った使い方として、TypeScriptプロジェクトで手動で.d.tsファイルを書くことが挙げられる。 • TypeScript 5.0以降では、.d.tsファイルをimport typeでインポートすることが可能になった。

Zenn uhyo
api library tool
Reactコンポーネントが「純粋である」とはどういうことか? 丁寧な解説

Reactコンポーネントが「純粋である」とはどういうことか? 丁寧な解説

Zenn uhyo
Reactの文脈での「副作用」は2種類あるのではという話

Reactの文脈での「副作用」は2種類あるのではという話

Zenn uhyo