Uh oh!
There was an error while loading. Please reload this page.
docs(react-native): AI-agent docs layer — scoped LLM indexes, Quick References, and kit-vs-docs fixes (ENG-38205) - #476
Merged
Conversation
…e docs (ENG-38205) RN-G14 — the Podfile requirement that BREAKS EVERY FIRST BARE-RN INSTALL. The UI Kit is a Swift pod depending on SPTPersistentCache and DVAssetLoaderDelegate, neither of which defines a module, so on a static-library build — the React Native default — `pod install` fails outright. Both official sample apps already carry the two modular_headers lines; the integration page never mentioned them. Added, with the verbatim error so it is searchable, plus the LANG=en_US.UTF-8 note (CocoaPods dies with an opaque Encoding::CompatibilityError when the locale is unset, and the trace points at Ruby rather than at the real cause). RN-G8 — accordion coverage 91% -> 100% (55/55 pages). Added the AI Integration Quick Reference to call-features, calling-integration, campaigns, core-features and extensions. Each carries the trap for its area, not filler: core-features states reactions and mentions are CORE in v5 so enabling the legacy dashboard extensions is unnecessary; extensions states most render themselves once enabled so emitting client code duplicates them; calling-integration states that INSTALLING the package is the enable switch (there is no setCallingEnabled() in RN) and that simulators capture no camera or mic. RN-G11 — the events page named five APIs that do not exist as exports. CometChatMessageEvents -> MessageEvents (un-prefixed) · CometChatCallEvents -> CallUIEvents · CometChatGroupEventListener -> CometChatGroupsEvents (plural) · CometChatConversationEventListener -> CometChatConversationEvents · CometChatUserEventListener -> CometChatUIEvents. All five replacements verified present in the kit's public exports, and ccUserBlocked confirmed to live in CometChatUIEvents.ts before accepting that last mapping. RN-G9 (partial) — three docs-side import bugs fixed: mentions-formatter-guide imported TextStyle from the kit; it is a react-native type. Now imported from 'react-native'. call-logs imported CallLogRequestBuilder from the CHAT sdk. It lives in the CALLS sdk and is only reachable as CometChatCalls.CallLogRequestBuilder — wrong on both counts. ai-assistant-chat-history imported ChatHistoryStyle purely to annotate an object literal; dropped, the type is inferred. NOT fixed here — these are KIT bugs, not doc bugs. OutgoingCallConfiguration, EnterKeyBehavior, SingleLineMessageComposerConfiguration and CometChatReceipt are all DOCUMENTED public API that src/index.ts does not export. The docs describe the intended behaviour correctly; the barrel is incomplete. Deleting those sections would remove documented capability, and EnterKeyBehavior is a STRING ENUM so a literal will not type-check either — there is no doc-side workaround. Each needs a one-line export in the kit, which is a different repo and a public-API decision. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
…s schema The Quick Reference is the FIRST thing an agent reads when a skill fetches a page, so it has to carry that page's whole contract — not just a name list. The JavaScript SDK already does this (median 10 rows across its 20 documented pages); React Native's were a name list or a bare code snippet. 13 hot-path pages upgraded to the same field schema — Package · Import · Key methods · Key classes · Primary output · Prerequisites · Constraints · Listeners registered · Request builder · Related. RN SDK pages with a real contract table: 6 -> 16. Median rows: 5 -> 8. The two fields that were missing everywhere are the ones that matter most, and every value is verified against the installed .d.ts: Primary output — is it a Promise, what does it resolve to, what does it reject with. Without it an agent does not know to await, or what to catch. e.g. deleteMessage resolves a TOMBSTONE not void; getLoggedinUser returns User | NULL and null is the normal no-session answer; markAsRead is untyped; addMessageListener returns VOID, not a subscription. Constraints — what the API will NOT do, which a page cannot express by omission. e.g. there is no sendCardMessage() (card/interactive messages are receive-only, and an agent will infer one from the three send* methods that do exist); login is VARIADIC AND UNTYPED so TypeScript catches nothing; startTyping/endTyping return void so do not await them; blockUsers takes an ARRAY; reactions are core in v5 with no extension to enable; ban is half a round trip and needs BannedMembersRequestBuilder + unbanGroupMember shipped alongside it. Existing code snippets are preserved beneath each table — the table answers "what is the contract", the snippet answers "what does it look like". Zero phantom methods: every CometChat.* named in the new tables verified present in the SDK catalog. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
… JS SDK's schema" This reverts commit 604e898.
…g index Reverted the previous commit — it deepened the Quick References toward the JS SDK's full contract schema, which is the wrong direction. The Quick Reference's job is ROUTING, not documentation. Pages are long. An agent scans the accordion to decide "is the method I need on this page?" — if yes it opens the page, if no it moves to the next one. Making the accordion long forces the agent to read a long accordion instead of a long page, which saves nothing. Compact and COMPLETE beats rich and partial. So the real defect was never depth — it was MISSES. A method a page covers but does not list is invisible: the agent scans, does not see it, and moves on, even though the answer was right there. receive-messages was the worst — 7 methods covered but unindexed, including getMessageDetails and ALL FOUR unread-count variants. Anyone asking "how do I get the unread count" would have skipped the page that answers it. Fixed both shapes: 2 pages had a table whose Key Methods row was incomplete -> completed 30 pages had a SNIPPET-ONLY accordion with no index at all -> added a compact Key Methods + Key Classes index above the existing snippet SDK pages with a method index: 6 -> 36. Routing misses: 16 -> 0. init/login/logout/getLoggedinUser are deliberately excluded from non-setup pages: they appear in nearly every example as boilerplate, and indexing them everywhere would make the index useless. The index must say what a page is ABOUT, not what its example happens to call. Every method verified present in the SDK catalog; the original snippets are untouched beneath each index. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
…dexes Same fix as the SDK side, applied to the UI Kit: a component a page demonstrates but does not list in its Quick Reference is invisible — the agent scans the index, sees nothing, and moves to the next page even though the answer was there. 15 pages fixed. The biggest was component-styling, which styles 21 components and indexed none of them — anyone asking "how do I style the avatar / badge / action sheet" would have skipped the one page that answers it. Also fixed: components-overview (the component index itself did not list Conversations, MessageHeader or MessageList), the four formatter guides, and four task guides. Scaffolding is deliberately EXCLUDED from pages it is not about, exactly as init/login are on the SDK side. CometChatThemeProvider, CometChatI18nProvider, CometChatUIEventHandler, CometChatUiKitConstants and CometChatUIKit wrap or support nearly every example; indexing them everywhere would stop the index discriminating, which is the one thing it exists to do. Each is kept on the page that IS about it (theme, localize, events, methods, integration). 8 pages are left untouched by design: they use a JSON-format accordion whose `"component"` key already names the page's subject — CometChatConversations on conversations, CometChatMessageList on message-list, and so on. Their apparent "misses" are incidental example usage (an Avatar inside a custom-view sample), not what the page documents. Mutating structured JSON that may be parsed downstream is riskier than the routing benefit. Result: 32 pages were already complete, 15 fixed, 8 correct in a different format. Every component named is verified present in catalogs/rn-v5.json. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
…form The AI Integration Quick Reference is a routing index: the agent scans it to decide whether to open the page. 18 RN pages were carrying a shape that cannot serve that job. UI Kit (14) — replaced the JSON-blob accordion that docs#446 deleted from all 35 React component pages. Those blobs inlined the whole prop contract at 33-120 lines each, so there was nothing left to open the page for. Now a Field/Value table: Component, Package, Import, Data props, Primary output, Other actions, View slots, Styling, Prerequisites, Stitching -- names only, each linking into the section that holds the detail. SDK (4) — ai-agents, delivery-read-receipts, retrieve-group-members and additional-message-filtering carried code dumps instead of the field table their docs#466 twins use. Method and class names verified against the shipped RN SDK, not copied from JS: createUploadFileRequest/uploadAttachments do not exist in the RN SDK, so nothing from JS's upload-files table was reused. Also fixes ccCallFailled -> ccCallFailed in call-buttons, incoming-call and outgoing-call. All three shipped kits (5.3.0, 5.3.2, 5.3.4) emit ccCallFailed; the misspelling would have sent the agent looking for an event that is never fired. The v4 archive still carries it and was left alone. Conceptual pages (overview, key-concepts, rate-limits, upgrading-from-v3, message-structure-and-hierarchy, users-overview) were left untouched: docs#466 deliberately gives their JS twins no Quick Reference at all. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…References docs#466 puts a consistent ~10-row field set on all 19 JS SDK method pages. Ours had the right table form but a fraction of the rows: Package appeared on 1 page and Import on 0, against 19/19 in the reference PR. Import is the single row an agent most needs to write working code, so its absence defeated the routing index on every SDK page. Adds the three mechanical rows -- Package, Import, Prerequisites -- which carry the same value on every page and need no per-page judgement. Package and Import lead the table, matching #466's row order. setup-sdk and authentication-overview are skipped for Prerequisites: they are themselves the pages the row links to, and must not cite themselves. Still thinner than #466 and tracked separately: Primary output (4/38), Related (5/38), Constraints (0/38) and Full reference (0/38) each need per-page authoring rather than a mechanical fill. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…ference on 38 pages Completes the docs#466 field set. Package/Import/Key Methods tell an agent what to call; these four tell it what comes back, what will break, what to read next, and what the returned objects can do. Every return type is read from the shipped RN SDK's CometChat.d.ts, not carried over from the JS PR. That matters -- several are not what the JS docs would suggest: startTyping / endTyping / sendTransientMessage -> void, not Promise connect / disconnect / ping -> void getConnectionStatus -> string, synchronous markAsDelivered / markAsRead -> any, fire-and-forget leaveGroup / deleteGroup / kickGroupMember -> Promise<boolean> transferGroupOwnership / deleteConversation -> Promise<string> An agent that awaits a void return, or expects a message object back from markAsRead, writes code that silently does nothing -- which is exactly what the Primary output row now prevents. Constraints is the anti-hallucination row. send-message states plainly that sendCardMessage() does not exist (verified: 0 occurrences in the SDK; the real send methods are sendMessage, sendMediaMessage, sendCustomMessage, sendDirectMessage, sendGroupMessage, sendInteractiveMessage, sendTransientMessage), because an agent asked to send a card will otherwise invent it by symmetry. Two claims were corrected against the SDK before landing: GROUP_TYPE exposes four constants for three wire values -- PROTECTED and PASSWORD both resolve to "password" -- so create-group and groups-overview now say so rather than listing three types and leaving PROTECTED unexplained. All 143 rows verified: every /sdk/reference anchor resolves to a real heading and every Related link to a real page. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…ad prop message-list — new warning under "Filtering Messages". CometChatMessageList builds its request from the configured data source: requestBuilder.setTypes(ChatConfigurator.dataSource.getAllMessageTypes()); requestBuilder.setCategories(ChatConfigurator.dataSource.getAllMessageCategories()); so a custom type must be registered for FETCH, not only for render. Overriding getAllMessageTemplates alone gets a bubble that appears optimistically on send and vanishes on reload, with no error anywhere. Documents all four required overrides and the after-login() registration order (login() re-runs ChatConfigurator.init(), discarding any earlier data source). This was documented in no RN page and no React page. A real integration lost hours to it. users — removed `onBack` from the routing index and the prop list. The kit's CometChatUsers source contains zero occurrences of it; the callback never fires. Groups, Conversations, GroupMembers and CallLogs all DO have it, which is exactly why the claim looked plausible. Refs AUDIT-094 in the skills pack. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The previous commit added the render/fetch split to message-list under "Filtering Messages", but left the page's AI Integration Quick Reference unchanged -- so the routing index did not know the page now covered it. That defeats the index's whole purpose. An agent scans the Quick Reference to decide whether a page is worth opening; with no row for custom message types it would conclude the page has nothing and move on, which is the exact failure the new section exists to prevent. Adds a row naming all four required overrides, marking which two are render and which two are fetch, and pointing at the section. Lesson worth keeping: adding a capability to a page is not finished until the routing index announces it. Content the index does not mention is content the agent never reaches. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
RELEASE_GUIDE_CHAT_SDK.md and react-v6-vs-rn-v5-comparison.md were analysis notes produced while auditing the kit against the docs. They were swept in by an over-broad `git add` in e3f4318 and do not belong on the docs site: neither is referenced by docs.json or any page, so both are orphaned files sitting at the repo root, and a release checklist / a v6-vs-v5 comparison table are not customer documentation. Removing them from the PR. The analysis they hold is already reflected in the work itself -- the comparison drove the RN coverage decisions, and the release notes belong in the SDK repo, not here. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
ENG-38205 prerequisite. Two unlisted-but-indexed routing indexes for AI coding agents, following the React v7 / Angular v5 / JS SDK v4 precedent: - ui-kit/react-native/llms-react-native-v5.mdx (incl. Task guides (recipes)) - sdk/react-native/llms-react-native-v4.mdx Both cover every page in their directory (redirect stubs excluded) and add a "Platform rules" section for the React Native specifics an agent gets wrong by default: no CSS/DOM, required native peer deps, one screen per route, CLI vs Expo toolchains, and listener cleanup on the SDK side. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The first pass listed @gorhom/bottom-sheet + react-native-reanimated as required peers. They are not. Replaced with the list verified against @cometchat/chat-uikit-react-native@5.4.0 and the integration pages, and added the async-storage v3 Android local_repo Gradle gotcha to both. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
…gin API Two gaps in llms-react-native-v5, both found by asking what an agent searching for "add a custom message type" would actually match. 1. NOTHING TO MATCH. The index promises "pick the page for the intent", but every entry was a bare page name. The custom-message-type contract lives on Message List, and no agent scanning a list of component names would ever guess that. The index routed to all 55 pages and still could not answer the question. New "Customization & extensibility" section keyed on the API rather than the page title: DataSourceDecorator, ChatConfigurator.enable, the four required overrides split into render vs fetch, getMessageOptions/getAuxiliaryOptions, CometChatUIEvents. Now greppable by the terms someone would actually search. 2. THE BIGGEST API DIVERGENCE WAS UNSTATED. Platform rules covered CSS, peer deps, Gradle and navigation but never said React's CometChatMessagePlugin / CometChatPluginRegistry DO NOT EXIST here. An agent porting React knowledge emits them and does not compile. Added, with the decorator chain as the replacement and the after-login() registration order. Also carries the docs-gap note: DataSourceDecorator / MessageDataSource / ExtensionsDataSource still have no dedicated RN page (RN-G10). All links verified to resolve. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
raj-dubey1
left a comment
Contributor
There was a problem hiding this comment.
Docs review — React Native v5 AI-agent docs layer (ENG-38205)
Reviewed from the skills pack perspective against the React v7 reference (PR #446) and the Angular v5 reference (PR #471).
✅ What's correct and solid
llms-react-native-v5.mdx — "unlisted not hidden" pattern correct (explicit rationale comment in file, no hidden: true). Not in docs.json — matches the #446/#471/#466 precedent. All required sections present: Getting started, Core & config, Theming, Components, Calling, AI & notifications, Customization, Text formatters (RN-specific), Task guides (recipes) (present), Framework recipes, Migration. Two RN-specific sections beyond the React reference — "Platform rules — React Native is not the web" and "Text formatters" with the getAllMessageTypes/getAllMessageCategories four-override trap documented inline. Hot-path section present. All 15 docs gap findings are explicitly tracked in the PR description (RN-G10, RN-G15, etc.) — the self-disclosure is correct.
Kit-vs-docs corrections:ccCallFailed spelling fix across all three call pages is a real agent-facing breakage (the agent waited on an event that never fires). Dead onBack removed from users (not in source). Custom message types getAllMessageTypes/getAllMessageCategories fetch-side documented on message-list — this was silently breaking integrations. Event API name corrections (RN-G11). All four are genuine correctness fixes, not cosmetic.
Quick References (38 SDK + 14 UI Kit pages): Format is consistent and richer than the 10-field base schema. The viewSlots field with PascalCase names and the silent-failure note is exactly what agents need ("camelCase silently ignored"). The Package and Import fields are on all 38 SDK pages — the PR notes that Import was on 0 SDK pages before this, which is the single row an agent most needs to produce working code.
llms-react-native-v4.mdx (SDK) — present. Return types verified from CometChat.d.ts (startTyping/endTyping/connect/disconnect → void; getConnectionStatus → synchronous). These contradict what the JS docs suggest — critical to have correct for RN.
❌ One fix required before merge
conversations.mdx "Where It Fits" example teaches a broken RN layout
The example code in the conversations page's "Where It Fits" section uses a two-column flexDirection: "row" web layout with a fixed-width sidebar:
// sidebar: { width: 350, ... }// chatArea: { flex: 1, ... }<Viewstyle={{flexDirection: "row"}}><Viewstyle={styles.sidebar}><CometChatConversations.../></View><Viewstyle={styles.chatArea}>{/* message pane */}</View></View>This directly contradicts the one-screen-per-route capability in contracts.rn-v5.json and the core skill's golden path. On a phone-sized display this layout produces two ~175px columns — nothing is usable. An agent that reads this page and follows the example will produce an app that silently fails on any real device.
The correct RN pattern is a stack navigator:
// In conversations list screen<CometChatConversationsonItemPress={(conv)=>navigation.navigate('Chat',{user: conv.getConversationWith()asCometChat.User,conversationType: conv.getConversationType(),})}/>Fix this example to use the stack/tab navigation pattern (matching the ios-conversation and android-one-to-one-chat recipe guides) before merge. The Quick Reference accordion at the top of the page is correct — only the "Where It Fits" sample code below it needs to change.
⚠️ Tracked open items (not blocking merge after the above fix)
RN-G10 — no dedicated page for DataSourceDecorator / MessageDataSource / ExtensionsDataSource end-to-end. What's added here covers the half that silently breaks builds. The full surface remains undocumented. Filed, not blocking.
RN-G15 — CometChatOngoingCall is exported by the RN kit but has no RN-specific docs page. Correctly noted as out-of-scope for this PR.
Summary
The LLM index, SDK Quick References, and kit-vs-docs correctness fixes are well-formed and materially improve what agents can produce with RN. One fix is required before merge: replace the conversations.mdx two-column web layout example with the correct stack-navigator pattern. After that fix, this PR is ready to merge.
Uh oh!
There was an error while loading. Please reload this page.
anshuman-cometchat added a commit
to anshuman-cometchat/docs
that referenced
this pull request
Aug 25, 2026
Flutter was the only platform with none. On the skills-v5-temp base, react has 128 Quick References and 3 llms indexes, android 112/2, angular 81/1, react-native 56/2, ios 34/2 - and flutter 0 and 0. This closes the index half. Structure and conventions follow the reference PRs for the same feature: cometchat#446 (React v7), cometchat#466 (JS SDK), cometchat#471 (Angular v5), cometchat#476 (React Native). Unlisted rather than hidden, for the reason those PRs give: in Mintlify hidden auto-applies noindex, which would drop the page from search and from the auto global llms.txt - and the whole point is that an agent can discover it. Not registered in docs.json, same as every prior index. ui-kit/flutter/llms-flutter-v6.mdx 70 links, all 54 UI Kit pages sdk/flutter/llms-flutter-v5.mdx 58 links, all 52 SDK pages Both are 100 percent page coverage with zero dead links, verified by resolving every href against the tree. The Platform rules section is the part that carries real weight, and every claim in it was verified against cometchat_chat_uikit 6.1.0 rather than recalled: - TWO barrels with different surfaces. Chat widgets do not resolve from the calls barrel and vice versa, so a screen showing both imports both. This is the most common Flutter-specific compile failure. - Lists need a bounded box or layout throws at render, not at build. - Kit widgets paint their own surface; the app ThemeData does not reach inside. - Theming is ThemeExtension, and registering on only one of light/dark silently leaves the other on kit defaults. - v5's CometChatUIKit.getDataSource() is gone; v6 uses MessageTemplateUtils. - Custom message types need addTemplate, not templates - templates only registers the bubble and the message is filtered out before it can render, with no error. A hand-rolled MessagesRequestBuilder does not help because the list always overrides uid/guid/types/categories on it. - Messages sent with CometChat.send*Message must emit ccMessageSent or a mounted list never shows them. - SDK: onSuccess AND onError are both required - compile-checked, omitting onError is missing_required_argument. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
anshuman-cometchat added a commit
to anshuman-cometchat/docs
that referenced
this pull request
Aug 25, 2026
…ent pages Flutter had 0 of these while react has 128, android 112, angular 81, react-native 56 and ios 34. This closes the UI Kit half. Format follows the reference PRs (cometchat#446, cometchat#466, cometchat#471, cometchat#476): an Accordion straight after the frontmatter, a Field/Value table, and rows that let an agent decide whether the page is worth opening at all. Generated from the compiler-verified prop tables rather than hand-written, so every prop named here provably exists on the widget and the row cannot drift from the kit on the next release. 35 in-page anchors, all resolving. Two rows are Flutter-specific and are the reason a generic template would not have done: - Import carries the RIGHT BARREL per widget. Calling widgets resolve only from cometchat_calls_uikit.dart, so call-buttons, incoming-call, outgoing-call and call-logs also get an explicit Barrel row saying so. Importing a calling widget from the chat barrel is the most common Flutter compile failure and no other platform has this split. - Layout warns that list widgets fill their parent and need an Expanded or a sized box, because the failure is an unbounded-height throw at render rather than a build error. Plus the two traps found by building on the kit: message-list carries the addTemplate-not-templates rule, and message-composer carries the ccMessageSent requirement for messages sent outside it. Classification is by TYPE, not name, after three passes got it wrong: messagesRequestBuilder ends in Builder but is data, hideThreadView ends in View but is a bool toggle, headerView is a HeaderFooterBuilder typedef with neither Widget nor Function in its name, and onError is typed OnError? so only the on-plus-capital convention identifies it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
anshuman-cometchat added a commit
to anshuman-cometchat/docs
that referenced
this pull request
Aug 25, 2026
…Kit pages Correcting an earlier claim. I said the Quick Reference set was closed after the 14 component pages; rechecking against the platforms in the reference PRs shows it was not. Measured on CURRENT-version pages only - earlier counts were inflated by v4/v5 archive subdirectories that git grep matched recursively: ui-kit/react-native 56 of 56 sdk/react-native 44 of 54 ui-kit/ios 34 of 52 sdk/ios 52 of 61 ui-kit/android 33 of 62 sdk/android 46 of 55 ui-kit/react 29 of 40 ui-kit/flutter 14 of 54 <- lowest of any platform React Native has one on every single UI Kit page, guides and hubs included, so component-only coverage was not the convention. This takes flutter to 54 of 54. Non-component pages get page-appropriate rows rather than a fixed schema, which is what the other platforms do: guides name Key widgets, Init and Related; theming names the mechanism and its constraints; hub pages route. Classes and methods are extracted from each page's own fences and ranked by use, with a fallback to inline code spans for the seven hub pages that carry no fences at all - a stub block on those would have been worse than none. Six pages carry a hand-written row for something no extraction can know: theme-introduction and component-styling explain that a kit widget paints its own surface so the app ThemeData never reaches inside; message-template carries the addTemplate-not-templates rule; customization-datasource records that getDataSource is gone in v6; events carries the ccMessageSent requirement; and upgrading-from-v5 notes its Before snippets are v5 and are meant not to compile. 122 links and anchors across the 54 blocks, all resolving. Fence gate still clean at 355 analyzed, 0 kit-API errors. sdk/flutter stays at 38 of 52 by design: the 14 without a block are conceptual and hub pages, which cometchat#476 deliberately left alone on React Native for the same reason. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Everything React Native needs for the v5 skills pack to route through the docs. Combines what was previously split across #476 and #474 — one change, since the index and the pages it points at only work together.
Structure and conventions follow the reference PRs for the same feature: #446 (React v7), #466 (JS SDK), #471 (Angular v5).
1. Scoped LLM indexes
ui-kit/react-native/llms-react-native-v5.mdxsdk/react-native/llms-react-native-v4.mdxMirrors React's
llms-react-v7.mdxsection-for-section, plus two RN-specific ones — Platform rules — React Native is not the web and Text formatters. Not registered indocs.json: #446, #466 and #471 all leave it untouched, because the index is fetched by URL rather than navigated.2. AI Integration Quick References
The routing index an agent scans to decide whether a page is worth opening.
conversationsandmessage-listwent 120 → 19 lines.Packagewas on 1 page andImporton none — the single row an agent most needs to write working code.Conceptual pages (
overview,key-concepts,rate-limits,upgrading-from-v3,message-structure-and-hierarchy,users-overview) are deliberately left alone — #466 gives their JS twins no Quick Reference either.3. Fixes found by auditing the kit against the docs
Every symbol verified against the shipped RN kit and SDK, never carried over from JS:
ccCallFailled→ccCallFailedoncall-buttons,incoming-call,outgoing-call. All three shipped kits (5.3.0/5.3.2/5.3.4) emitccCallFailed; the misspelling had the agent waiting on an event that never fires.onBackremoved fromusers—CometChatUsers's source contains zero occurrences. Groups, Conversations, GroupMembers and CallLogs all do have it, which is exactly why the claim looked plausible.message-list.CometChatMessageListbuilds its request fromgetAllMessageTypes()/getAllMessageCategories(), so overridinggetAllMessageTemplatesalone renders a bubble that vanishes on reload — no error anywhere. Documented in no RN page and no React page; a real integration lost hours to it.modular_headers, RN-G8 accordion coverage, RN-G9 import corrections, RN-G11 five wrong event API names.Return types come from the SDK's own
CometChat.d.ts— several are not what the JS docs would suggest:startTyping/endTyping/sendTransientMessage/connect/disconnectreturn void,getConnectionStatusis synchronous,markAsDelivered/markAsReadare fire-and-forget.Verification
/sdk/reference/anchor resolves to a real heading; every Related link to a real page; every index link resolves.Still open (owner: docs)
DataSourceDecorator/MessageDataSource/ExtensionsDataSourceremain undocumented end to end. What's added here covers the half that silently breaks builds, not the whole surface.CometChatOngoingCallis exported by the RN kit and documented for React, but no RN page covers it.Supersedes #474.