Merge pull request #315 from flashcatcloud/doc-review/20260826-082500

docs(rum): React Native coverage + Issue CSV export (doc-review 2026-08-26)

Author: ysyneu

en/changelog/changelog.mdx

@@ -4,6 +4,27 @@ description: "This page documents important updates and feature releases for Fla
 keywords: ["Changelog", "Product Release", "Feature Updates", "Flashduty", "Version History"]
 ---
 
+<Update label="2026-08-26" description="📱 React Native RUM support and Issue export">
+
+### React Native app support
+
+RUM adds a **React Native** app type with the full integration path:
+
+- React Native can be selected when creating an app; the SDK config page offers a four-step wizard: install `@flashcatcloud/mobile-react-native` (plus the view-tracking package for your navigation library), configure Metro with `withDatadogMetroConfig` (stamps a Debug ID into the bundle and its sourcemap for exact stack matching), initialize the SDK (`serviceName` is required to keep Android and iOS under one service), and enable automatic view tracking
+- Source Maps adds a React Native tab: Android uploads the sourcemap automatically during the release build via the SDK's bundled Gradle script, iOS uploads manually with `flashcat-cli sourcemaps upload-react-native`; the two platforms' sourcemaps are stored separately, so same-named bundles never conflict
+- The Native dashboard adds a **JS Thread Frame Rate (P75)** metric plus JS frame rate (average/minimum) columns in view performance detail and smoothness analysis, reflecting jank in the business JavaScript layer directly
+- React Native native crashes (Android/iOS/NDK) are grouped and symbolicated by their real platform, like Flutter
+
+### Export Issues as CSV
+
+The Issue list in Error Tracking adds **CSV export**:
+
+- Exports exactly the rows and columns matching the current filters and sort order, capped at 100 rows per export
+- Optionally includes error sample columns (on by default) and the earliest sample columns (off by default); time column headers carry the timezone for easy sorting
+- Sample stacks are truncated to 20 lines and exported without symbolication; the export guards against spreadsheet formula injection
+
+</Update>
+
 <Update label="2026-08-20" description="☁️ Tencent Cloud CLS data source and mobile War Room support">
 
 ### Tencent Cloud CLS data source

en/rum/analytics/native.mdx

@@ -50,6 +50,7 @@ The top section displays P75 percentile values for four key performance metrics:
 - **Frame Rate (P75)**: Display the P75 percentile of runtime frame rate to measure visual smoothness. Target is 60fps; higher values indicate smoother interactions. The SDKs normalize per-frame samples from high-refresh-rate screens (ProMotion, 120Hz Android devices) to a 60fps baseline and cap them at 60, so this metric reflects relative smoothness rather than the display's physical refresh rate.
 - **CPU Usage (P75)**: Track the P75 percentile of CPU utilization to identify compute-intensive operations. High CPU usage leads to device heating and increased battery drain.
 - **Memory Usage (P75)**: Monitor the P75 percentile of app memory usage to detect memory leaks or abnormal growth early.
+- **JS Thread Frame Rate (P75)**: Monitor the P75 percentile of the React Native JS thread's frame rate (FPS). Compared with the native frame rate, it reflects jank caused by business JavaScript more directly (re-renders, synchronous work on the bridge). Reported only by the React Native SDK.
 
 #### App Startup Time Analysis
 
@@ -63,6 +64,7 @@ Performance metrics by view name (Page/Activity/ViewController):
 - **Visit Count**: Shows visit volume for each view to identify high-frequency core pages.
 - **Startup Time**: Monitor loading duration for each view to locate slow-loading pages.
 - **Frame Rate**: Track runtime frame rate performance for each view to identify rendering issues.
+- **JS Thread Frame Rate**: Track each view's React Native JS thread frame rate (FPS) to spot business-JavaScript jank; reported only by the React Native SDK, so this column is empty for other platforms' views.
 - **CPU Usage**: Statistics of CPU utilization for each view to optimize compute-intensive pages.
 - **Memory Usage**: Monitor memory usage for each view to detect memory leak risks.
 
@@ -74,6 +76,8 @@ App smoothness metrics by view name:
 - **Frozen Frames**: Count of single main-thread tasks running longer than 700ms, which leave the UI completely stuck and unresponsive.
 - **Long Tasks**: Count of main-thread tasks running past the threshold (100ms by default on both Android and iOS, configurable), used to locate performance bottlenecks. Long tasks block user interactions and UI updates.
 - **Freeze Frequency**: Frozen frames per second of view time (frozen frames / time spent), evaluating overall smoothness performance.
+- **JS Frame Rate (Average)**: The average JS-thread frame rate across that view's updates; highlighted below 50 FPS. Reported only by the React Native SDK.
+- **JS Frame Rate (Minimum)**: The lowest JS-thread frame rate recorded in any single update of that view — the worst jank a user encountered; highlighted below 30 FPS. Reported only by the React Native SDK.
 
 <Warning>
 **Frozen Frames, Long Tasks and Freeze Frequency all come from one source.** On mobile, frozen frames are not counted from rendered frames — they are the subset of long tasks running past 700ms, and Freeze Frequency is derived from the frozen-frame count. So once long-task collection is disabled in the SDK, all three columns sit at **0 at the same time** — meaning "not measured", not "no freezes".
@@ -508,6 +512,7 @@ Flashduty RUM typically completes data collection and display within **1-3 minut
 | CPU Usage | view_cpu_ticks_per_second | Below 40 ticks/s | Below 60 ticks/s | 60 ticks/s or above |
 | Memory Usage | view_memory_average | Below 100 MB | Below 200 MB | 200 MB or above |
 | Peak Memory | view_memory_max | Below 200 MB | Below 400 MB | 400 MB or above |
+| JS Thread Frame Rate | view_js_refresh_rate_avg | 55 FPS or above | 50 FPS or above | Below 50 FPS |
 
 ### Smoothness Metrics
 
@@ -517,6 +522,8 @@ Flashduty RUM typically completes data collection and display within **1-3 minut
 | Frozen Frames | Count of single main-thread tasks over 700ms; stays 0 when long-task collection is disabled | view_frozen_frame_count |
 | Long Tasks | Count of main-thread tasks past the threshold (100ms by default, configurable) | view_long_task_count |
 | Freeze Frequency | Frozen frames divided by view time, i.e. average freezes per second | - |
+| JS Frame Rate (Average) | The average JS-thread frame rate across that view's updates; highlighted below 50 FPS; reported only by the React Native SDK | view_js_refresh_rate_avg |
+| JS Frame Rate (Minimum) | The lowest JS-thread frame rate recorded in any single update of that view, i.e. the worst jank a user encountered; highlighted below 30 FPS; reported only by the React Native SDK | view_js_refresh_rate_min |
 
 ### Stability Metrics
 

en/rum/error-tracking/error-aggregation.mdx

@@ -22,6 +22,8 @@ When a new error event occurs, Flashduty uses a three-step aggregation strategy
 
     **Flutter native crashes are handled by their real platform:** Native crashes reported by a Flutter app carry `source` = `flutter`; during grouping the real platform is resolved from `source_type` (`ndk`, `android`, `ios`). Crashes whose `source_type` is `ndk` (or whose stack contains application-layer native frames) behave exactly like Android NDK crashes — they skip ML similarity analysis and group by the native-frame fingerprint. Crashes whose `source_type` is `ios` still group by the message fingerprint, the same as a standalone iOS app.
 
+    **React Native native crashes follow the same rule:** Native crashes reported by a React Native app carry `source` = `react-native` and are likewise resolved to the real platform by `source_type` (`ndk`, `android`, `ios`) — `ndk` (or stacks containing application-layer native frames) skip ML similarity analysis and group by the native-frame fingerprint; `source_type` = `ios` groups by the message fingerprint, the same as a standalone iOS app. JS errors carry `source_type` = `react-native` (or empty) and keep their `react-native` identity for grouping and JS fingerprinting.
+
     **Electron process-gone events skip similarity analysis:** Electron process-gone events (whose `error.type` is `RenderProcessGone` or `ChildProcessGone`) also skip ML similarity analysis and group solely by the deterministic fingerprint (error type + message). Every process-gone event reads `<process> process gone: <reason>` (for example `Renderer process gone: killed`), so any two events differ by a single token; similarity grouping would incorrectly merge unrelated failures such as "killed" and "launch-failed" into one Issue. The deterministic fingerprint keeps them separate by exit reason.
     </Note>
   </Step>

en/rum/error-tracking/error-viewing.mdx

@@ -96,6 +96,30 @@ For regression-related transition logic, please refer to [Issue Status](./issue-
   </Tab>
 </Tabs>
 
+## Export Issues
+
+The **CSV** export button at the top right of the Issue list exports data that matches the list's current filters and sort order.
+
+After clicking the CSV button, you can choose what to include in the export popover:
+
+| Option | Default | Description |
+|--------|---------|-------------|
+| Include error samples | On | Attaches the most recent error sample columns to each Issue (time, version, view, session ID, device, OS, browser, stack), prefixed `sample_` |
+| Also include the earliest sample | Off | Additionally attaches the earliest error sample columns (`sample_first_*`), useful for finding the version a problem first appeared in. Only selectable while "Include error samples" is on |
+
+<Note>
+Error samples only exist within the error data retention window; older Issues export with empty sample columns.
+</Note>
+
+The export always includes the Issue's 18 fields (Issue ID, Issue URL, Application, Service, Error type, Error message, Status, Severity, Is crash, Error count, Affected sessions, First seen, First seen version, Last seen, Last seen version, Versions, Suspected cause, Resolved at); the sample columns are appended when "Include error samples" is enabled.
+
+<Warning>
+- A single export is capped at **100 rows**. When more than 100 Issues match, a tooltip on the button says "At most 100 rows can be exported. Narrow the time range or add filters."; if the exported file was truncated, the page shows a toast with the exported count.
+- Time columns (First seen / Last seen / Resolved at / sample time) carry the timezone in the header (e.g. `First seen (Asia/Shanghai)`) with cell values as `YYYY-MM-DD HH:mm:ss` text in that timezone, so spreadsheets sort them as dates.
+- Sample stacks are truncated to the first 20 lines. Full stacks are available in the Issue detail (where they are symbolicated per platform); the export contains the raw frames as reported, without symbolication.
+- To prevent formula injection, cells starting with `=`, `+`, `-`, or `@` are prefixed with a quote.
+</Warning>
+
 ## Error Cause Classification
 
 Flashcat adds an error cause classification to each Issue when created, helping improve fault localization efficiency.
@@ -229,6 +253,10 @@ Click any Issue to open the details panel and view more information.
 
     Flutter native crashes (with `source_type` of `ndk`, `android`, or `ios`) carry thread stacks and Binary Images, and are rendered with the same native view described above as Android/iOS native crashes. Dart exceptions are symbolicated by matching the build_id in the stack against uploaded Flutter symbol files.
 
+    **React Native Support**
+
+    React Native has the same shape as Flutter: JS errors render as Web stacks and are symbolicated against uploaded JS sourcemaps, while native crashes (with `source_type` of `ios`, `android`, or `ndk`) carry thread stacks and Binary Images and are rendered with the native stack view described above, symbolicated via dSYM / NDK symbol files like standalone Android/iOS crashes. JS error sourcemap lookup is scoped to the `react-native` type and further narrowed by the platform derived from the error's OS (`os_name`) — iOS and Android bundles may share a file name, and the platform scoping prevents matching the other side's file.
+
     **Electron Support**
 
     Electron errors are routed by type: main-process and renderer JavaScript errors are V8 stacks and render exactly like browser errors in the Web stack view (original source is restored once a source map is uploaded), while minidump native crashes are address-style native stacks (with threads and `binary_images`) rendered in the native stack view above — uploading matching Breakpad symbols restores function names, file names, and line numbers. See [Electron error symbolication](../sdk/electron/error-symbolication).