feat: general requirements (user-friendly error display) - #62
Conversation
* feat: install next+ts+linter+prettier+ husky+redux * feat: configs + perfectionist + lint fix * feat: install scss * refactor: add some folders * feat: install i18n + basic configs * feat: add internatiolisation * feat: language switcher * feat: dependencies update * fix: delete scss + delete unnecessary files * fix: delete unnecessary layout
* feat: add error page component * test: add tests for error page component * feat: add global error page component * test: add tests for global error page component * feat: implement toast provider and toast component * test: add tests for toast provider and toast component * feat: add toaster messages dictionary * chore: add coderabbit config * fix: fix .coderabbit.yaml instruction * fix: add target branches for review to instructions * fix: move console.error into useEffect * fix: ignore clickaway on close * test: add test for onClose on clickaway * fix: memoize showToast and context value with useCallback/useMemo
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
✅ Files skipped from review due to trivial changes (1)
📝 WalkthroughWalkthroughThis PR adds locale and global error pages, a toast notification provider and component, a sticky header with layout wiring, expanded English/Russian messages, and updated app dependencies and tooling. ChangesUser-friendly errors and supporting UI/i18n
Estimated code review effort: 3 (Moderate) | ~30 minutes Sequence Diagram(s)sequenceDiagram
participant App
participant ErrorPage
participant GlobalError
participant ErrorCard
participant unstable_retry
App->>ErrorPage: render locale error
App->>GlobalError: render fatal error
ErrorPage->>ErrorCard: title, description, retry button text
GlobalError->>ErrorCard: title, description, button text
ErrorCard->>unstable_retry: retry click
sequenceDiagram
participant Component
participant useToast
participant ToastProvider
participant Toast
Component->>useToast: showToast(message, severity)
useToast->>ToastProvider: update provider state
ToastProvider->>Toast: render Snackbar + Alert
Toast-->>Component: close or auto-hide
Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.github.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Nitpick comments (6)
src/providers/toast-provider/ToastProvider.tsx (1)
21-49: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winConsecutive
showToastcalls will abruptly swap content instead of properly transitioning.The provider holds a single
toaststate object withopenstayingtrueacross successiveshowToastcalls (e.g., a "save failed" toast quickly followed by a "sign-out succeeded" toast, both mentioned in the linked issue's use cases). Sinceopennever toggles tofalsein between, the Snackbar/Alert won't exit/re-enter — the message and severity just swap in place without giving the user a chance to notice the first toast, and MUI's own autoHideDuration timer handling for such "stacked" invocations is not guaranteed to reset cleanly.MUI's official Snackbar docs recommend a queuing approach: close the current snackbar first, then set the next message once
onExitedfires (or track a queue and only update the visible message when the previous one has exited).♻️ Suggested consecutive-snackbar pattern (per MUI docs)
- const showToast = useCallback((message: string, severity: ToastType = 'success') => { - setToast({ message, open: true, severity }); - }, []); + const [queue, setQueue] = useState<ToastState[]>([]); + + const showToast = useCallback((message: string, severity: ToastType = 'success') => { + setQueue((prev) => [...prev, { message, open: true, severity }]); + }, []); + + useEffect(() => { + if (queue.length && !toast.open) { + setToast(queue[0]); + setQueue((prev) => prev.slice(1)); + } else if (queue.length && toast.open) { + setToast((prev) => ({ ...prev, open: false })); + } + }, [queue, toast.open]);This is only a real problem if the app can trigger back-to-back toasts (likely, given the many toast triggers listed in the issue). Given the multiple simultaneous non-critical error/success scenarios described in the PR (save failures, sign-in/out, history load errors, cURL copy), consecutive toasts seem plausible.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/providers/toast-provider/ToastProvider.tsx` around lines 21 - 49, The ToastProvider currently overwrites a single visible toast in place, so consecutive showToast calls skip the exit/enter transition and can confuse MUI Snackbar timing. Update ToastProvider to queue or stage toasts instead of replacing toast state immediately: when showToast is called while a toast is open, close the current Toast first and only apply the next message/severity after the previous one has fully exited (using Toast’s onExited or equivalent). Keep the fix centered around the showToast, handleClose, and ToastContext.Provider flow so back-to-back notifications transition cleanly.src/i18n/messages/en.json (1)
38-38: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winRemove leftover debug key.
"check": "check english"at the root isn't part of any namespace used bygenerateMetadata,Header,HomePage,errorPage, ortoaster. Looks like a leftover debug/test artifact.🧹 Proposed removal
"historyLoadError": "Failed to load request history" - }, - "check": "check english" + } }🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/i18n/messages/en.json` at line 38, Remove the leftover debug translation entry from the root of the English messages file. The key "check" is not used by generateMetadata, Header, HomePage, errorPage, or toaster, so delete it from the messages object and keep only the namespace keys that are actually consumed by the app.src/app/[locale]/layout.tsx (1)
33-48: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winConsider validating
localebefore use.
localefromparamsisn't checked againstrouting.locales. next-intl's setup guide recommends guarding withhasLocale+notFound()in the locale layout, since[locale]is a catch-all segment.🛡️ Proposed guard
+import { hasLocale } from 'next-intl'; +import { notFound } from 'next/navigation'; + +import { routing } from '`@/i18n/routing`'; + export default async function RootLayout({ children, params }: Props) { const { locale } = await params; + + if (!hasLocale(routing.locales, locale)) { + notFound(); + } return (🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/app/`[locale]/layout.tsx around lines 33 - 48, The RootLayout in next-intl locale handling uses params.locale directly without validating it, so add a locale guard before rendering. In RootLayout, check the awaited locale against routing.locales with hasLocale and call notFound() for invalid values, then continue rendering with the validated locale passed into NextIntlClientProvider and html lang.src/components/language-switcher/language-switcher.tsx (2)
18-24: 🚀 Performance & Scalability | 🔵 Trivial | 💤 Low valueConsider wrapping the locale switch in a transition for pending UI feedback.
Other next-intl locale-switcher implementations wrap
router.replaceinstartTransitionso the UI can show a pending state while the new locale's segment loads. Not required, but improves perceived responsiveness on slower navigations.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/components/language-switcher/language-switcher.tsx` around lines 18 - 24, The locale switch handler in handleChange currently calls router.replace directly, so the UI cannot reflect a pending navigation state. Update the language-switcher component to wrap the locale change in startTransition around router.replace, and use the transition state to support pending feedback while the new locale loads.
27-46: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winSelect is missing an accessible name.
The
Selecthas noInputLabel/labelIdpairing and noaria-label, so screen reader users get no context that this control switches the site language.♿ Proposed fix
<Select className={styles.select} + inputProps={{ 'aria-label': 'Select language' }} MenuProps={{Per MUI's docs, "Select always needs an accessible name," obtainable via an associated label or
aria-labeloninputProps.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/components/language-switcher/language-switcher.tsx` around lines 27 - 46, The Select in language-switcher.tsx is missing an accessible name, so update the language switcher control to provide one by either adding an InputLabel/labelId pairing or setting an aria-label on the Select. Keep the change within the LanguageSwitcher component and ensure the existing Select, FormControl, and MenuItem structure still works with the new accessible naming.src/app/global-error.tsx (1)
47-55: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueFallback error text is hardcoded (not localized).
Unlike the locale
error.tsx, this component doesn't usenext-intltranslations. This is likely intentional/necessary sinceglobal-error.tsxreplaces the root layout and loses access to context providers set up there, but it does mean non-English users see English text on the rare occasion this boundary triggers.If localizing this fallback is desired, next-intl docs note global-error can still be used with i18n, though it requires wiring up its own message loading independent of the removed root layout.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/app/global-error.tsx` around lines 47 - 55, The fallback UI in globalError is hardcoded in English, unlike the localized error screen elsewhere. If localization is desired, update the GlobalError component to load messages independently of the root layout and use next-intl translations for the heading, body, and retry label; otherwise keep the current behavior as an intentional non-localized fallback.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@package.json`:
- Around line 37-38: The React package versions are duplicated across manifest
sections and currently conflict, so npm may resolve the older devDependencies
pin instead of the intended one. Update the package.json entries for react and
react-dom so the versions match exactly in both dependencies and
devDependencies, or remove the duplicate devDependencies entries entirely,
keeping the manifest consistent.
In `@src/app/`[locale]/page.tsx:
- Around line 6-11: The home page is still rendering the leftover debug
translation key instead of the real HomePage copy. Update the page component in
the default locale route to use the existing HomePage.title and
HomePage.description translations from getTranslations() rather than t('check'),
and ensure the rendered markup reflects the HomePage section instead of the
placeholder string.
In `@src/i18n/messages/ru.json`:
- Line 38: Remove the leftover debug translation entry from the ru messages
file: the standalone "check" key with the test string is not a real UI message.
Update the Messages object in messages/ru.json to keep only the intended
HomePage-related keys, and ensure any code using this translation continues to
reference the existing HomePage message symbols rather than the debug key.
---
Nitpick comments:
In `@src/app/`[locale]/layout.tsx:
- Around line 33-48: The RootLayout in next-intl locale handling uses
params.locale directly without validating it, so add a locale guard before
rendering. In RootLayout, check the awaited locale against routing.locales with
hasLocale and call notFound() for invalid values, then continue rendering with
the validated locale passed into NextIntlClientProvider and html lang.
In `@src/app/global-error.tsx`:
- Around line 47-55: The fallback UI in globalError is hardcoded in English,
unlike the localized error screen elsewhere. If localization is desired, update
the GlobalError component to load messages independently of the root layout and
use next-intl translations for the heading, body, and retry label; otherwise
keep the current behavior as an intentional non-localized fallback.
In `@src/components/language-switcher/language-switcher.tsx`:
- Around line 18-24: The locale switch handler in handleChange currently calls
router.replace directly, so the UI cannot reflect a pending navigation state.
Update the language-switcher component to wrap the locale change in
startTransition around router.replace, and use the transition state to support
pending feedback while the new locale loads.
- Around line 27-46: The Select in language-switcher.tsx is missing an
accessible name, so update the language switcher control to provide one by
either adding an InputLabel/labelId pairing or setting an aria-label on the
Select. Keep the change within the LanguageSwitcher component and ensure the
existing Select, FormControl, and MenuItem structure still works with the new
accessible naming.
In `@src/i18n/messages/en.json`:
- Line 38: Remove the leftover debug translation entry from the root of the
English messages file. The key "check" is not used by generateMetadata, Header,
HomePage, errorPage, or toaster, so delete it from the messages object and keep
only the namespace keys that are actually consumed by the app.
In `@src/providers/toast-provider/ToastProvider.tsx`:
- Around line 21-49: The ToastProvider currently overwrites a single visible
toast in place, so consecutive showToast calls skip the exit/enter transition
and can confuse MUI Snackbar timing. Update ToastProvider to queue or stage
toasts instead of replacing toast state immediately: when showToast is called
while a toast is open, close the current Toast first and only apply the next
message/severity after the previous one has fully exited (using Toast’s onExited
or equivalent). Keep the fix centered around the showToast, handleClose, and
ToastContext.Provider flow so back-to-back notifications transition cleanly.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 671edccb-b96f-4e63-b5fa-52f4038b55d9
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (29)
.coderabbit.yamlAGENTS.mdCLAUDE.mdnext.config.tspackage.jsonsrc/app/[locale]/error.test.tsxsrc/app/[locale]/error.tsxsrc/app/[locale]/layout.tsxsrc/app/[locale]/page.module.csssrc/app/[locale]/page.tsxsrc/app/global-error.test.tsxsrc/app/global-error.tsxsrc/app/layout.tsxsrc/app/page.tsxsrc/components/header/header.tsxsrc/components/index.tssrc/components/language-switcher/language-switcher.module.csssrc/components/language-switcher/language-switcher.tsxsrc/i18n/messages/en.jsonsrc/i18n/messages/ru.jsonsrc/i18n/navigation.tssrc/i18n/request.tssrc/i18n/routing.tssrc/providers/toast-provider/Toast.test.tsxsrc/providers/toast-provider/Toast.tsxsrc/providers/toast-provider/ToastProvider.test.tsxsrc/providers/toast-provider/ToastProvider.tsxsrc/providers/toast-provider/types.tssrc/proxy.ts
💤 Files with no reviewable changes (2)
- src/app/layout.tsx
- src/app/page.tsx
|
|
||
| &:hover { | ||
| :global(.MuiOutlinedInput-notchedOutline) { | ||
| border-color: rgb(192 132 252 / 75%) !important; |
There was a problem hiding this comment.
цвета б конечно в палитру записать и юзать ограниченное их кол-во
There was a problem hiding this comment.
будет тема из хедер-ветки
…lyaEngineer/swagger-editor-app into feature/7-general-requirements
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
src/components/header/header.tsx (1)
41-53: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winMixing
styleandsxfor related transitions is inconsistent.
minHeightand its transition are set via the inlinestyleprop, whilepyand its transition usesx. Consolidating both intosx(ortheme.transitions.create(['padding', 'min-height'], ...)) would be more idiomatic MUI usage and easier to maintain/theme.♻️ Suggested consolidation
<Toolbar - style={{ - minHeight, - transition: 'min-height 200ms', - }} sx={{ + minHeight, py, transition: (theme) => - theme.transitions.create(['padding'], { + theme.transitions.create(['padding', 'min-height'], { duration: theme.transitions.duration.short, }), }} >🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/components/header/header.tsx` around lines 41 - 53, The Toolbar styling is split between inline style and sx for related layout transitions, which is inconsistent. Update the Header Toolbar in header.tsx so both minHeight and py-related transition behavior are handled in sx using the theme object, keeping the transition definitions together with theme.transitions.create and removing the inline style prop for these shared styles.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/components/header/header.tsx`:
- Around line 33-40: The AppBar styling in header should not rely on borderColor
alone, since it won’t render without an actual border. Update the AppBar sx in
header.tsx to add a visible bottom border/divider (for example via borderBottom
or borderBottomWidth with a border style) while keeping the existing
backgroundColor and sticky behavior.
---
Nitpick comments:
In `@src/components/header/header.tsx`:
- Around line 41-53: The Toolbar styling is split between inline style and sx
for related layout transitions, which is inconsistent. Update the Header Toolbar
in header.tsx so both minHeight and py-related transition behavior are handled
in sx using the theme object, keeping the transition definitions together with
theme.transitions.create and removing the inline style prop for these shared
styles.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: a48dff04-364c-49cc-96e4-9eeaa7d92fd0
📒 Files selected for processing (7)
src/app/[locale]/error.tsxsrc/app/global-error.tsxsrc/components/error-card/error-card.tsxsrc/components/header/header.tsxsrc/i18n/messages/en.jsonsrc/i18n/messages/ru.jsonsrc/providers/mui-provider.tsx
✅ Files skipped from review due to trivial changes (2)
- src/i18n/messages/en.json
- src/i18n/messages/ru.json
🚧 Files skipped from review as they are similar to previous changes (1)
- src/app/global-error.tsx
There was a problem hiding this comment.
Caution
Inline review comments failed to post. This is likely due to GitHub's internal server error or limits when posting large numbers of comments. If you are seeing this consistently it is likely a permissions issue. Please check "Moderation" -> "Code review limits" under your organization settings.
Actionable comments posted: 1
🧹 Nitpick comments (1)
src/components/header/header.tsx (1)
41-53: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winMixing
styleandsxfor related transitions is inconsistent.
minHeightand its transition are set via the inlinestyleprop, whilepyand its transition usesx. Consolidating both intosx(ortheme.transitions.create(['padding', 'min-height'], ...)) would be more idiomatic MUI usage and easier to maintain/theme.♻️ Suggested consolidation
<Toolbar - style={{ - minHeight, - transition: 'min-height 200ms', - }} sx={{ + minHeight, py, transition: (theme) => - theme.transitions.create(['padding'], { + theme.transitions.create(['padding', 'min-height'], { duration: theme.transitions.duration.short, }), }} >🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/components/header/header.tsx` around lines 41 - 53, The Toolbar styling is split between inline style and sx for related layout transitions, which is inconsistent. Update the Header Toolbar in header.tsx so both minHeight and py-related transition behavior are handled in sx using the theme object, keeping the transition definitions together with theme.transitions.create and removing the inline style prop for these shared styles.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/components/header/header.tsx`:
- Around line 33-40: The AppBar styling in header should not rely on borderColor
alone, since it won’t render without an actual border. Update the AppBar sx in
header.tsx to add a visible bottom border/divider (for example via borderBottom
or borderBottomWidth with a border style) while keeping the existing
backgroundColor and sticky behavior.
---
Nitpick comments:
In `@src/components/header/header.tsx`:
- Around line 41-53: The Toolbar styling is split between inline style and sx
for related layout transitions, which is inconsistent. Update the Header Toolbar
in header.tsx so both minHeight and py-related transition behavior are handled
in sx using the theme object, keeping the transition definitions together with
theme.transitions.create and removing the inline style prop for these shared
styles.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: a48dff04-364c-49cc-96e4-9eeaa7d92fd0
📒 Files selected for processing (7)
src/app/[locale]/error.tsxsrc/app/global-error.tsxsrc/components/error-card/error-card.tsxsrc/components/header/header.tsxsrc/i18n/messages/en.jsonsrc/i18n/messages/ru.jsonsrc/providers/mui-provider.tsx
✅ Files skipped from review due to trivial changes (2)
- src/i18n/messages/en.json
- src/i18n/messages/ru.json
🚧 Files skipped from review as they are similar to previous changes (1)
- src/app/global-error.tsx
🛑 Comments failed to post (1)
src/components/header/header.tsx (1)
33-40: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
borderColor: 'divider'has no visible effect without a border width/style.The AppBar doesn't set
border,borderWidth, orborderStyle, soborderColor: 'divider'is dead CSS — no border will render. If the intent is a bottom divider under the sticky header, addborderBottom/borderBottomWidth.🎨 Proposed fix
sx={{ backgroundColor: 'background.paper', - borderColor: 'divider', + borderBottom: 1, + borderColor: 'divider', }}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.<AppBar elevation={0} position="sticky" sx={{ backgroundColor: 'background.paper', borderBottom: 1, borderColor: 'divider', }} >🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/components/header/header.tsx` around lines 33 - 40, The AppBar styling in header should not rely on borderColor alone, since it won’t render without an actual border. Update the AppBar sx in header.tsx to add a visible bottom border/divider (for example via borderBottom or borderBottomWidth with a border style) while keeping the existing backgroundColor and sticky behavior.
There was a problem hiding this comment.
🧹 Nitpick comments (1)
src/app/[locale]/layout.tsx (1)
49-53: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winConsider wrapping
{children}in a<main>landmark.
Header/Footersandwich{children}directly without a semantic<main>element, which affects accessibility landmark navigation.♻️ Proposed fix
<MuiProvider> <Header /> - {children} + <main>{children}</main> <Footer /> </MuiProvider>🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/app/`[locale]/layout.tsx around lines 49 - 53, Wrap the routed page content rendered by the layout in a semantic <main> landmark so accessibility tools can identify the primary content area. Update the layout component that composes MuiProvider, Header, Footer, and {children} to place {children} inside a <main> element, keeping Header and Footer outside that landmark.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@src/app/`[locale]/layout.tsx:
- Around line 49-53: Wrap the routed page content rendered by the layout in a
semantic <main> landmark so accessibility tools can identify the primary content
area. Update the layout component that composes MuiProvider, Header, Footer, and
{children} to place {children} inside a <main> element, keeping Header and
Footer outside that landmark.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 72e86b96-a581-490c-81c5-5cb932ccdd89
📒 Files selected for processing (6)
src/app/[locale]/error.tsxsrc/app/[locale]/layout.tsxsrc/app/[locale]/page.tsxsrc/app/global-error.tsxsrc/components/error-card/error-card.tsxsrc/components/index.ts
💤 Files with no reviewable changes (1)
- src/app/[locale]/page.tsx
✅ Files skipped from review due to trivial changes (1)
- src/components/index.ts
🚧 Files skipped from review as they are similar to previous changes (3)
- src/components/error-card/error-card.tsx
- src/app/global-error.tsx
- src/app/[locale]/error.tsx
4 participants
Summary
Implements User-friendly error display from Feature 7 (General Requirements). Language switching and sticky header items also originated in this branch but were finalized in feature/1-app-header (already pending merge to develop) - so this PR effectively only brings in error handling.
Changes Made
Related issue
Closes #10
Feature
Feature 7: General Requirements
Acceptance criteria
Feature 1: App Header
Feature 2: Sign In / Sign Up
Feature 3: Swagger Editor
Feature 4: Swagger Viewer
Feature 5: History and Analytics
Feature 6: About Page
Feature 7: General Requirements
Feature 8: YouTube Video
Type of change
Checklist
any/@ts-ignoreHow to test
error.tsxAdd
TriggerErrorButtoncomponent to the project and import it insrc/app/[locale]/page.tsx. Clicking the button throws an error, which triggers the nearest error.tsx UIglobal-error.tsxAdd
.env.localto the project root with the variable NEXT_PUBLIC_TEST_GLOBAL_ERROR=true. Then add a conditional throw in the body of RootLayout (src/app/[locale]/layout.tsx):Restart the dev server (Next.js only reads .env.local on startup). The app should fail to render entirely and fall back to global-error.tsx (unstyled, since theme and i18n providers are unavailable at this level by Next.js design).
Temporary component
TriggerToastButton(src/components/trigger-toast-button/trigger-toast-button.tsx) lets you pick a severity and trigger a toast via useToast(). Add temporarily to any page (e.g. the main page).Screenshots
globai-error.tsxerror.tsxwith i18nsuccess toast
error toast
Summary by CodeRabbit
Summary