Skip to main content

Engagement, Feed, Chat, and Announcements Feature Context

Source: .agents/references/features/engagement-feed-chat-and-announcements.md

Content​

Engagement, Feed, Chat, and Announcements Feature Context

Purpose​

Engagement features keep community members active through feeds, comments, reactions, announcements, activity rows, chat cards/platform connections, messages, sessions, and notification-like banners/modals. This domain crosses public community pages, member-only surfaces, and creator configuration.

User-Facing Workflows​

  • Members browse feed posts, comment, react, and view activity.
  • Visitors or members see announcement banners, modal announcements, and carousel announcements.
  • Communities expose chat entrypoints such as WhatsApp/group cards or connected chat platform surfaces.
  • Members manage or view messages and profile/member detail popups.
  • Session and calendar-connected experiences can surface upcoming bookings or availability.

Key Entrypoints​

  • Routes:
    • src/pages/[communityLink]/feed.page.js
    • src/pages/[communityLink]/feed/[postSlug].page.js
    • src/pages/[communityLink]/sessions/
    • src/pages/[communityLink]/events/[eventSlug]/index.page.js
  • Features/components:
    • src/features/Feed/
    • src/features/ActivityFeed/
    • src/features/CommentSection/
    • src/features/AnnouncementCarousel/
    • src/features/Announcements/
    • src/components/features/AnnouncementBannerCarousel/
    • src/components/features/AnnouncementModal/
    • src/components/features/CommunityPage/components/feed/
    • src/components/features/CommunityPage/components/chat/
    • src/features/Messages/
    • src/features/ViewMemberDetails/
    • src/features/ProfilePopUp/
    • src/features/1on1Sessions/
  • Hooks:
    • src/hooks/useAnnouncements.js
    • src/hooks/useReactionList.js
    • src/hooks/usePostReaction.js
    • src/hooks/useCommunityMembers.js
    • src/hooks/member/useCommunityEventsData.js
    • src/features/1on1Sessions/hooks/
  • Services:
    • src/services/announcementService.js
    • src/services/feedImpressionService.ts
    • src/services/notificationService.ts
    • src/services/calendarService.js
    • src/services/sessionAnalytics/sessionAnalyticsService.js
  • Utilities:
    • src/utility/member/analytics.js
    • src/utility/member/helper.js
    • src/utility/hideEventAttendeeHelper.js

Data Flow and Service Boundaries​

  • Feed and announcement data can appear on both public and member pages. Confirm whether a component is public-safe before adding member-only assumptions.
  • Reactions/comments usually need optimistic or local UI state plus service-backed updates. Keep error recovery explicit and avoid hiding failed mutations.
  • Announcement surfaces can be banners, carousels, or modals. Reuse existing announcement hooks/components before adding a new display mechanism.
  • Chat and message entrypoints can depend on community configuration and user role/member state. Guard missing configuration rather than rendering broken links.
  • Chat history success responses use { data: { chat, messages, metadata } }; unwrap the API envelope once so portal chat selection receives the top-level chat payload.
  • Chat initialization product mentions must use LPBE-supported concrete entity types. Map legacy resource DIGITAL_PRODUCT to FOLDER; omit MENTION_PRODUCT when no supported concrete type is available.
  • React optimistic chat sends must track resolved temporary IDs. Hide a confirmed temporary overlay before its Action settles so the canonical server message and pending copy cannot render together.
  • Merge polled chat messages inside the functional state update and deduplicate by server message ID against that latest committed state. Filtering against the hook's render snapshot races send confirmations.
  • Enable member polling once initialization returns a server chat ID and the member has a chat token. Do not permanently gate polling merely because the chat was initialized during the current messenger session.
  • Re-check pending delivery identity after every awaited upload or send. Closing a messenger clears its pending-delivery map, so stale async continuations must not repopulate the closed view.
  • Preserve outbound manager metadata in both optimistic messages and first-message chat initialization.
  • Upload guest image messages before persisting their local signup queue; blob preview URLs are browser-local and cannot be submitted later as message attachments.
  • When closing a messenger, mark every pending temporary ID resolved and replace its FIFO queue so reopening cannot render a stale optimistic overlay or chain new sends behind an abandoned delivery.
  • Lock the controlled composer after an accepted send until its cleared value renders, preventing a rapid click or held Enter key from enqueueing the same draft twice.
  • Count in-flight guest image uploads toward the guest image cap before the uploaded message is persisted.
  • Pause selected-chat portal polling while an optimistic message is pending, uploading, or uncertain; resume for failed or settled messages so canonical polling cannot race an unresolved optimistic copy.
  • Cancel guest message persistence when the messenger session changes during an awaited upload.
  • Apply the pending-delivery poll gate to member and portal messengers.
  • Reset message-list near-bottom state and scroll position when the selected chat ID changes.
  • Restore physical-product inquiry pairing eligibility when its optimistic delivery fails or is removed; mark it pending again on retry.
  • Cancel remaining dependent messages from one accepted-send batch after an earlier message fails, without canceling later independent sends.
  • Reserve initial chat context when it is queued so rapid subsequent sends cannot attach a duplicate copy.
  • Exclude temporary delivery messages from support selection because their IDs are not server-backed.
  • Session/calendar data may depend on external calendar integrations. Inspect the calendar/session service contract before changing availability or upcoming booking UI.

Conventions and Gotchas​

  • User-generated feed/comment content is untrusted. Avoid raw HTML injection and sanitize any rich content path.
  • Do not log message/comment content or member PII.
  • Keep reaction/comment handlers in event handlers, not effects.
  • Use stable keys for lists and avoid array indices when feed items can reorder or paginate.
  • Preserve empty states and skeletons for feed/announcement loads.
  • If design-driven, match exact Figma spacing and color semantics for banners/cards/modals.
  • .agents/rules/web-security.mdc
  • .agents/rules/clean-react.mdc
  • .agents/rules/no-try-catch-service-api.mdc
  • .agents/rules/use-classnames-for-conditional-classes.mdc
  • .agents/references/coding-standard/useeffect-guidance.md
  • .agents/references/features/community-public-pages.md

Useful Graph Queries and Fallback Searches​

Use the terms below with search_graph/search_code, then run trace_path on central engagement symbols. Run these shell searches only as documented fallbacks.

rtk rg "feed|comment|reaction|announcement|chat|message|session|calendar|activity" src/features src/components/features src/hooks src/services src/pages/[communityLink]
rtk rg "useAnnouncements|usePostReaction|CommentSection|AnnouncementCarousel|JoinWhatsapp" src
rtk find src/features/Feed src/features/CommentSection src/features/AnnouncementCarousel -maxdepth 4 -type f

Update Triggers​

Update this reference when feed/comment/reaction contracts, announcement display behavior, chat entrypoints, message/member detail behavior, or session/calendar engagement flows change.