@droppii-org/chat-mobile 0.2.81 → 0.2.82

package/src/screens/chat-detail/legend/LegendChatMessage.tsx

@@ -137,8 +137,14 @@ export const LegendChatMessage = memo(
 
     const hasMediaPress =
       MEDIA_TYPES.includes(message?.contentType) && onMediaPress;
+    // AtTextMessage included: mention+URL combo attaches its link-preview
+    // card via ex.urlMetadata on an AtTextMessage (see TextMessage's doc
+    // comment) instead of a dedicated UrlTextMessage — the card still needs
+    // a tap handler.
     const hasUrlPress =
-      onPressUrl && message?.contentType === MessageType.UrlTextMessage;
+      onPressUrl &&
+      (message?.contentType === MessageType.UrlTextMessage ||
+        message?.contentType === MessageType.AtTextMessage);
 
     return (
       <KContainer.View style={messageStyles.wrapper} row alignItems>

package/src/services/mentionSearch.ts

@@ -0,0 +1,57 @@
+import OpenIMSDK, {
+  GroupMemberFilter,
+  type GroupMemberItem,
+} from '@droppii/openim-rn-client-sdk';
+import type {
+  MentionSearchResult,
+  MentionSearchSource,
+  MentionSuggestion,
+} from '../types/mention';
+
+const toSuggestion = (member: GroupMemberItem): MentionSuggestion => ({
+  userId: member.userID,
+  displayName: member.nickname,
+  avatar: member.faceURL,
+});
+
+/**
+ * Concrete MentionSearchSource implementation for Part A's mention
+ * composer, wrapping the OpenIM SDK's group-member primitives — 0 call
+ * sites anywhere else in this repo before this feature. Empty keyword ->
+ * the full/initial member list (getGroupMemberList); non-empty keyword ->
+ * server-backed search (searchGroupMembers), purpose-built for this case.
+ *
+ * Neither SDK call returns a total count, so `hasMore` is inferred from
+ * page size (a full page *might* mean there's another one) — the same
+ * heuristic every offset/count-paginated list in this codebase already
+ * relies on, since OpenIM doesn't expose a cheaper alternative here.
+ */
+export function createOpenIMMentionSearchSource(
+  groupID: string
+): MentionSearchSource {
+  return {
+    async search({ keyword, limit, offset }): Promise<MentionSearchResult> {
+      const members =
+        keyword === ''
+          ? await OpenIMSDK.getGroupMemberList({
+              groupID,
+              filter: GroupMemberFilter.All,
+              offset,
+              count: limit,
+            })
+          : await OpenIMSDK.searchGroupMembers({
+              groupID,
+              keywordList: [keyword],
+              isSearchUserID: false,
+              isSearchMemberNickname: true,
+              offset,
+              count: limit,
+            });
+
+      return {
+        items: members.map(toSuggestion),
+        hasMore: members.length === limit,
+      };
+    },
+  };
+}

package/src/services/message.ts

@@ -67,7 +67,15 @@ export namespace ChatMessageAPI {
   }
 
   export async function markConversationAsRead(conversationID: string) {
-    return OpenIMSDK.markConversationMessageAsRead(conversationID);
+    // resetConversationGroupAtType clears the "@ mention" flag
+    // (ConversationItem.groupAtType) — the core SDK never resets it on its
+    // own (confirmed: markConversationMessageAsRead only zeroes
+    // unreadCount), so it has to be requested explicitly at the same
+    // "user is caught up on this conversation" moment as the read marker.
+    return Promise.all([
+      OpenIMSDK.markConversationMessageAsRead(conversationID),
+      OpenIMSDK.resetConversationGroupAtType(conversationID),
+    ]);
   }
 
   export async function getCurrentUserId() {

package/src/translation/resources/i18n.ts

@@ -215,6 +215,12 @@ const i18nKey: Record<string, string> = {
   'group:dismiss_confirm_primary': 'Giải tán',
   'group:dismiss_confirm_secondary': 'Quay lại',
   'group:dismiss_toast_success': 'Đã giải tán nhóm',
+  'group:tag_title': 'Nhắc đến',
+  'group:tag_all': 'Tất cả',
+  'group:tag_all_desc': 'Nhắc đến tất cả thành viên',
+  'group:tag_no_member_found': 'Không tìm thấy thành viên nào',
+  'group:tag_limit_exceeded':
+    'Chỉ {{max}} người được nhắc đến đầu tiên sẽ nhận được thông báo',
   'group:access_blocked_title': 'Không thể xem cuộc trò chuyện này',
   'group:access_blocked_desc':
     'Bạn hiện không có quyền truy cập vào cuộc trò chuyện hoặc tin nhắn này.',

package/src/types/chat.ts

@@ -160,6 +160,12 @@ export interface DConversationQueryParams {
   pageSize: number;
 }
 
+export interface ISerializedMentionEx {
+  userID: string;
+  offset: number;
+  length: number;
+}
+
 export interface IMessageItemEx {
   applicationType: DChatApplicationType;
   sessionId?: string;
@@ -171,6 +177,22 @@ export interface IMessageItemEx {
   urlMetadata?: IUrlMetadata;
   flow?: IRunConversationFlowPayload;
   stickerId?: string;
+  /**
+   * @mention ranges, riding in this app-defined `ex` channel because
+   * OpenIM's own AtTextElem/AtMsgParams carry no per-mention offset/length
+   * — just a flat atUserIDList/atUsersInfo. Render logic prefers this
+   * (exact) and falls back to searching AtTextElem.text for
+   * "@{groupNickname}" per atUsersInfo entry when absent (interop safety
+   * net — see mentionSerializer.ts deserializeMentionRanges).
+   *
+   * Wrapped under `offsets` (not a bare array) to match the wire shape
+   * already sent by other Droppii clients (confirmed against a real
+   * message from the web/CRM client, `applicationType: "OBEFE"`:
+   * `ex.mentions = { offsets: [{userID, offset, length}, ...] }`). Offset
+   * units matched too (UTF-16 code units) — verified against a real
+   * Vietnamese-diacritic payload, no cross-client encoding mismatch.
+   */
+  mentions?: { offsets: ISerializedMentionEx[] };
 }
 
 export interface IGetMessagesParams {

package/src/types/mention.ts

@@ -0,0 +1,70 @@
+/**
+ * @mention composer types.
+ *
+ * All offsets throughout this module are raw JS string indices (UTF-16 code
+ * units) — the same unit RN's TextInput selection/cursor API uses on both
+ * platforms. This is a deliberate choice, not a default: it means offsets
+ * never need conversion at the RN boundary, at the cost of requiring
+ * surrogate-pair-aware handling wherever text is diffed (see mentionDiff.ts).
+ * AT Protocol-style byte offsets are unnecessary here because this data
+ * never crosses a non-JS boundary — see mentionSerializer.ts.
+ */
+
+export interface Selection {
+  start: number;
+  end: number;
+}
+
+/**
+ * A committed mention: created only by explicit picker selection
+ * (insertMention), never inferred from text content. [start, end) excludes
+ * the trailing separator space inserted after the display name — see
+ * insertMention's doc comment for why.
+ */
+export interface Mention {
+  id: string;
+  userId: string;
+  displayName: string;
+  start: number;
+  end: number;
+}
+
+/**
+ * The in-progress, uncommitted "@query" at the cursor. Freely editable
+ * character-by-character — never atomic, never promoted to a Mention except
+ * through explicit selection from the suggestion list.
+ */
+export interface ActiveMention {
+  trigger: '@';
+  start: number;
+  end: number;
+  keyword: string;
+}
+
+export interface MentionSuggestion {
+  userId: string;
+  displayName: string;
+  avatar?: string;
+}
+
+/**
+ * The boundary between Part A (composer, no concrete OpenIM dependency) and
+ * Part B (OpenIM SDK integration). Part A depends only on this type,
+ * injected; Part B's `openIMMentionSearchSource` (src/services/mentionSearch.ts)
+ * implements it against the real SDK. Defined here, in Part A's own types
+ * file, rather than in the Part B service file, so the dependency direction
+ * stays correct: Part A defines the contract, Part B implements it.
+ */
+export interface MentionSearchResult {
+  items: MentionSuggestion[];
+  /** True when `items.length === limit` — a same-size next page may exist. */
+  hasMore: boolean;
+}
+
+export interface MentionSearchSource {
+  search(params: {
+    keyword: string;
+    limit: number;
+    offset: number;
+  }): Promise<MentionSearchResult>;
+}

package/src/utils/mentionSerializer.ts

@@ -0,0 +1,155 @@
+import type { AtUsersInfoItem } from '@droppii/openim-rn-client-sdk';
+import type { ISerializedMentionEx } from '../types/chat';
+import type { Mention } from '../types/mention';
+
+/** Composer-internal marker for the "Tất cả" suggestion row / a committed
+ * "tag everyone" Mention — never sent on the wire, see AT_ALL_TAG below. */
+export const ALL_MEMBERS_USER_ID = 'ALL';
+
+/**
+ * OpenIM's own protocol sentinel for "everyone in the group", used inside
+ * atUserIDList in place of enumerating every member. Confirmed against
+ * openimsdk-core (pkg/constant/constant.go:242 — `AtAllString = "AtAllTag"`,
+ * exposed client-side as `GetAtAllTag()`) and openim-server's group-message
+ * send path (internal/rpc/msg/send.go's `setConversationAtInfo`), which
+ * special-cases exactly this string and does the "who is everyone right
+ * now" resolution itself, server-side.
+ *
+ * This is why "Tất cả" must serialize to this one token instead of
+ * expanding to every resolved member's userID client-side (the previous
+ * approach): the Go core's CreateTextAtMessage hard-rejects any
+ * atUserIDList longer than 10 entries regardless of group size
+ * (openimsdk-core/internal/conversation_msg/create_message.go:80-82) — a
+ * >10-member group's "Tất cả" silently failed to send at all. Sending just
+ * `[AT_ALL_TAG]` keeps atUserIDList small no matter the group size, and is
+ * also the behavior the protocol actually expects.
+ */
+export const AT_ALL_TAG = 'AtAllTag';
+
+/**
+ * OpenIM's Go core hard-rejects any AtMsgParams.atUserIDList longer than
+ * this (openimsdk-core/internal/conversation_msg/create_message.go:80-82,
+ * `if len(userIDList) > 10 { return nil, sdkerrs.ErrArgs }`) — not
+ * adjustable client-side. "Tất cả" no longer risks this (see AT_ALL_TAG),
+ * but tagging more than 10 *individual* members in one message still
+ * would, so serializeMentionsForSend caps atUserIDList/atUsersInfo at this
+ * count (keeping the first MAX_AT_USER_COUNT, in mention order) rather
+ * than letting the send fail outright the way "Tất cả" used to.
+ */
+export const MAX_AT_USER_COUNT = 10;
+
+export interface SerializedMentions {
+  atUserIDList: string[];
+  atUsersInfo: AtUsersInfoItem[];
+  exMentions: ISerializedMentionEx[];
+  /**
+   * True when more than MAX_AT_USER_COUNT distinct users were mentioned —
+   * atUserIDList/atUsersInfo were capped to the first MAX_AT_USER_COUNT (in
+   * mention order) so the send doesn't hit the Go core's hard rejection.
+   * `exMentions` is deliberately NOT capped: every mention still renders
+   * highlighted in the sent text (the sender sees what they typed), only
+   * native tag/notify is limited to the first MAX_AT_USER_COUNT. Callers
+   * use this flag to warn the user, not to block the send.
+   */
+  truncated: boolean;
+}
+
+/**
+ * Translates the composer's Mention[] (client-side ranges) into OpenIM's
+ * wire shapes for createTextAtMessage, plus our own ex.mentions channel. No
+ * group-member resolution needed here (or by the caller) any more — see
+ * AT_ALL_TAG's doc comment for why a "Tất cả" mention maps to that single
+ * sentinel rather than a per-member list.
+ */
+export function serializeMentionsForSend(
+  mentions: Mention[]
+): SerializedMentions {
+  const wireUserId = (m: Mention) =>
+    m.userId === ALL_MEMBERS_USER_ID ? AT_ALL_TAG : m.userId;
+
+  const exMentions: ISerializedMentionEx[] = mentions.map((m) => ({
+    userID: wireUserId(m),
+    offset: m.start,
+    length: m.end - m.start,
+  }));
+
+  // Map dedupes by userID — e.g. "Tất cả" and an individually-tagged member
+  // both present in the same message only produce one atUserIDList entry
+  // each, not duplicates. Insertion order == mention order, which is what
+  // makes "keep the first MAX_AT_USER_COUNT" below well-defined.
+  const nicknameByUserId = new Map<string, string>();
+  for (const m of mentions) {
+    nicknameByUserId.set(wireUserId(m), m.displayName);
+  }
+
+  const allEntries = [...nicknameByUserId.entries()];
+  const truncated = allEntries.length > MAX_AT_USER_COUNT;
+  const cappedEntries = truncated
+    ? allEntries.slice(0, MAX_AT_USER_COUNT)
+    : allEntries;
+
+  return {
+    atUserIDList: cappedEntries.map(([atUserID]) => atUserID),
+    atUsersInfo: cappedEntries.map(([atUserID, groupNickname]) => ({
+      atUserID,
+      groupNickname,
+    })),
+    exMentions,
+    truncated,
+  };
+}
+
+interface ReceivedAtTextElem {
+  text: string;
+  atUserList: string[];
+  atUsersInfo?: AtUsersInfoItem[];
+}
+
+/**
+ * Reverse of serializeMentionsForSend, for rendering a received/sent
+ * AtTextMessage (Phase B3). Prefers `exMentions` (exact, our own channel);
+ * falls back to searching `atTextElem.text` for "@{groupNickname}" per
+ * atUsersInfo entry when ex is absent — an interop safety net, not the
+ * primary path. The fallback is inherently ambiguous if a member's
+ * nickname coincidentally appears elsewhere in the message as plain text;
+ * accepted as a known, documented limitation (see the mention plan's
+ * finding #3) rather than something client code can fully resolve without
+ * position data from the protocol.
+ */
+export function deserializeMentionRanges(
+  atTextElem: ReceivedAtTextElem,
+  exMentions?: ISerializedMentionEx[]
+): Mention[] {
+  if (exMentions && exMentions.length > 0) {
+    return exMentions.map((e, index) => ({
+      id: `${e.userID}-${e.offset}-${index}`,
+      userId: e.userID,
+      displayName: atTextElem.text
+        .slice(e.offset, e.offset + e.length)
+        .replace(/^@/, ''),
+      start: e.offset,
+      end: e.offset + e.length,
+    }));
+  }
+
+  const nicknameByUserId = new Map(
+    (atTextElem.atUsersInfo ?? []).map((i) => [i.atUserID, i.groupNickname])
+  );
+
+  const mentions: Mention[] = [];
+  for (const userId of atTextElem.atUserList) {
+    const nickname = nicknameByUserId.get(userId);
+    if (!nickname) continue;
+    const needle = `@${nickname}`;
+    const start = atTextElem.text.indexOf(needle);
+    if (start === -1) continue;
+    mentions.push({
+      id: `${userId}-${start}`,
+      userId,
+      displayName: nickname,
+      start,
+      end: start + needle.length,
+    });
+  }
+  return mentions;
+}

package/src/utils/mentions/index.ts

@@ -0,0 +1,16 @@
+export { findActiveMention } from './mentionDetector';
+export {
+  diffTextChange,
+  snapBoundary,
+  type TextChangeDiff,
+} from './mentionDiff';
+export {
+  insertMention,
+  reconcileMentions,
+  normalizeDeleteRange,
+  applyTextChange,
+  type InsertMentionResult,
+  type ReconcileMentionsResult,
+  type ApplyTextChangeResult,
+} from './mentionRange';
+export { tokenize, type Segment } from './mentionTokenize';

package/src/utils/mentions/mentionDetector.ts

@@ -0,0 +1,58 @@
+import type { ActiveMention } from '../../types/mention';
+
+// No realistic @query is longer than this — caps the backward scan so the
+// common case (cursor nowhere near an '@') bails in O(word length), not
+// O(text length).
+const MAX_ACTIVE_MENTION_SCAN = 64;
+
+const isBoundaryChar = (ch: string) => /\s/.test(ch);
+
+/**
+ * Scans backward from `cursor` for an unclosed "@query" — the in-progress
+ * trigger that drives the suggestion list, not a committed mention.
+ *
+ * Only called for a collapsed cursor (selection.start === selection.end);
+ * the caller must resolve a range selection to `null` before calling this —
+ * a live "@query" only makes sense at a single insertion point.
+ *
+ * "@" itself counts as a boundary: the scan stops there whether or not it's
+ * a valid trigger, which is what prevents re-scanning back through an
+ * already-committed mention's "@Name " when the user starts typing a second
+ * "@" right after it (insertMention always appends a trailing space, a
+ * boundary char, so the previous mention's "@" is never reachable from the
+ * new query).
+ */
+export function findActiveMention(
+  text: string,
+  cursor: number
+): ActiveMention | null {
+  if (cursor <= 0 || cursor > text.length) return null;
+
+  let i = cursor;
+  let scanned = 0;
+
+  while (i > 0 && scanned < MAX_ACTIVE_MENTION_SCAN) {
+    const ch = text[i - 1] as string;
+
+    if (ch === '@') {
+      const before = i - 2 >= 0 ? text[i - 2] : undefined;
+      if (before === undefined || isBoundaryChar(before)) {
+        return {
+          trigger: '@',
+          start: i - 1,
+          end: cursor,
+          keyword: text.slice(i, cursor),
+        };
+      }
+      // '@' present but not at a valid boundary (e.g. "user@domain") — not a trigger.
+      return null;
+    }
+
+    if (isBoundaryChar(ch)) return null;
+
+    i--;
+    scanned++;
+  }
+
+  return null;
+}

package/src/utils/mentions/mentionDiff.ts

@@ -0,0 +1,95 @@
+// RN's onChangeText hands over only the new full string — no delta, no
+// info about what was inserted/deleted/replaced. A common-prefix +
+// common-suffix scan is the only viable way to localize the changed region,
+// and it's IME-safe for free: a Vietnamese diacritic recomposition (e.g.
+// "tie" + accent key -> "tiế") is just "two different strings" to this
+// algorithm, not a keystroke sequence it has to track.
+//
+// Assumes exactly one contiguous edit happened between the two strings —
+// true for every realistic single-field mutation (typing, backspace,
+// paste, autocorrect, IME composition). If that assumption is ever wrong
+// (some exotic keyboard rewriting two disjoint spans in one event), the
+// failure mode is safe-by-default: the computed region is a superset of
+// the true edits, so callers may over-invalidate mention ranges but never
+// corrupt them.
+
+const isHighSurrogate = (code: number) => code >= 0xd800 && code <= 0xdbff;
+const isLowSurrogate = (code: number) => code >= 0xdc00 && code <= 0xdfff;
+
+/**
+ * Snaps `index` so it never sits between a surrogate pair in `str` —
+ * without this, diffing e.g. "😀" vs "😁" (which differ only in their low
+ * surrogate) would compute a boundary that bisects the emoji. Snapping
+ * always shrinks the "common" region (treats one more code point as
+ * "changed"), which is always safe: being more conservative about what
+ * counts as touched only ever produces more mention-invalidation upstream,
+ * never corruption.
+ */
+export function snapBoundary(
+  str: string,
+  index: number,
+  direction: 1 | -1
+): number {
+  if (
+    index > 0 &&
+    index < str.length &&
+    isHighSurrogate(str.charCodeAt(index - 1)) &&
+    isLowSurrogate(str.charCodeAt(index))
+  ) {
+    return index + direction;
+  }
+  return index;
+}
+
+export interface TextChangeDiff {
+  /** [removedStart, removedEnd) in previousText coords — what was deleted. */
+  removedStart: number;
+  removedEnd: number;
+  /** [insertedStart, insertedEnd) in nextText coords — what was inserted. insertedStart === removedStart. */
+  insertedStart: number;
+  insertedEnd: number;
+}
+
+export function diffTextChange(
+  previousText: string,
+  nextText: string
+): TextChangeDiff {
+  const prevLen = previousText.length;
+  const nextLen = nextText.length;
+  const maxCommon = Math.min(prevLen, nextLen);
+
+  let prefixLen = 0;
+  while (
+    prefixLen < maxCommon &&
+    previousText.charCodeAt(prefixLen) === nextText.charCodeAt(prefixLen)
+  ) {
+    prefixLen++;
+  }
+  prefixLen = snapBoundary(previousText, prefixLen, -1);
+
+  // Clamp the suffix scan budget against what's left after the prefix —
+  // without this, a naive independent prefix+suffix scan can overlap on
+  // repeated-character edits (e.g. "aaa" -> "aaaa") and produce a
+  // negative-length "changed" region.
+  const maxSuffix = maxCommon - prefixLen;
+  let suffixLen = 0;
+  while (
+    suffixLen < maxSuffix &&
+    previousText.charCodeAt(prevLen - 1 - suffixLen) ===
+      nextText.charCodeAt(nextLen - 1 - suffixLen)
+  ) {
+    suffixLen++;
+  }
+
+  let removedEnd = prevLen - suffixLen;
+  let insertedEnd = nextLen - suffixLen;
+  removedEnd = snapBoundary(previousText, removedEnd, 1);
+  insertedEnd = snapBoundary(nextText, insertedEnd, 1);
+
+  return {
+    removedStart: prefixLen,
+    removedEnd,
+    insertedStart: prefixLen,
+    insertedEnd,
+  };
+}