Conversation
trackError reports a plain error through ErrorModalService as
{ title: null }, and the title guard only covered undefined - null was
passed to t() and handed on to antd. antd renders its title slot for
every value that is not undefined or null, so those alerts came out with
an empty heading above the message, the icon aligned to the heading and
a row gap between the two: the icon sits clear of the text it belongs to.
A null title now falls back to the same default heading an omitted one
gets, so an error raised without its own title renders as the standard
error alert.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
🟢 Approved
The focused, backward-compatible fix covers every shared alert variant with regression tests.
Pull request overview
Fixes null alert titles so default headings render correctly and icons remain aligned.
Changes:
- Uses
isNilfor all alert variants. - Accepts nullable titles and adds focused regression tests.
Review: Fixes the root cause at the shared hook boundary, covers all variants, and remains backward compatible. No documentation update is needed; remaining risk is minimal.
File summaries
| File | Description |
|---|---|
use-alert-modal.tsx |
Normalizes nullish titles to alert defaults. |
use-alert-modal.test.tsx |
Tests custom and null-title behavior. |
Review details
- Files reviewed: 2/2 changed files
- Comments generated: 0
- Review effort level: Balanced
💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
7 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.



Changes in this pull request
Every alert raised through
trackErrorwithout its own title renders with the icon sitting clear of the message it belongs to:The cause is a
nullthat slips past the title guard.trackError's default path hands the error toErrorModalService, which reports a plain (non-API) error as{ title: null }— it has no title to give.useAlertModalonly guarded againstundefined:so
nulltook the first branch, went throught(), and reached antd as a defined title. antd renders its title slot for any value that is notundefinedornull(hasTitle = props.title !== undefined && props.title !== null), so the dialog gets:.ant-modal-confirm-titleabove the message,.ant-modal-confirm-body-has-title, which aligns the icon to that empty heading rather than to the text,rowGapbetween the empty heading and the message.The icon ends up a row above the first line of text. An error raised with a title — every
ApiError— was unaffected, which is why the standard error alerts look right and only the plain ones do not.The guard now uses
isNil, so anulltitle falls back to the same default heading an omitted one already gets. Applied to all four kinds (info,error,warn,success) since they share the pattern, andtitleis typedstring | nullto match what callers actually pass.Additional info
No call site changes: everything that already passed a title behaves exactly as before, and this is the path
trackErrorhas always taken.Covered by
use-alert-modal.test.tsx— the null-title cases fail against the old guard and pass against the new one.Found while looking at plain
GeneralErroralerts in the backend power tools bundle, where every one of the 19 call sites hits this path.🤖 Generated with Claude Code