fix(uxcore): keep the new-update modal closed for the session once di…

[MaryWylde]

…smissed

Dismissal is stored in sessionStorage keyed to the CMS updatedAt, so a newly published update still shows once while the same one stays hidden across reloads and locale switches.

[github-actions]

Claude finished @MaryWylde's task in 2m 11s —— View job

---

Reviewing PR #168

• Gather context (diff, related files)
• Understand the request
• Review correctness / React best practices / SSR safety
• Review TypeScript quality
• Review project conventions (AGENTS.md)
• Review accessibility / security / styling
• Post findings

Summary

Clean, minimal fix. sessionStorage access is correctly scoped — the read happens inside a useEffect (client-only), and the write happens inside a click handler (handleClose) — so there's no SSR/hydration risk. The dismissal key correctly incorporates res.updatedAt, matching the PR's stated goal of showing a newly-published update once while keeping a previously-dismissed one hidden across reloads and locale switches.

I initially suspected the import reorder in NewUpdateModal.tsx (moving @uxcore/components/* above next/image/react) broke the documented AGENTS.md import order, but checked eslint.config.mjs: the simple-import-sort group for third-party (^@?\w) also matches @uxcore/... (no dedicated @uxcore group exists), and @ sorts before lowercase letters — so alphabetically @uxcore/components/Button before next/image is what the linter would actually produce. Not a violation.

Two minor, non-blocking observations:

1. NewUpdateModalContainer.tsx:29 — sessionStorage.getItem(...) isn't wrapped in its own try, but it does fall inside the outer try { ... } catch (err) { console.warn('[new-update] fetch failed:', err) } (lines 20–43), so a storage-access exception (e.g. Safari private mode with storage disabled) is still caught — just logged with a slightly misleading "fetch failed" message. Cosmetic only.
2. Fallback key 'seen' (res.updatedAt ?? 'seen') — if the CMS entry is ever missing updatedAt, dismissing once will suppress any future update lacking updatedAt for the rest of the session, since they'd all collide on the same fallback key. Strapi populates updatedAt by default on every content type via populate=*, so this is a very low-risk theoretical edge case, not a practical bug.

No correctness, security, accessibility, or convention issues found. Approving of the approach as implemented.