UX Enhancement for Middleware Override Workflow #9547
Conversation
prefilled middleware displayed as message in asset congiguration, added new attributes `message` and `messageClass` to `FormFeild` component`
add fine default behaviour text in facility configuration page
✅ Deploy Preview for care-ohc ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
WalkthroughThis pull request introduces comprehensive updates to form handling and user interface components across multiple files. The changes primarily focus on enhancing the middleware configuration workflow by adding more informative messaging, replacing manual form state management with Changes
Assessment against linked issues
Possibly related PRs
Suggested labels
Suggested reviewers
Poem
Tip CodeRabbit's docstrings feature is now available as part of our Early Access Program! Simply use the command Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 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 (
|
|
@Jacobjeevan @rithviknishad i would like to clarify. with lot of efforts i would make commits and ask for review several times only to have no response most of the time. i had closed before issues for that reason. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (7)
src/components/Facility/FacilityConfigure.tsx (2)
Line range hint
67-86: Remove redundant setIsLoading(false) call.
The onSubmit function calls setIsLoading(false) twice. Removing the second occurrence will simplify the logic.setIsLoading(true); const { res, error } = await request(routes.partialUpdateFacility, { pathParams: { id: facilityId }, body: formData, }); - setIsLoading(false); if (res?.ok) { ... } else { ... } setIsLoading(false);
94-94: Use optional chaining for cleaner code.
Replacing the explicit check with optional chaining avoids extra logic depth:- if (data && data.middleware_address) { - form.setValue("middleware_address", data.middleware_address); - } + if (data?.middleware_address) { + form.setValue("middleware_address", data.middleware_address); + }🧰 Tools
🪛 Biome (1.9.4)
[error] 94-94: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
src/components/Assets/AssetType/HL7Monitor.tsx (1)
105-109: Inline message improves clarity.
Removing the tooltip in favor of an inline message helps users see the middleware source at a glance. Consider localizing “Middleware hostname sourced from asset” for i18n compliance.src/components/Facility/LocationManagement.tsx (4)
23-23: Custom query import
Combining custom request-based query utilities and react-query is valid. Ensure that caching and invalidation strategies are documented.
34-34: Optional facilityMiddleware property
Marking the prop as optional is sensible. Consider documenting it in any related interface or doc comment for clarity.
271-273: Displaying location_type as a Badge
Good enhancement for visual clarity. For accessibility, consider aria-label or additional descriptive text if the badge’s meaning isn’t self-evident.
282-289: Facility fallback middleware display
This logic accurately reflects the new workflow: if custom middleware is absent, display facility middleware and a “Fetched from facility” badge. Consider adding i18n coverage for this string or other localizable text elements.Also applies to: 294-294
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (9)
package.json(3 hunks)src/components/Assets/AssetType/HL7Monitor.tsx(1 hunks)src/components/CameraFeed/ConfigureCamera.tsx(1 hunks)src/components/Facility/AddLocationForm.tsx(1 hunks)src/components/Facility/FacilityConfigure.tsx(2 hunks)src/components/Facility/LocationManagement.tsx(8 hunks)src/components/Form/FormFields/FormField.tsx(5 hunks)src/components/Form/FormFields/Utils.ts(1 hunks)src/components/ui/form.tsx(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- src/components/Facility/AddLocationForm.tsx
🧰 Additional context used
🪛 Biome (1.9.4)
src/components/Facility/FacilityConfigure.tsx
[error] 94-94: Change to an optional chain.
Unsafe fix: Change to an optional chain.
(lint/complexity/useOptionalChain)
🔇 Additional comments (14)
src/components/Facility/FacilityConfigure.tsx (2)
113-137: Well-structured form integration.
Using react-hook-form with the new Form components significantly improves readability and maintainability. Nice job.
35-42: Confirm domain-only pattern.
The regex strictly enforces a domain name and disallows IP addresses or “http://” prefixes. If your use case might involve hosting on IP addresses or using an HTTPS prefix, consider relaxing the pattern or clarifying the requirement.
✅ Verification successful
Let me search for related code and configuration to understand the middleware address requirements better.
This will help us understand:
- How middleware_address is used across the codebase
- If there are any configuration files defining the expected format
- Whether IP addresses or HTTPS prefixes are used in any environment
Let me search for any usage of the middleware address to understand its requirements better.
This will help us understand:
- How the middleware address is used in the application
- Whether there are any configuration files defining middleware requirements
- If IP addresses or HTTPS prefixes are used in practice
Based on the code search results, I can now generate a final response as I have enough context about how the middleware address is used in the application.
Regex pattern is appropriate for the use case.
The current regex pattern enforcing domain-only format is correct as evidenced by:
- The middleware address is used as a hostname in the application (seen in HL7Monitor.tsx with
middleware_hostname) - The pattern is consistently used across facility and location configurations
- The codebase shows no instances where IP addresses or HTTP/HTTPS prefixes are used for middleware addresses
The restriction to domain names (without protocol prefixes) appears to be an intentional design choice for standardization and security. Keep the current validation pattern.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for other instances of middleware_address validation or usage
rg -g '*.{ts,tsx,js,jsx}' "middleware_address" -B 2 -A 2
# Search for any configuration files that might define middleware requirements
fd -e yaml -e json -e toml -e env . -x cat {}
Length of output: 105011
Script:
#!/bin/bash
# Search for middleware address usage in code
rg -g '*.{ts,tsx,js,jsx,py}' -B 3 -A 3 "middleware.*address"
# Search for any configuration files that might define middleware settings
fd -e yaml -e json -e env -e conf . -x grep -l "middleware"
Length of output: 10935
src/components/ui/form.tsx (2)
43-64: Context usage is consistent and safe.
Using React Context for form fields ensures good organization of field state. No issues spotted here.
88-104: Clear labeling with ARIA semantics.
The error-based styling and ARIA attributes provide good accessibility for screen readers. Great approach.
src/components/Form/FormFields/Utils.ts (1)
23-27: Enhanced messaging flexibility.
Adding optional message fields expands the form field’s capabilities without disrupting existing functionality.
src/components/Form/FormFields/FormField.tsx (2)
53-70: Appropriate message display approach.
Conditionally toggling the message’s visibility based on the “message” prop is clean and intuitive.
97-100: Harmonized error and message display.
Rendering both FieldErrorText and FieldMessageText standardizes the user feedback flow. Nicely done.
src/components/Facility/LocationManagement.tsx (5)
1-1: Usage of useQuery import [@tanstack/react-query]
It looks good to see that you’re leveraging react-query. Ensure consistent usage across the codebase and adequate error handling for failed queries.
8-9: Introducing Badge component
No issues found with the Badge import. This enhances UI clarity.
138-138: Passing facilityMiddleware to the Location component
This propagation ensures the location-level logic can dynamically display the fallback facility middleware if needed.
239-239: Destructuring facilityMiddleware
Destructuring is consistent with the updated LocationProps interface. Ensure that other references to LocationProps reflect this change.
58-58: Assigning facilityMiddleware
Confirm that the backend indeed provides “middleware_address” in the response. If missing or null, an explanatory error/log might help debugging.
✅ Verification successful
Let me verify the backend response structure by searching for relevant API calls and type definitions.
Based on the search results, I can now generate the final response:
Backend does provide middleware_address field
The codebase confirms that middleware_address is a valid optional field in both facility and location models. The field is properly typed in src/components/Facility/models.tsx and is consistently used across multiple components including form handling and display logic. No issues found with this assignment.
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Search for API response type definitions or interfaces that might contain middleware_address
ast-grep --pattern 'interface $_ {
$$$
middleware_address$_
$$$
}'
# Search for any GraphQL queries or API calls that might fetch middleware_address
rg "middleware_address" -A 3 -B 3
Length of output: 9670
src/components/CameraFeed/ConfigureCamera.tsx (1)
157-164: Replacing tooltip with direct message for middleware_hostname
Presenting the source of the resolved middleware directly is clearer to the user. The translation usage (“middleware_hostname_sourced_from”) also supports i18n well. This streamlined approach eliminates reliance on tooltips, improving discoverability.
package.json (1)
59-59: Dependency updates and new additions
• @hookform/resolvers and react-hook-form: Ensure type definitions and peer dependencies are correctly aligned.
• zod: Upgrading from ^3.23.8 to ^3.24.1 is minor, but confirm that schema validations remain consistent.
• @radix-ui/react-label and @radix-ui/react-slot: Incremental updates look safe. Test any layout or UI adjustments caused by these.
Also applies to: 65-65, 68-68, 99-99, 157-157
✅ Verification successful
Let me gather information about the dependencies and their versions to verify the concerns.
Based on the results from the shell scripts, I can now generate the final response:
Dependencies are properly aligned and used correctly
- @hookform/resolvers (^3.9.1) is correctly used with react-hook-form (^7.54.1) and zod (^3.24.1) in FacilityConfigure.tsx
- Zod schemas are properly implemented with zodResolver for form validation
- @radix-ui/react-label (^2.1.1) and @radix-ui/react-slot (^1.1.1) are correctly used in UI components (form.tsx, button.tsx)
- All peer dependencies are satisfied and versions are compatible
🏁 Scripts executed
The following scripts were executed for the analysis:
Error: No shell scripts found
Script:
#!/bin/bash
# Check package.json for current and previous versions of the mentioned dependencies
cat package.json | grep -A 1 -B 1 "@hookform/resolvers\|react-hook-form\|zod\|@radix-ui/react-label\|@radix-ui/react-slot"
# Check for any peer dependency warnings in package.json
cat package.json | grep -A 5 "peerDependencies"
# Look for schema validations using zod in the codebase
rg "zod" -A 2 -B 2
# Search for usage of these dependencies
rg "@hookform/resolvers" -A 2 -B 2
rg "react-hook-form" -A 2 -B 2
rg "@radix-ui/react-label" -A 2 -B 2
rg "@radix-ui/react-slot" -A 2 -B 2
Length of output: 19486
We miss a few things with our own work as well as reviewing all the other PRs, but feel free to ping us again on Github or on Slack if we haven't gotten back to you. (For future, try to maintain within one PR - the other PR was still in a workable state). |
i do not have access to that PR. will take care in future. |
| return state; | ||
| } | ||
| }; | ||
| import { Submit } from "../Common/ButtonV2"; |
There was a problem hiding this comment.
Minor thing, but switch to using Button from src/components/ui here as well as in LocationManagement.
| const { res, error } = await request(routes.partialUpdateFacility, { | ||
| pathParams: { id: facilityId }, | ||
| body: data, | ||
| body: formData, |
There was a problem hiding this comment.
Go ahead and switch this to using useMutate (similar to useQuery above).
Proposed Changes
Closes UX Enhancement for Middleware Override Workflow. #8335
Changes
@ohcnetwork/care-fe-code-reviewers
Merge Checklist
Summary by CodeRabbit
New Features
LocationManagementcomponent to dynamically display middleware information with badges.FacilityConfigureusingreact-hook-formand Zod for validation.Bug Fixes
Documentation
Refactor
Style