fix: #11090 improve mobile experience for questionnaire errors #11091
Conversation
…ve collapsible component and always show validation errors
WalkthroughThis pull request enhances error handling and type definitions across the application. In the questionnaire form component, it adds a new server validation error interface, renames an existing interface for clarity, and integrates a ValidationErrorDisplay component to show errors. In the batch processing types, it updates interfaces to include additional error details and refines response union types. Changes
Sequence Diagram(s)sequenceDiagram
participant U as User
participant QF as QuestionnaireForm
participant S as Server
participant V as ValidationErrorDisplay
U->>+QF: Submit Form
QF->>+S: Send Request
S-->>-QF: Response (status_code, error data)
alt Error Detected
QF->>QF: Filter non-200 responses
QF->>+V: Pass serverErrors data
V-->>-QF: Render error messages
else Success
QF->>QF: Process valid response
end
Suggested labels
Suggested reviewers
Poem
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Deploying care-fe with
|
| Latest commit: |
d1d487b
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://65798b6a.care-fe.pages.dev |
| Branch Preview URL: | https://fix-11090-questionnaire-mobi.care-fe.pages.dev |
✅ Deploy Preview for care-ohc ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
@amjithtitus09 I am merging this as a temp fix |
✅ Deploy Preview for care-ohc ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
@bodhish Your efforts have helped advance digital healthcare and TeleICU systems. 🚀 Thank you for taking the time out to make CARE better. We hope you continue to innovate and contribute; your impact is immense! 🙌 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (17)
src/components/Questionnaire/QuestionnaireForm.tsx (8)
45-50: Leverage specific HTTP method type instead of string.
Declaringmethodas a plainstringmay reduce type safety. Consider using a more specific type (e.g., a union of allowed HTTP verbs) to catch typos and invalid methods at compile-time.interface FormBatchRequest { url: string; - method: string; + method: "GET" | "POST" | "PUT" | "PATCH" | "DELETE"; body: Record<string, any>; reference_id: string; }
52-56: Add doc comments for clarity.
Though straightforward, adding minimal doc comments (JSDoc/TSDoc) for each property inServerValidationErrorcan help future contributors quickly understand the error fields.
68-71: Optionally enforce strictness on props.
HavingserverErrorsoptional is fine, but consider whether defaulting to an empty array would simplify usage by reducing the need to check forundefined.
73-83: Extract smaller helper utilities.
TheValidationErrorDisplaycomponent is large and includes multiple helper functions. Splitting utility functions (e.g.,findQuestionText) into smaller, more testable units could improve readability and maintainability.
132-274: Remove repeated scroll/visual highlight logic.
Scrolling and highlighting are repeated in multiple places for both server-level and form-level errors. Abstracting these steps into a shared helper function would reduce duplication and simplify future changes.- // Scrolling logic repeated in lines 167–200 & 232–264 + // Suggest using a helper like scrollToQuestion(questionId)
289-289: Consider initializing with an empty array.
Using[ ]as the default value forserverErrorsinstead ofundefinedcan simplify checks and reduce the likelihood of null/undefined references.
310-310: Use empty array instead of undefined for consistency.
Similarly here, settingserverErrorsto[]might be more consistent thanundefinedif all calling code expects an array.
315-383: Refactor large error-processing block.
This block of error parsing, mapping, and server error extraction is quite extensive. Extracting it into a dedicated function or custom hook (e.g.,useServerErrorHandler) could reduce complexity within this component and ease maintenance.src/types/questionnaire/batch.ts (9)
16-22: Add doc comments for clarity.
QuestionValidationErrorwould benefit from short descriptions on each field to help new contributors understand how these properties interplay in validation scenarios.
24-31: Consider a more descriptive name for ctx.
ctxis flexible but somewhat vague. Clarifying its content in documentation or renaming it (e.g.,contextData) may help readability.
33-42: Maintain consistent naming.
BatchRequestErrorproperties such asmsganderroroverlap in meaning. Consider merging or clarifying them to avoid ambiguity.
55-61: Restrict HTTP methods if possible.
Like inFormBatchRequest, yourBatchRequestcould also use a union of string literal types formethodto reduce possible runtime errors from incorrect method strings.
63-65: Use more explicit naming.
TheBatchErrorDataname is fine, but a doc comment indicating that this interface holds an array ofBatchRequestErrorclarifies usage.
67-70: Tag base fields with doc comments.
BatchResponseBaseis frequently extended. Adding short doc comments forreference_idandstatus_codecan improve readability and serve as a quick reference for future maintainers.
72-74: Validatedatashape forBatchErrorResponse.
Consider whetherStructuredDataError[]might need a more precise type (e.g., each item also guaranteeing certain fields). This could strengthen type-safety.
81-86: Markerrorsas optional if partial failures are possible.
In some scenarios, the response might contain additional data even when there's only a warning, but no full error. If partial error states occur, updating the interface accordingly can prevent confusion.
88-93: Unify or consolidate union types.
Consider mergingBatchResponseResult,BatchRequestResult, andBatchResponseto ensure you don’t have overlapping definitions. This can help maintain a single source of truth.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
src/components/Questionnaire/QuestionnaireForm.tsx(6 hunks)src/types/questionnaire/batch.ts(2 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (5)
- GitHub Check: Redirect rules - care-ohc
- GitHub Check: Header rules - care-ohc
- GitHub Check: Pages changed - care-ohc
- GitHub Check: cypress-run (1)
- GitHub Check: Cloudflare Pages: care-fe
🔇 Additional comments (5)
src/components/Questionnaire/QuestionnaireForm.tsx (2)
557-557: Initialization is straightforward.
Using a typed array for storing requests is fine. No further action needed here.
819-823: Placement of ValidationErrorDisplay is effective.
RenderingValidationErrorDisplayafter the questionnaire forms is logical. It ensures all form data and errors are collected before displaying them.src/types/questionnaire/batch.ts (3)
2-3: Ensure alignment with server definitions.
reference_idanddataare fundamental fields. Confirm that the server’s response always provides these fields. Ifdatacan be empty or missing, the?is correct; otherwise, consider removing the optional to enforce data presence.
44-53: StructuredDataError structure looks consistent.
Ensure each nested error object consistently matches the shape expected by validating code. No immediate concerns here.
76-78: Check for potential empty success response.
Ifdatamight be empty or null, consider marking it optional or handle it in your application logic so you don’t rely on a missing property.
Fixes #11090
Summary by CodeRabbit