Skip to content

Refresh views when an entry is logged from anywhere in the app - #287

Merged
mike12806 merged 1 commit into
mainfrom
claude/main-screen-refresh-feeding-gsuswr
Aug 4, 2026
Merged

Refresh views when an entry is logged from anywhere in the app#287
mike12806 merged 1 commit into
mainfrom
claude/main-screen-refresh-feeding-gsuswr

Conversation

@mike12806

Copy link
Copy Markdown
Owner

Problem

Logging a feeding (or anything else) from the bottom-nav FAB while on the main screen didn't update the dashboard — the new entry only appeared after a manual page reload.

Layout renders its own QuickLogDialog for the FAB sheet, outside the routed page, and never passed an onLogged callback. The dashboard's reloadAll was only reachable from the dialog the dashboard itself renders (the tile grid), so the FAB path had no way to tell the page underneath that data had changed.

Changes

  • New DataRefreshProvider / useDataRefresh hook (client/src/hooks/useDataRefresh.tsx) exposing a refreshKey counter and a refreshData() signal, mounted in App.tsx inside ChildProvider.
  • QuickLogDialog calls refreshData() itself after a successful save, so every mount point benefits rather than each caller having to wire up a callback. The existing onLogged prop still works.
  • Views refetch on refreshKey: Dashboard, Feedings, Diapers, Sleep, Tummy Time, Pumping, Notes, Activity and Charts add it to their load effect dependencies — so the FAB now updates whichever screen is behind it, not just the dashboard.
  • Refresh on return to the app: the provider also bumps the key on visibilitychange/focus (throttled to 2s, since both fire when returning to a tab), so the installed PWA picks up entries logged on another device instead of showing stale cards after sitting in the background.
  • Dashboard fetch hardening: the load moved into the effect with a cancellation guard, so a slow in-flight request can't overwrite newer data when the key bumps again, and load failures now surface a notification instead of an unhandled rejection.

Testing

  • New client/test/DataRefresh.test.tsx (4 tests) reproduces the bug: a QuickLogDialog rendered as a sibling of the dashboard (mirroring Layout) triggers a refetch on save, doesn't refetch on cancel, refetches on visibilitychange, and doesn't double-fetch when visibilitychange and focus both fire.
  • client/test/Dashboard.test.tsx now wraps in DataRefreshProvider and asserts refetch counts — the previous assertions passed on the initial mount fetch alone and would not have caught this.
  • npm test -w client — 63 passed (9 files). npm test -w server — 70 passed. npm run build -w client clean.

Generated by Claude Code

Logging from the bottom-nav FAB never updated the screen underneath.
Layout renders its own QuickLogDialog outside the routed page and passed
no onLogged callback, so a feeding saved from the main screen didn't show
up until a manual reload.

Add a DataRefreshProvider exposing a refreshKey/refreshData pair.
QuickLogDialog bumps the key itself after a successful save, so every
mount point benefits, and the Dashboard plus the entry list, activity and
charts pages refetch on that key. The provider also bumps on
visibilitychange/focus (throttled) so returning to the installed PWA picks
up entries logged on another device.

The Dashboard fetch moves into the effect with a cancellation guard so an
in-flight load can't overwrite newer data, and now surfaces load errors.

Co-Authored-By: Claude Opus 5 <[email protected]>
Claude-Session: https://claude.ai/code/session_019DSiaPu62P8nPww2vhF3zf
@mike12806
mike12806 marked this pull request as ready for review August 4, 2026 17:46
@mike12806
mike12806 merged commit ac6b762 into main Aug 4, 2026
6 checks passed
@mike12806
mike12806 deleted the claude/main-screen-refresh-feeding-gsuswr branch August 4, 2026 17:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants