CodeForPhilly / CodeForPhilly/codeforphilly-ng
Form error ids should derive from useId (hardcoded title-error/slug-error collide across screen + modal)
- Ngôn ngữ chính
- TypeScript
- Star
- 1
- Fork
- 1
- Merge trung bình
- 5 ngày 3 giờ
- Pull request đã merge (30 ngày)
- 9
Mô tả
Follow-up from PR #155 (ARIA correctness).
The form error wiring in that PR gives every error `
` 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.com/claude-code)
https://claude.ai/code/session_01RdRwHvDupRLV8GuJpYKzEr
Hướng dẫn đóng góp
Chưa lập chỉ mục được hướng dẫn đóng góp cho kho mã nguồn này
Hướng nghiên cứu
Bắt đầu bằng cách xác định phần kết nối lỗi biểu mẫu trong ProjectEdit, ProjectBuzzNew, TagEditModal và các component liên quan, sau đó so sánh cách sử dụng useId hiện có trong SearchBox và TagPicker. Tập trung hóa từng id lỗi hoặc nhất quán suy ra chúng từ instance của biểu mẫu, đồng thời xác minh rằng các biểu mẫu được mount đồng thời có các id duy nhất và các tham chiếu aria-describedby khớp nhau.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Đánh giá
- Công nghệ
- typescript
- Lĩnh vực
- accessibility, frontend
- Loại issue
- Lỗi
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức độ hoạt động
- Sôi nổi
- Độ rõ ràng
- Khá rõ ràng
- Mức phù hợp với người mới
- 72/100