@droppii-org/chat-mobile 0.2.80 → 0.2.82

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 {
@@ -341,3 +363,33 @@ export interface ISearchMessageItem {
   chatLog: MessageItem;
   conversation: ConversationItem;
 }
+
+export enum ContactCategory {
+  Customer = 'CUSTOMER',
+  Pdp = 'PDP_BOT',
+  Group = 'GROUP',
+  Seller = 'USER',
+}
+
+export type IContactSearchRequest = {
+  applicationType: DChatApplicationType;
+  searchTerm: string;
+  page: number;
+  pageSize: number;
+  type?: ContactCategory;
+};
+
+export interface IContactSearchItem {
+  id: string;
+  type: ContactCategory;
+  targetUserId?: string;
+  targetCustomerId?: string;
+  targetGroupId?: string;
+  targetBotId?: string;
+  targetName: string;
+  targetAvatar?: string;
+  applicationType: DChatApplicationType;
+  lastOnlineTime?: string;
+  memberCount?: number;
+  description?: string;
+}

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/dateTimeUtils.ts

@@ -2,6 +2,12 @@
  * Date and time formatting utilities
  */
 
+import dayjs from 'dayjs';
+import relativeTime from 'dayjs/plugin/relativeTime';
+import 'dayjs/locale/vi';
+
+dayjs.extend(relativeTime);
+
 export const formatDuration = (durationMs: number): string => {
   // Convert milliseconds to seconds
   const totalSeconds = Math.floor(durationMs / 1000);
@@ -46,3 +52,12 @@ export const formatTimestamp = (ts: number | string | null): string => {
     return '';
   }
 };
+
+export const formatLastOnlineTime = (ts: number | string | null): string => {
+  if (!ts) return '';
+
+  const date = dayjs(ts).locale('vi');
+  if (!date.isValid()) return '';
+
+  return date.fromNow();
+};

package/src/utils/highlightSearch.ts

@@ -4,6 +4,16 @@ export interface HighlightResult {
   after: string;
 }
 
+// Strips Vietnamese diacritics one base-character-at-a-time (NFD decomposition +
+// combining-mark removal, plus đ/Đ which NFD doesn't decompose) so the result stays
+// the same length and index-aligned with the input
+const stripDiacritics = (input: string): string =>
+  input
+    .normalize('NFD')
+    .replace(/[\u0300-\u036f]/g, '')
+    .replace(/đ/g, 'd')
+    .replace(/Đ/g, 'D');
+
 export const highlightSearch = (
   text: string,
   keyword: string,
@@ -11,8 +21,8 @@ export const highlightSearch = (
 ): HighlightResult | null => {
   if (!keyword) return null;
 
-  const lowerText = text.toLowerCase();
-  const lowerKeyword = keyword.toLowerCase();
+  const lowerText = stripDiacritics(text.toLowerCase());
+  const lowerKeyword = stripDiacritics(keyword.toLowerCase());
   const index = lowerText.indexOf(lowerKeyword);
 
   if (index === -1) return null;

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,
+  };
+}