Add scheduled post published notification support#3327
Conversation
Greptile SummaryThis PR adds client support for scheduled-post-published notifications. The main changes are:
Confidence Score: 5/5This looks safe to merge.
Important Files Changed
Reviews (3): Last reviewed commit: "fix(i18n): fall back to English for untr..." | Re-trigger Greptile |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: d5c7c69819
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| /> | ||
| <SettingsItem | ||
| title={intl.formatMessage({ | ||
| id: 'settings.notification.scheduled_published', |
There was a problem hiding this comment.
Add fallbacks for scheduled notification copy
When the app locale is anything other than en-US, IntlProvider is initialized with only that locale's messages (src/index.tsx), and this commit adds the new scheduled-published strings only to en-US.json. This formatMessage call will therefore render the raw id for every other supported language; the foreground title/body ids added in this commit have the same issue. Please add the new keys to the other locale files, or provide defaultMessage fallbacks at each call site.
Useful? React with 👍 / 👎.
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThis PR adds scheduled_published notification handling across Redux state, migration logic, foreground display, notification routing, settings UI, locale strings, startup message fallback, and an SDK dependency update. ChangesScheduled Published Notification
SDK Dependency Update
Estimated code review effort: 3 (Moderate) | ~25 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
src/screens/application/hook/useInitApplication.tsx (1)
256-274: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low valueConsider folding into the existing identical case group.
The new
scheduled_publishedcase (Lines 256-264) has the exact same body as the adjacentfavorite/bookmark/replygroup (Lines 265-274). Consolidating via fallthrough avoids duplicating this logic a third time.♻️ Proposed consolidation
- case 'scheduled_published': - params = { - author: get(push, 'source', ''), - permlink: fullPermlink, - }; - key = fullPermlink; - routeName = ROUTES.SCREENS.POST; - break; - case 'favorite': case 'bookmark': case 'reply': + case 'scheduled_published': params = { author: get(push, 'source', ''), permlink: fullPermlink, }; key = fullPermlink; routeName = ROUTES.SCREENS.POST; break;🤖 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/screens/application/hook/useInitApplication.tsx` around lines 256 - 274, The new scheduled_published branch in useInitApplication duplicates the exact same params, key, and routeName assignment logic already handled by the adjacent favorite/bookmark/reply case group. Fold scheduled_published into that existing fallthrough block in the switch so the shared handling lives in one place and the duplicated body is removed.
🤖 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/screens/application/hook/useInitApplication.tsx`:
- Around line 256-274: The new scheduled_published branch in useInitApplication
duplicates the exact same params, key, and routeName assignment logic already
handled by the adjacent favorite/bookmark/reply case group. Fold
scheduled_published into that existing fallthrough block in the switch so the
shared handling lives in one place and the duplicated body is removed.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 0725a954-c3aa-4a7f-a3a1-629f9302bc21
📒 Files selected for processing (15)
src/components/foregroundNotification/foregroundNotification.tsxsrc/components/notificationLine/view/notificationLineView.tsxsrc/config/locales/en-US.jsonsrc/redux/actions/applicationActions.tssrc/redux/constants/constants.tssrc/redux/reducers/applicationReducer.tssrc/redux/store/store.tssrc/screens/application/container/applicationContainer.tsxsrc/screens/application/hook/useInitApplication.tsxsrc/screens/login/container/loginContainer.tsxsrc/screens/notification/container/notificationContainer.tsxsrc/screens/settings/container/settingsContainer.tsxsrc/screens/settings/screen/settingsScreen.tsxsrc/utils/migrationHelpers.test.tssrc/utils/migrationHelpers.ts
Client support for a new notification type (main_type 22, string
scheduled_published): the backend will notify authors when their scheduled post goes live. Safe to merge and release ahead of the backend; deployed apps re-register device preferences that include the new type, and the daemon starts only after clients ship.What
notificationDetailsshape forever and would never register the new type (autoMergeLevel1 does not merge new defaults). The migration also backfills the pre-existing missingbookmarkNotificationkey, fixed alongside in the reducer/typed shape.Notes
Summary by CodeRabbit