refactor(client): inline UserProvider.queryPreference subscribe/getSnapshot#40491
refactor(client): inline UserProvider.queryPreference subscribe/getSnapshot#40491ggazzo wants to merge 1 commit into
Conversation
…apshot
queryPreference was the last context value in UserProvider going through
createReactiveSubscriptionFactory — i.e., through Tracker.autorun.
getUserPreference reads two sources:
- Users.use.getState() (zustand, non-reactive)
- settings.watch(`Accounts_Default_User_Preferences_${key}`) as a fallback
when the user record has no override
Replace the factory call with a hand-rolled [subscribe, getSnapshot] pair
that subscribes to Users.use directly and to the specific setting key via
settings.observe — no Tracker computation, same fan-out behaviour. Same
shape as the useSyncExternalStore migration #40446 did for ServerProvider /
AuthenticationProvider.
AuthorizationProvider still uses createReactiveSubscriptionFactory; the
permission-check helpers (hasPermission / hasRole) read via watch() and
will get their own plan in a follow-up. The factory file stays in place
for that consumer.
|
/jira ARCH-2116 |
|
Looks like this PR is not ready to merge, because of the following issues:
Please fix the issues and try again If you have any trouble, please check the PR guidelines |
WalkthroughThe ChangesUser Preference Subscription Enhancement
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Suggested labels
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (2)
apps/meteor/client/providers/UserProvider/UserProvider.tsx (2)
147-149: 💤 Low valueConsider removing implementation comment per coding guidelines.
The comment explains the internal behavior of
getUserPreferenceand why the settings subscription is needed. While this is architecturally useful context, the coding guideline for TypeScript files asks to avoid code comments in implementation.Consider whether this comment adds sufficient value to warrant an exception, or if the behavior could be documented elsewhere (e.g., in PR description, commit message, or the
getUserPreferencefunction itself).As per coding guidelines: "Avoid code comments in the implementation" for
**/*.{ts,tsx,js}.🤖 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 `@apps/meteor/client/providers/UserProvider/UserProvider.tsx` around lines 147 - 149, Remove the implementation comment explaining getUserPreference's fallback and the settings.watch subscription from UserProvider.tsx; either delete it or relocate that rationale to the getUserPreference function's JSDoc or the PR/commit message. Specifically, update the comment near the settings.watch invocation in the UserProvider component and ensure any necessary documentation lives on getUserPreference (its function comment) or external documentation so the implementation file follows the "avoid code comments in implementation" guideline.
141-158: 💤 Low valueConsider using
.toString()for explicit ObjectId conversion.The code uses
String(key)to convertObjectId | stringto string (lines 150, 156). WhileString()coercion works, usingString(key)on mixed types is less explicit than checking the type and calling.toString()when needed, or using a type guard.📝 More explicit conversion approach
- const subscribe = (onStoreChange: () => void): (() => void) => { + const keyStr = String(key); + const subscribe = (onStoreChange: () => void): (() => void) => { const unsubUsers = Users.use.subscribe(onStoreChange); // getUserPreference falls back to settings.watch(`Accounts_Default_User_Preferences_${key}`) // when the user record has no override. Subscribe to that specific // setting key so admin-side default changes still propagate. - const unsubSettings = settings.observe(`Accounts_Default_User_Preferences_${String(key)}`, onStoreChange); + const unsubSettings = settings.observe(`Accounts_Default_User_Preferences_${keyStr}`, onStoreChange); return () => { unsubUsers(); unsubSettings(); }; }; - const getSnapshot = (): T | undefined => getUserPreference(userId, String(key), defaultValue); + const getSnapshot = (): T | undefined => getUserPreference(userId, keyStr, defaultValue); return [subscribe, getSnapshot];This hoists the conversion to clarify that both subscribe and getSnapshot use the same string representation.
🤖 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 `@apps/meteor/client/providers/UserProvider/UserProvider.tsx` around lines 141 - 158, The queryPreference helper currently uses String(key) in both subscribe and getSnapshot; change this to compute a single stringKey by checking the type of key and calling key.toString() when key is an ObjectId (or otherwise using the existing string), then use stringKey in Users.use.subscribe/settings.observe and in getUserPreference(userId, stringKey, defaultValue) so the conversion is explicit and consistent across subscribe and getSnapshot (refer to queryPreference, subscribe, getSnapshot, getUserPreference, settings.observe, and Users.use.subscribe).
🤖 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 `@apps/meteor/client/providers/UserProvider/UserProvider.tsx`:
- Around line 147-149: Remove the implementation comment explaining
getUserPreference's fallback and the settings.watch subscription from
UserProvider.tsx; either delete it or relocate that rationale to the
getUserPreference function's JSDoc or the PR/commit message. Specifically,
update the comment near the settings.watch invocation in the UserProvider
component and ensure any necessary documentation lives on getUserPreference (its
function comment) or external documentation so the implementation file follows
the "avoid code comments in implementation" guideline.
- Around line 141-158: The queryPreference helper currently uses String(key) in
both subscribe and getSnapshot; change this to compute a single stringKey by
checking the type of key and calling key.toString() when key is an ObjectId (or
otherwise using the existing string), then use stringKey in
Users.use.subscribe/settings.observe and in getUserPreference(userId, stringKey,
defaultValue) so the conversion is explicit and consistent across subscribe and
getSnapshot (refer to queryPreference, subscribe, getSnapshot,
getUserPreference, settings.observe, and Users.use.subscribe).
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 8ecb3023-661b-4960-babd-3838702b886a
📒 Files selected for processing (1)
apps/meteor/client/providers/UserProvider/UserProvider.tsx
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: 📦 Build Packages
- GitHub Check: CodeQL-Build
- GitHub Check: CodeQL-Build
🧰 Additional context used
📓 Path-based instructions (1)
**/*.{ts,tsx,js}
📄 CodeRabbit inference engine (.cursor/rules/playwright.mdc)
**/*.{ts,tsx,js}: Write concise, technical TypeScript/JavaScript with accurate typing in Playwright tests
Avoid code comments in the implementation
Files:
apps/meteor/client/providers/UserProvider/UserProvider.tsx
🧠 Learnings (2)
📚 Learning: 2026-03-27T14:52:56.865Z
Learnt from: dougfabris
Repo: RocketChat/Rocket.Chat PR: 39892
File: apps/meteor/client/views/room/contextualBar/Threads/Thread.tsx:150-155
Timestamp: 2026-03-27T14:52:56.865Z
Learning: In Rocket.Chat, there are two different `ModalBackdrop` components with different prop APIs. During review, confirm the import source: (1) `rocket.chat/fuselage` `ModalBackdrop` uses `ModalBackdropProps` based on `BoxProps` (so it supports `onClick` and other Box/DOM props) and does not have an `onDismiss` prop; (2) `rocket.chat/ui-client` `ModalBackdrop` uses a narrower props interface like `{ children?: ReactNode; onDismiss?: () => void }` and handles Escape keypress and outside mouse-up, and it does not forward arbitrary DOM props such as `onClick`. Flag mismatched props (e.g., `onDismiss` passed to the fuselage component or `onClick` passed to the ui-client component) and ensure the usage matches the correct component being imported.
Applied to files:
apps/meteor/client/providers/UserProvider/UserProvider.tsx
📚 Learning: 2026-05-06T12:21:44.083Z
Learnt from: juliajforesti
Repo: RocketChat/Rocket.Chat PR: 40256
File: apps/meteor/client/components/CreateDiscussion/CreateDiscussion.tsx:121-149
Timestamp: 2026-05-06T12:21:44.083Z
Learning: Field wrappers in rocket.chat/fuselage-forms (Field, FieldLabel, FieldRow, FieldError, FieldHint) auto-create htmlFor/id associations, aria-describedby, and role="alert" for errors. Do not manually set htmlFor, id, aria-describedby, or role attributes when using these wrappers. This automatic wiring does not apply to plain rocket.chat/fuselage components, which require explicit ID wiring per the accessibility docs. In code reviews, prefer using fuselage-forms wrappers for form fields and verify there is no unnecessary manual ID/aria wiring in files that use these wrappers. If a component uses plain fuselage components, ensure proper id wiring as per docs.
Applied to files:
apps/meteor/client/providers/UserProvider/UserProvider.tsx
🔇 Additional comments (2)
apps/meteor/client/providers/UserProvider/UserProvider.tsx (2)
150-150:settings.observeAPI exists and correctly returns a cleanup function.The
observe(key: string, callback: SettingCallback): () => voidsignature confirms the code on line 150 properly captures the unsubscribe function.
156-156:getUserPreferenceexplicitly handles undefined userId.The function overloads document that
undefinedis an accepted parameter type (lines 12, 19, 27, 35-39), and the implementation uses optional chaining (user?.settings?.preferences?.[key]) to safely handle undefined values with proper fallback behavior todefaultValueorsettings.watch(). No runtime errors will occur whenuserIdis undefined.> Likely an incorrect or invalid review comment.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #40491 +/- ##
===========================================
+ Coverage 69.64% 69.66% +0.02%
===========================================
Files 3318 3318
Lines 121981 121980 -1
Branches 21791 21808 +17
===========================================
+ Hits 84948 84978 +30
+ Misses 33701 33675 -26
+ Partials 3332 3327 -5
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
1 participant
Summary
`queryPreference` was the last context value in `UserProvider` going through `createReactiveSubscriptionFactory` — i.e., through `Tracker.autorun`. `getUserPreference` reads two sources:
Replace the factory call with a hand-rolled `[subscribe, getSnapshot]` pair that subscribes to `Users.use` directly and to the specific setting key via `settings.observe` — no Tracker computation, same fan-out behaviour. Same shape as #40446's migration of `ServerProvider` / `AuthenticationProvider`.
`AuthorizationProvider` still uses `createReactiveSubscriptionFactory` — the permission-check helpers (`hasPermission` / `hasRole`) read via `watch()` and will get their own plan in a follow-up. The factory file stays in place for that consumer.
Test plan
Task: ARCH-2141
Summary by CodeRabbit
Bug Fixes
Chores