BA-1934 [FE packages] Mark Chat as Unread #158
Conversation
|
|
Warning There were issues while running some tools. Please review the errors and either fix the tool’s configuration or disable the tool if it’s a critical failure. 🔧 eslint
packages/components/modules/messages/ChatRoomsList/ChatRoomItem/index.tsxOops! Something went wrong! :( ESLint: 8.57.1 Error: Cannot read config file: /packages/components/.eslintrc.js
WalkthroughThis pull request introduces a comprehensive update to the unread messages functionality across the messaging system. The changes involve modifying GraphQL schemas, mutations, and components to replace the simple Changes
Possibly related PRs
Suggested reviewers
Poem
📜 Recent review detailsConfiguration used: CodeRabbit UI 📥 CommitsReviewing files that changed from the base of the PR and between ae7f8f069a8a4b11f5de510cf6afa506e2785ecf and c2ed2ff. ⛔ Files ignored due to path filters (11)
📒 Files selected for processing (9)
✅ Files skipped from review due to trivial changes (1)
🚧 Files skipped from review as they are similar to previous changes (7)
🔇 Additional comments (3)packages/components/schema.graphql (3)
The change from scalar
The
The mutation currently returns Also applies to: 260-267, 648-648 Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 3
🧹 Outside diff range and nitpick comments (3)
packages/components/modules/messages/graphql/mutations/UnreadChat.ts (1)
25-28: Add JSDoc documentation for the hookConsider adding JSDoc documentation to describe the hook's purpose, parameters, and return value.
+/** + * Hook for marking a chat room as unread + * @returns [commit function, mutation in flight status] + */ export const useUnreadChatMutation = (): [packages/graphql/package.json (1)
25-25: Consider using caret range for React peer dependencyThe React version is pinned to exactly 18.3.1 while other dependencies use caret ranges. Consider using
^18.3.1for consistency unless there's a specific reason for the exact version.packages/components/package.json (1)
53-114: Ensure test coverage for new chat featuresThe comprehensive testing setup (Jest, Cypress, Testing Library, MSW) provides a good foundation for testing the new "Mark Chat as Unread" feature. Consider:
- Adding component tests using Cypress (line 89)
- Using MSW (line 100) to mock GraphQL mutations for chat status
- Leveraging Testing Library (lines 72-75) for interaction testing
Would you like help setting up test cases for the new chat feature?
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📥 Commits
Reviewing files that changed from the base of the PR and between 3c2ea87 and 0f4d560249b1425a7bf7969d4532d38b27948479.
⛔ Files ignored due to path filters (12)
packages/components/__generated__/ChatRoomMessagesListPaginationQuery.graphql.tsis excluded by!**/__generated__/**packages/components/__generated__/ChatRoomQuery.graphql.tsis excluded by!**/__generated__/**packages/components/__generated__/ChatRoomsQuery.graphql.tsis excluded by!**/__generated__/**packages/components/__generated__/CreateChatRoomMutation.graphql.tsis excluded by!**/__generated__/**packages/components/__generated__/MessagesListFragment.graphql.tsis excluded by!**/__generated__/**packages/components/__generated__/ReadMessagesMutation.graphql.tsis excluded by!**/__generated__/**packages/components/__generated__/RoomFragment.graphql.tsis excluded by!**/__generated__/**packages/components/__generated__/UnreadChatMutation.graphql.tsis excluded by!**/__generated__/**packages/components/__generated__/chatRoomsPaginationQuery.graphql.tsis excluded by!**/__generated__/**packages/components/__generated__/useMessageCountUpdateSubscription.graphql.tsis excluded by!**/__generated__/**packages/components/__generated__/useRoomListSubscription.graphql.tsis excluded by!**/__generated__/**pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (18)
packages/authentication/package.json(1 hunks)packages/components/modules/messages/ChatRoomsList/ChatRoomItem/index.tsx(6 hunks)packages/components/modules/messages/graphql/mutations/ReadMessages.ts(1 hunks)packages/components/modules/messages/graphql/mutations/UnreadChat.ts(1 hunks)packages/components/modules/messages/graphql/queries/ChatRoomQuery.ts(1 hunks)packages/components/modules/messages/graphql/queries/MessagesList.ts(1 hunks)packages/components/modules/messages/graphql/queries/Room.ts(1 hunks)packages/components/modules/messages/graphql/subscriptions/useMessageCountUpdateSubscription.tsx(1 hunks)packages/components/package.json(1 hunks)packages/components/schema.graphql(4 hunks)packages/config/package.json(1 hunks)packages/design-system/package.json(1 hunks)packages/eslint-plugin/package.json(1 hunks)packages/graphql/package.json(1 hunks)packages/provider/package.json(1 hunks)packages/test/package.json(1 hunks)packages/utils/package.json(1 hunks)packages/wagtail/package.json(1 hunks)
🔇 Additional comments (28)
packages/components/modules/messages/graphql/queries/ChatRoomQuery.ts (1)
21-24: LGTM! Verify GraphQL schema compatibility
The addition of the unreadMessages object with count and markedUnread fields aligns well with the PR objectives for implementing the "Mark as Unread" feature. The structure is consistent with GraphQL best practices.
Let's verify the GraphQL schema compatibility:
✅ Verification successful
Schema compatibility verified and usage is consistent
The UnreadMessages type is properly defined in the schema with matching fields (count and markedUnread). The field is consistently used across multiple files:
- Mutations:
UnreadChat.ts,ReadMessages.ts - Queries:
Room.ts,MessagesList.ts,ChatRoomQuery.ts,RoomsList.ts - Subscriptions:
useMessageCountUpdateSubscription.tsx,useRoomListSubscription.tsx
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that the schema defines the UnreadMessages type
# and that it's used consistently across queries
# Check for UnreadMessages type definition
rg -A 5 "type UnreadMessages" packages/components/schema.graphql
# Check for consistent usage of unreadMessages field
rg "unreadMessages.*{" packages/components/modules/messages/graphql/
Length of output: 328
Script:
#!/bin/bash
# Let's try a different approach to verify the schema compatibility and usage
# Check for unreadMessages field usage in queries without regex metacharacters
rg "unreadMessages" packages/components/modules/messages/graphql/
# Check if there are any other GraphQL schema files that might contain the type definition
fd schema.graphql
# Check for any fragments that might be using unreadMessages
rg "fragment.*Messages" packages/components/modules/messages/graphql/
Length of output: 1693
packages/components/modules/messages/graphql/queries/Room.ts (1)
6-9: LGTM! Consistent implementation across fragments
The unreadMessages object structure in the RoomFragment matches the implementation in ChatRoomQuery, maintaining consistency throughout the codebase. This will properly support the unread status display in chat cards as per the requirements.
packages/components/modules/messages/graphql/queries/MessagesList.ts (1)
11-14: LGTM! Verify pagination query compatibility
The unreadMessages implementation in MessagesListFragment maintains consistency with other fragments. The placement before the paginated messages connection is appropriate.
Let's verify the pagination query compatibility:
✅ Verification successful
Pagination query compatibility verified
The unreadMessages field is correctly included in the pagination query structure and is properly handled by the usePaginationFragment hook in the MessagesList component. The field placement before the paginated allMessages connection maintains data consistency during pagination operations.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Verify that the pagination query includes unreadMessages field
# and that it's handled consistently
# Check the generated pagination query
rg -A 10 "ChatRoomMessagesListPaginationQuery.*{" packages/components/modules/messages/
# Check for any potential pagination-related mutations that might need updates
rg "mutation.*ChatRoomMessages.*{" packages/components/modules/messages/
Length of output: 426
Script:
#!/bin/bash
# Let's fix the regex syntax and try again with proper escaping
# Check the generated pagination query
rg -A 10 "ChatRoomMessagesListPaginationQuery.*\{" packages/components/modules/messages/
# Check for any potential pagination-related mutations that might need updates
rg "mutation.*ChatRoomMessages.*\{" packages/components/modules/messages/
# Also search for any pagination-related fragments
rg "fragment.*MessagesListPagination.*\{" packages/components/modules/messages/
# Let's also check for any pagination-related code in the TypeScript files
rg -t ts "MessagesListPagination" packages/components/modules/messages/
Length of output: 1829
packages/components/modules/messages/graphql/subscriptions/useMessageCountUpdateSubscription.tsx (2)
18-21:
Remove redundant unreadMessagesCount field
The subscription includes both unreadMessagesCount and the new unreadMessages structure. Since unreadMessages.count provides the same information, we should remove the redundant unreadMessagesCount field.
subscription useMessageCountUpdateSubscription($profileId: ID!) {
chatRoomOnMessagesCountUpdate(profileId: $profileId) {
profile {
id
- unreadMessagesCount
chatRooms {
totalCountLikely invalid or redundant comment.
18-21: Verify subscription behavior with new unread structure
The new unreadMessages structure looks good and aligns with the PR objectives. Let's verify that the subscription properly handles both manual unread state and message counts.
✅ Verification successful
Based on the search results, I can see that the new unreadMessages structure with count and markedUnread fields is consistently used across the codebase in multiple locations:
- GraphQL schema defines the structure correctly
- Multiple components and queries use this structure:
- ChatRoomItem component uses both fields appropriately
- Room, MessagesList, UnreadChat mutations/queries all use the correct structure
- The subscription in question (useMessageCountUpdateSubscription) aligns with this structure
The subscription properly handles both the manual unread state (markedUnread) and message counts (count) in its structure, and this is consistent with how it's used throughout the codebase. The implementation is verified to be correct.
The new unreadMessages structure is properly implemented and consistent
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for consistent usage of the new unreadMessages structure
rg -l "unreadMessagesCount" --type ts --type tsx
# Verify that all relevant components are updated to use the new structure
ast-grep --pattern 'unreadMessages { count markedUnread }'
Length of output: 137
Script:
#!/bin/bash
# Search for unreadMessages structure usage with proper file extensions
rg -l "unreadMessages.*count" --type typescript --type tsx
# Search for any references to unread messages or counts in the codebase
rg -A 3 "unreadMessages" --type typescript --type tsx
# Look for GraphQL fragments or queries related to unread messages
rg -A 5 "fragment.*UnreadMessages|query.*UnreadMessages|subscription.*UnreadMessages" --type typescript --type tsx
Length of output: 336
Script:
#!/bin/bash
# Search for unreadMessages structure usage without file type restrictions
rg -A 3 "unreadMessages"
# Look for GraphQL related files and their content
fd -e graphql . -x cat {}
# Search specifically in the messages module
fd . packages/components/modules/messages -x cat {}
Length of output: 71194
packages/components/modules/messages/graphql/mutations/ReadMessages.ts (1)
12-15: LGTM! Verify RoomFragment consistency
The mutation correctly implements the new unreadMessages structure and maintains proper error handling. The changes align well with the subscription updates.
✅ Verification successful
RoomFragment is consistent with the new unreadMessages structure
The verification confirms that RoomFragment in packages/components/modules/messages/graphql/queries/Room.ts correctly includes the new unreadMessages structure with both count and markedUnread fields. This matches the structure used in the ReadMessages mutation.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Verify RoomFragment includes the new unreadMessages structure
rg -A 5 "fragment RoomFragment" --type graphql
Length of output: 80
Script:
#!/bin/bash
# Search for RoomFragment in all files
rg -A 5 "fragment RoomFragment"
Length of output: 11386
Script:
#!/bin/bash
# Find GraphQL files that might contain fragments
fd -e graphql -e gql -e ts -e tsx | xargs rg -l "fragment.*Room"
Length of output: 856
Script:
#!/bin/bash
# Look for files containing both RoomFragment and unreadMessages
rg -l "RoomFragment" | xargs rg -l "unreadMessages"
Length of output: 862
packages/components/modules/messages/graphql/mutations/UnreadChat.ts (2)
7-23: LGTM! Well-structured mutation implementation
The mutation is well-implemented with proper error handling and consistent structure.
8-9: Verify ChatRoomUnreadInput type definition
Let's verify the input type definition in the schema.
✅ Verification successful
Input type ChatRoomUnreadInput is correctly defined in the schema
The schema shows that ChatRoomUnreadInput is properly defined with the following fields:
roomId: ID!(required)profileId: ID!(required)clientMutationId: String(optional)
The usage in the mutation is consistent with the schema definition.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check the input type definition
rg "input ChatRoomUnreadInput" --type graphql -A 5
Length of output: 84
Script:
#!/bin/bash
# Let's search for GraphQL schema files with common extensions
fd "\.(graphql|gql)$" --type f --exec cat {}
# Also check for schema definitions in TypeScript/JavaScript files
rg "input.*ChatRoomUnreadInput" -t ts -t js -A 5
Length of output: 37868
packages/components/modules/messages/ChatRoomsList/ChatRoomItem/index.tsx (4)
1-1: LGTM: Appropriate imports added for the new functionality.
The new imports support the "Mark as Unread" feature implementation:
useCallbackfor performance optimizationuseUnreadChatMutationfor the GraphQL mutation
Also applies to: 12-12
26-26: LGTM: Mutation hook properly initialized.
The mutation hook is correctly initialized at the component level, following React hooks best practices.
56-67: LGTM: Well-implemented unread state management and mutation callback.
The implementation is robust:
- Unified unread state check combines both manual and automatic unread indicators
- Callback is properly memoized with correct dependencies
- Mutation includes all required parameters
82-85: Verify the position of the "Mark as Unread" action in the overlay menu.
The UI implementation looks good, but let's verify if the "Mark as Unread" action should be positioned after the "Archive Chat" action in the overlay menu. Consider the user experience and common patterns in chat applications.
Also applies to: 142-145
✅ Verification successful
Based on the search results, I can see the implementation of the ActionsOverlay component in the ChatRoomItem and its usage across the codebase. Looking at the code in packages/components/modules/messages/ChatRoomsList/ChatRoomItem/index.tsx, the "Mark as Unread" action is positioned after the "Archive Chat" action, which is a logical and common pattern in chat applications. The order follows a natural progression from primary actions (archiving) to secondary actions (marking as unread).
The position of "Mark as Unread" action in the overlay menu is correctly placed.
The current implementation follows the established pattern where:
- Archive action is placed first as it's a primary chat management action
- Mark as Unread follows as a secondary action affecting chat state
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for similar overlay menu implementations in the codebase
rg -A 10 "ActionsOverlay.*title=\"Chat\"" --type typescript
Length of output: 94
Script:
#!/bin/bash
# Search for ActionsOverlay components in the codebase
rg -A 10 "ActionsOverlay" --type ts --type tsx
# Also search for menu-related patterns to understand the common order
rg -A 10 "menu.*items.*=.*\[" --type ts --type tsx
Length of output: 155
Script:
#!/bin/bash
# Search for ActionsOverlay components and menu patterns in the codebase
rg -A 10 "ActionsOverlay"
# Also search for menu items array patterns
rg -A 10 "items.*=.*\["
Length of output: 21964
packages/components/schema.graphql (2)
1979-1982: LGTM: Well-structured UnreadMessages type.
The type definition properly supports both automatic and manual unread states:
countfor tracking number of unread messagesmarkedUnreadfor tracking manual unread state
109-109: LGTM: ChatRoom type properly updated with unreadMessages field.
The field definition is correct:
- Optional profileId parameter allows per-user unread state
- Returns the new UnreadMessages type
packages/eslint-plugin/package.json (1)
18-18: Verify compatibility between TypeScript and related dependencies
The TypeScript version (^5.4.5) is very recent while ESLint (^8.42.0) and its types are from older releases. This version mismatch might cause compatibility issues.
Also applies to: 22-23, 25-26
✅ Verification successful
Let me gather more information about the specific ESLint version being used to check for any known compatibility issues or vulnerabilities.
Let me check one more thing to verify the ESLint plugin's compatibility with TypeScript.
Based on the gathered information, I can now provide the final response:
ESLint version is compatible with the TypeScript setup
The current setup is actually well-structured:
- ESLint is correctly specified as a runtime dependency since this is an ESLint plugin package
- TypeScript and @types/eslint are properly set as devDependencies
- The version ranges (^) are appropriate here as:
- ESLint 8.42.0 is stable and compatible with TypeScript 5.x
- No security advisories were found for ESLint 8.42.0
- The types version (^9.6.1) is forward-compatible with ESLint 8.x
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for compatibility issues between TypeScript and ESLint
# Description: Verify if the specified versions are compatible and if there are any known issues
# Check latest compatible versions
echo "Latest TypeScript version:"
curl -s https://registry.npmjs.org/typescript/latest | jq '.version'
echo "Latest ESLint version:"
curl -s https://registry.npmjs.org/eslint/latest | jq '.version'
echo "Latest @types/eslint version:"
curl -s https://registry.npmjs.org/@types/eslint/latest | jq '.version'
# Check for related issues
gh api graphql -f query='
{
search(query: "repo:microsoft/TypeScript is:issue typescript eslint compatibility", type: ISSUE, first: 5) {
nodes {
... on Issue {
title
url
state
createdAt
}
}
}
}'
Length of output: 1551
Script:
#!/bin/bash
# Check ESLint v8.42.0 release date and any security advisories
echo "ESLint v8.42.0 release info:"
curl -s https://registry.npmjs.org/eslint/8.42.0 | jq '{date: .time, version: .version}'
echo -e "\nChecking for security advisories:"
curl -s "https://registry.npmjs.org/-/npm/v1/security/advisories/search?package=eslint&version=8.42.0" | jq '.'
# Check the actual TypeScript version in package.json
echo -e "\nActual TypeScript version in package.json:"
rg '"typescript":\s*"([^"]+)"' packages/eslint-plugin/package.json
# Check if there are any TypeScript-specific ESLint rules or configurations
echo -e "\nChecking for TypeScript-specific ESLint configurations:"
fd -e json -e js -e ts . packages/eslint-plugin/src -x rg -l "typescript|@typescript-eslint" {}
Length of output: 1033
Script:
#!/bin/bash
# Check package dependencies and peer dependencies
echo "Checking package.json content:"
cat packages/eslint-plugin/package.json
# Check if there are any TypeScript-specific files in the plugin
echo -e "\nChecking for TypeScript-related files:"
fd . packages/eslint-plugin -t f -x rg -l "typescript|@typescript-eslint" {}
# Look for any existing eslint config files
echo -e "\nLooking for eslint config files:"
fd -g '.eslintrc*' packages/eslint-plugin
Length of output: 1780
packages/provider/package.json (1)
15-16: Verify compatibility with React Query and related dependencies
The React Query version is recent (^5.45.1). Let's ensure compatibility with other dependencies, especially given the chat functionality requirements.
Also applies to: 25-27
✅ Verification successful
Let me gather more information about the React dependencies in the project to ensure full compatibility.
Based on the comprehensive analysis of the codebase, I can now provide a final response:
React Query version 5.45.1 is compatible with the project's requirements
The codebase shows proper integration with React Query v5, with consistent usage patterns across multiple packages. Key findings:
- The project uses React Query primarily for authentication, user management, and MFA features
- All React Query hooks (
useQuery,useMutation,useQueryClient) are used correctly according to v5 patterns - The project's React version (18.3.1) matches React Query's peer dependencies
- No compatibility issues found in the chat functionality implementation
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check compatibility between React Query and related dependencies
# Check latest stable versions
echo "Latest @tanstack/react-query version:"
curl -s https://registry.npmjs.org/@tanstack/react-query/latest | jq '.version'
# Check peer dependencies
echo "React Query peer dependencies:"
curl -s https://registry.npmjs.org/@tanstack/react-query/latest | jq '.peerDependencies'
# Search for potential issues
gh api graphql -f query='
{
search(query: "repo:TanStack/query is:issue react-query chat", type: ISSUE, first: 5) {
nodes {
... on Issue {
title
url
state
}
}
}
}'
Length of output: 1315
Script:
#!/bin/bash
# Check React version and other related dependencies
echo "Checking package.json files for React and related dependencies:"
fd package.json --exec cat {} \; | jq -r 'select(.dependencies != null or .peerDependencies != null) | {name: .name, dependencies: .dependencies, peerDependencies: .peerDependencies}'
# Check for React Query usage patterns
echo -e "\nChecking React Query usage patterns:"
rg -A 2 "useQuery|useMutation|useInfiniteQuery|useQueryClient"
Length of output: 34610
packages/config/package.json (1)
13-28: Review version compatibility and security implications
Several dependencies are significantly outdated and might have security implications:
- eslint-plugin-import (2.26.0)
- eslint-plugin-jsx-a11y (6.6.1)
- eslint-plugin-react (7.31.11)
Additionally, Prettier 3.x has breaking changes that might affect the existing configuration.
Consider implementing a dependency update strategy to keep security-critical packages up-to-date while maintaining stability.
✅ Verification successful
Let me verify the ESLint plugin compatibility with the current versions by checking their peer dependencies.
Dependencies are compatible and secure
The initial concern about outdated dependencies and security implications has been verified:
- No security vulnerabilities were found in any of the ESLint plugins
- All ESLint plugins are compatible with ESLint v8.42.0 used in the project
- Prettier 3.3.3 is only slightly behind the latest (3.4.2) and within the same major version
The current dependency versions are stable and secure to use.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for security advisories and compatibility issues
# Check for security advisories
for pkg in "@emotion/eslint-plugin" "@next/eslint-plugin-next" "eslint-plugin-import" "eslint-plugin-jsx-a11y" "eslint-plugin-react"; do
echo "Checking $pkg:"
gh api graphql -f query="
{
securityVulnerabilities(first: 5, ecosystem: NPM, package: \"${pkg}\") {
nodes {
advisory {
summary
severity
publishedAt
}
vulnerableVersionRange
}
}
}"
done
# Check latest versions
echo "Latest Prettier version and breaking changes:"
curl -s https://registry.npmjs.org/prettier/latest | jq '.version'
Length of output: 2836
Script:
#!/bin/bash
# Check peer dependencies for ESLint plugins
for pkg in "eslint-plugin-import" "eslint-plugin-jsx-a11y" "eslint-plugin-react"; do
echo "Checking $pkg peer dependencies:"
curl -s "https://registry.npmjs.org/$pkg/latest" | jq '.peerDependencies'
done
# Check ESLint version compatibility
echo "Current ESLint version in package.json:"
rg '"eslint": ".*"' packages/config/package.json
Length of output: 1184
packages/graphql/package.json (1)
15-21: Verify security implications of dependency updates
The transition from catalog-based versions to explicit versions looks good, but let's verify there are no known vulnerabilities in these versions.
✅ Verification successful
Dependencies are secure with the specified versions
The version ^16.8.1 of graphql package specified in package.json is secure as it's exactly the version that patches the moderate severity vulnerability (Uncontrolled Resource Consumption) that affected versions >= 16.3.0, < 16.8.1. Let's verify other key dependencies:
All dependency updates are secure and properly versioned
The security verification shows that:
graphql@^16.8.1includes the fix for the moderate severity vulnerabilitygraphql-ws@^5.16.0has no known vulnerabilitiesreact-relay@^16.2.0has no known vulnerabilities
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for known vulnerabilities in the updated packages
gh api graphql -f query='
{
securityVulnerabilities(first: 10, ecosystem: NPM, package: "graphql") {
nodes {
advisory {
summary
severity
publishedAt
}
vulnerableVersionRange
firstPatchedVersion {
identifier
}
}
}
}'
Length of output: 575
Script:
#!/bin/bash
# Check vulnerabilities for other updated packages
gh api graphql -f query='
{
securityVulnerabilities(first: 10, ecosystem: NPM, package: "graphql-ws") {
nodes {
advisory {
summary
severity
publishedAt
}
vulnerableVersionRange
firstPatchedVersion {
identifier
}
}
}
}'
gh api graphql -f query='
{
securityVulnerabilities(first: 10, ecosystem: NPM, package: "react-relay") {
nodes {
advisory {
summary
severity
publishedAt
}
vulnerableVersionRange
firstPatchedVersion {
identifier
}
}
}
}'
Length of output: 689
packages/test/package.json (2)
29-31: Review testing library version compatibility
The testing library packages have significant version differences:
- jest-dom: ^6.4.6
- react: ^16.0.0
- user-event: ^14.5.2
Please verify these versions are compatible with each other.
19-19:
Verify impact of React Query v5 upgrade
The update to @tanstack/react-query v5 includes breaking changes that might affect tests.
✅ Verification successful
Let's examine the actual usage patterns to identify potential breaking changes. I'll search for specific React Query patterns that have changed in v5.
Based on the analysis of the shell script results, I can now provide a final response:
React Query v5 upgrade is compatible with current usage
The codebase's React Query implementation already follows v5's object-syntax pattern for both queries and mutations. Key observations:
- All
useQuerycalls use the object syntax:useQuery({ queryKey, queryFn, ... }) - All
useMutationcalls use the object syntax:useMutation({ mutationFn, ... }) - QueryClient configurations are simple and don't use deprecated options
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for React Query usage patterns that might be affected by v5 breaking changes
rg -l "useQuery|useMutation|useInfiniteQuery|queryClient"
Length of output: 2314
Script:
#!/bin/bash
# Check for specific v5 breaking changes patterns
# 1. Check for QueryClient configuration (defaults changed in v5)
rg "new QueryClient\(" -A 5
# 2. Check for useQuery usage (syntax changes in v5)
ast-grep --pattern 'useQuery($$$)'
# 3. Check for useMutation usage (syntax changes in v5)
ast-grep --pattern 'useMutation($$$)'
# 4. Check for test files using React Query
rg "useQuery|useMutation" "**/*.test.tsx"
Length of output: 18881
packages/authentication/package.json (2)
32-46: Consistent dependency versions across packages
The testing-related dependencies are now aligned with the @baseapp-frontend/test package, which is good for maintainability.
16-21:
Verify breaking changes in updated dependencies
Multiple dependencies have been updated that might include breaking changes:
- @tanstack/react-query v5
- react-hook-form ^7.51.5
- jotai ^2.9.3
Please ensure these updates are compatible with the chat unread feature implementation.
✅ Verification successful
Let me gather more specific information about the usage patterns to verify compatibility.
This will help us understand the specific usage patterns and whether they might be affected by breaking changes in the updated dependencies.
Based on the analysis of the usage patterns, I can now generate the final response:
Dependencies update appears safe to proceed
The codebase usage patterns are compatible with the updated versions:
- React Query usage follows v5 patterns with object syntax for
useQuery - React Hook Form usage is standard and includes a comment about v8 compatibility
- No direct Jotai atom usage found in the codebase
The chat unread feature implementation should not be affected by these dependency updates.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for usage patterns that might be affected by breaking changes
rg -l "useForm|useQuery|atom|atomWithStorage"
Length of output: 1968
Script:
#!/bin/bash
# Check React Query usage patterns
echo "=== React Query Patterns ==="
rg "useQuery\(" -A 2
echo -e "\n=== React Hook Form Patterns ==="
rg "useForm\(" -A 2
echo -e "\n=== Jotai Usage Patterns ==="
rg "atom\(|atomWithStorage\(" -A 2
Length of output: 5202
packages/utils/package.json (2)
26-26: Verify state management dependencies compatibility
The chat unread feature relies on state management. Ensure the updated versions of react-hook-form (^7.51.5) and zustand (^4.5.2) are compatible with the new chat functionality.
Also applies to: 28-28
✅ Verification successful
Dependencies are compatible with chat functionality
The codebase analysis shows that both react-hook-form and zustand are being used correctly in the chat implementation:
-
react-hook-form(^7.51.5) is used in chat-related components:SendMessage/index.tsxfor message compositionChatRoomsList/index.tsxfor search functionalityCreateChatRoomList/index.tsxfor room creation
-
zustand(^4.5.2) is properly integrated:ChatRoomProvider/index.tsximplements the chat state management using zustand'screateuseChatRoomhook correctly uses zustand'suseStore- The state management pattern follows zustand's recommended practices
The implementation shows no compatibility issues between these dependencies and the chat functionality.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for zustand store implementations related to chat
rg -l "create.*Store.*[Cc]hat"
# Search for react-hook-form usage in chat components
rg -l "useForm.*[Cc]hat"
Length of output: 131
Script:
#!/bin/bash
# Let's examine the chat store implementation and its dependencies
cat packages/components/modules/messages/context/ChatRoomProvider/index.tsx
# Search for any chat-related components using react-hook-form
rg "useForm" -A 3 -B 3
# Check for zustand usage in chat components
rg "create" -A 3 packages/components/modules/messages/context/ChatRoomProvider/index.tsx
# Look for any chat-related state management
rg "createStore|useStore" -A 3 -B 3
Length of output: 33545
24-24: Caution: Using Next.js Canary Version
The package specifies Next.js canary version 14.3.0-canary.24. Canary releases are pre-release versions that may contain breaking changes or instabilities.
Consider using the latest stable version of Next.js to ensure production reliability.
packages/design-system/package.json (1)
21-26: Verify MUI component compatibility with chat overlay
The chat card overlay feature relies on MUI components. The updates to multiple MUI packages (^5.15.19) should be tested thoroughly with the new chat overlay implementation.
packages/wagtail/package.json (1)
26-28: Ensure GraphQL dependencies support chat mutations
The chat unread feature requires GraphQL mutations. The updates to graphql (^16.8.1) and react-relay (^16.2.0) should be verified with the new chat mutation implementation.
✅ Verification successful
GraphQL dependencies are properly configured for chat mutations
The codebase shows correct implementation of chat mutations using the specified versions:
- Uses modern
react-relayfeatures likeuseMutationhook - Implements proper GraphQL mutation structure with input types
- Generated files indicate successful schema compilation
- Error handling and TypeScript types are properly integrated
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for GraphQL mutations related to chat
rg -l "mutation.*[Cc]hat.*[Uu]nread"
# Look for Relay implementations
ast-grep --pattern 'import { useMutation } from "react-relay"'
Length of output: 370
Script:
#!/bin/bash
# Check the content of UnreadChat mutation to verify compatibility
cat packages/components/modules/messages/graphql/mutations/UnreadChat.ts
# Check the generated mutation files for version compatibility markers
head -n 5 packages/components/__generated__/UnreadChatMutation.graphql.ts
head -n 5 packages/components/__generated__/ReadMessagesMutation.graphql.ts
# Look for actual mutation usage in components
rg -A 5 "useMutation.*[Cc]hat.*[Uu]nread"
Length of output: 2419
packages/components/package.json (2)
49-50:
React 18.3.1 is a canary release. Using canary releases in production can lead to:
- Unexpected breaking changes
- Potential security vulnerabilities
- Unstable behavior
Consider using the latest stable version of React instead.
Let's verify the latest stable React version:
24-42: Consider pinning critical dependency versions
While using caret ranges (^) allows for automatic minor version updates, consider pinning versions for critical dependencies to ensure consistent builds and prevent unexpected breaking changes. This is particularly important for:
@mui/*packages (lines 25-27)react-relayandrelay-runtime(lines 36, 38)@tanstack/react-query(line 29)
Let's verify the compatibility of these versions:
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
packages/components/CHANGELOG.md (1)
7-8: Enhance the changelog entries with more specific detailsThe current entries could be more descriptive to better reflect the scope of changes. Consider expanding them to:
-Graphql mutation for unreading chats introduced -graphql field unreadMessagesCount is replaced by a count field on unreadMessages (which also has a markedUnread field) +- Added new GraphQL mutation `unreadChat` to support marking chats as unread from chat card overlay +- Replaced `unreadMessagesCount` field with `unreadMessages` object containing: + - `count`: Number of unread messages + - `markedUnread`: Boolean flag indicating manually marked unread status
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📥 Commits
Reviewing files that changed from the base of the PR and between d627207312d4038f3aef9b859c79a8f8efde5130 and f85fd40756794a0526cdde475a622e5bbe2ff6d4.
📒 Files selected for processing (3)
packages/components/CHANGELOG.md(1 hunks)packages/components/modules/messages/ChatRoomsList/ChatRoomItem/index.tsx(6 hunks)packages/components/package.json(1 hunks)
✅ Files skipped from review due to trivial changes (1)
- packages/components/package.json
🚧 Files skipped from review as they are similar to previous changes (1)
- packages/components/modules/messages/ChatRoomsList/ChatRoomItem/index.tsx
🔇 Additional comments (2)
packages/components/CHANGELOG.md (2)
7-7: Fix the double dash formatting
There's an extra dash in the bullet point.
-- - Graphql mutation for unreading chats introduced
+- Graphql mutation for unreading chats introduced3-9: Verify version bump is appropriate
The changes introduce new GraphQL mutations and modify existing fields, which could be breaking changes depending on how they're used.
✅ Verification successful
Version bump from 0.0.29 to 0.0.30 is appropriate
The changes are backward compatible as they add new functionality (GraphQL mutation for unreading chats) and modify the structure of the unread messages data in a non-breaking way:
- The old
unreadMessagesCountfield is still present in the schema and subscription - The new structure (
unreadMessages { count, markedUnread }) is added alongside the existing field - The changes follow the pattern of extending functionality rather than removing or breaking existing features
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if these changes might be breaking by looking for usages of the old field
rg -l 'unreadMessagesCount'
# Check package.json to verify if this should be a minor version instead of patch
cat package.json | jq '.version'
Length of output: 309
Script:
#!/bin/bash
# Let's check the actual content of these files to understand the usage
rg -A 5 'unreadMessagesCount' packages/components/schema.graphql
rg -A 5 'unreadMessagesCount' packages/components/modules/messages/graphql/subscriptions/useMessageCountUpdateSubscription.tsx
rg -A 5 'unreadMessagesCount' packages/components/__generated__/useMessageCountUpdateSubscription.graphql.ts
# Let's also check the package.json in the components directory
cat packages/components/package.json
Length of output: 6856
tsl-ps2
force-pushed
the
BA-1934-mark-as-unread
branch
2 times, most recently
from
3f8e49b to
ae7f8f0
Compare
# Conflicts: # packages/components/CHANGELOG.md # packages/components/__generated__/ChatRoomQuery.graphql.ts # packages/components/__generated__/ChatRoomsQuery.graphql.ts # packages/components/__generated__/CreateChatRoomMutation.graphql.ts # packages/components/__generated__/ReadMessagesMutation.graphql.ts # packages/components/__generated__/RoomFragment.graphql.ts # packages/components/__generated__/chatRoomsPaginationQuery.graphql.ts # packages/components/__generated__/useRoomListSubscription.graphql.ts # packages/components/modules/messages/ChatRoomsList/ChatRoomItem/index.tsx # packages/components/modules/messages/graphql/queries/ChatRoomQuery.ts # packages/components/modules/messages/graphql/queries/Room.ts # packages/components/package.json # packages/components/schema.graphql # Conflicts: # packages/components/CHANGELOG.md # Conflicts: # packages/components/CHANGELOG.md
tsl-ps2
force-pushed
the
BA-1934-mark-as-unread
branch
from
c52361a to
c2ed2ff
Compare
|
Acceptance Criteria
Business Rules - Mark as Unread - 5 points
As a user, I want the option to mark a chat as unread from the overlay on a chat card, so that I can keep track of conversations that require follow-up or additional attention later.
When I hover over a chat card, the overlay displays a "Mark as Unread" button (eye), allowing me to mark the chat as unread without opening it.
When I mark a chat as unread, the chat card displays an unread indicator (red dot) to signal that the chat needs attention.
The notification dot should not show any number.
Whenever a user clicks on an unread chat, then the chat room should be unmarked.
If a new message comes in while the chat is markes as unread (with the empty red dot), it should update so that it shows the amount of new unread messages.
Implementation Strategy
We talked about having a manual unread field to handle the unread blank dot state.
Summary by CodeRabbit
New Features
Bug Fixes
Documentation
Schema Updates