Hacktoberfest 2026:メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Form error ids should derive from useId (hardcoded title-error/slug-error collide across screen + modal)

オープン
#164 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
72/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
typescript

調査の方向性

まず、ProjectEdit、ProjectBuzzNew、TagEditModal、および関連コンポーネントにおけるフォームエラーの配線を確認し、次に SearchBox と TagPicker で既存の useId の使用方法を比較します。各エラー id を一元化するか、フォームインスタンスから一貫して導出し、同時にマウントされるフォームが一意の id と一致する aria-describedby 参照を持つことを確認します。

索引モデルが issue の本文から書いたものです。

説明

Follow-up from PR #155 (ARIA correctness).

The form error wiring in that PR gives every error <p> an id and points the control at it with aria-describedby. Several of those ids are hardcoded string literals — title-error, slug-error, and siblings in ProjectEdit, ProjectBuzzNew, TagEditModal, etc. When a screen and a modal that both use one of those ids are mounted at the same time (e.g. ProjectEdit with PostHelpWantedModal open), the ids collide and aria-describedby can resolve to the wrong element.

Derive the ids from useId() (as SearchBox and TagPicker already do) so each mounted form instance owns unique ids. Consider a tiny helper so the ${id}-error convention stays in one place.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RdRwHvDupRLV8GuJpYKzEr

主要言語
TypeScript
スター
1
フォーク
1
平均マージ
11分
マージ済み PR(30日)
22

環境構築

  • Dockerfile または Docker Compose ファイルあり
  • プルリクエストのテンプレートなし
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

CodeForPhilly/codeforphilly-ng のほかの issue

CodeForPhilly/codeforphilly-ng の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。