docs(react-native): add AIO components guides

[konradgapinski]

Documents the React Native AIO components, which ship public in 8.7 with no guide. For most readers these pages are their first contact with the API.

Jira: SDC-33129 · Fix version 8.7.0-beta.1

What's here

A new AIO Components category in the React Native sidebar, with two pages.

aio/get-started.md — the linear path from an empty app to a working scanner: mounting ScanditProvider, adding a SparkScanAioView and handling results, camera position and torch, camera permissions, and the architecture support statement. The intro states that the components are available from 8.7.

aio/navigating-between-screens.md — the advanced page. Which views take a shared claim on the provider's camera and which one takes an exclusive claim, the navigation prop that suspends and resumes scanning on blur and focus, and the disabled / appStateHandlingDisabled props for when focus and foreground are not the whole story.

Decisions worth reviewing

Navigation earns its own page. A single scanning screen is straightforward; a second one is where applications go wrong, and the material did not fit the linear shape of a getting-started guide. Get Started summarises the handover in three sentences and links onward.

The navigation page leads with the navigation prop. Passing the screen's navigation object is the concrete answer to "how do I use two scanning screens", so the ownership model is explained around it rather than on its own. The example crosses SparkScanAioView (exclusive claim) to BarcodeCaptureAioView (shared), because that transition is the one that breaks.

No shared partial is imported. Nine of the eleven React Native get-started pages import _create-data-capture-context-react-native.mdx, which builds a DataCaptureContext by hand. That is the work ScanditProvider removes, so reusing it would contradict the guide.

Three things were deliberately left out. reset() is too specific for a getting-started reader and belongs on the view reference page. Passing application data between screens is not something the SDK provides — ScanditProvider shares the capture context and the camera, and the only React context in the packages is internal — so that guidance would be generic React advice under Scandit's name. And a separate ScanditProvider page was folded into Get Started once the reference page in SDC-33126 was accounted for.

Verification

• yarn build clean. onBrokenMarkdownLinks and onBrokenAnchors are both throw, so internal links and anchors between the two pages are verified.
• yarn docs:gate clean (Vale, cspell, frontmatter).
• Every identifier in every snippet is exported from the four RN packages' ts/index.ts on develop.
• Behavioural claims read from the implementation, not the TSDoc: the camera claim mode of all seven views, the nested-provider camera props, the frameSourceState claim release on unmount, and the Android/iOS split in useCameraPermission.

Note on links

The core/api/scandit-provider.html links point at the reference page added by SDC-33126, which is not merged yet. They resolve once it lands.

[github-actions]

PR Preview Action v1.8.1
Preview removed because the pull request was closed.
2026-09-14 11:31 UTC

[ilber]

🤖 Review pass with one lens: a React Native dev who has never touched a Scandit API. The prose is good and the ordering of the four steps is right. What I found splits into snippets that don't run as pasted, a few concepts that arrive before they're defined, and two things a first-timer will look for and not find. Inline below.

[ilber]

🤖 Follow-up pass on 94841c09 (the page split). The split is an improvement — the ownership model has its own page now, and the shared-vs-exclusive view list is the concrete detail the original was missing. Three new findings on navigating-between-screens.md below, same lens as before.

Two carry-overs worth noting rather than duplicating as new threads: LICENSE_KEY is now undefined in both files, and the new page has no prerequisites of its own despite importing @react-navigation/native and @react-navigation/stack — someone landing there from search has no install path at all. Both are covered by the existing open threads on get-started.

[konradgapinski]

🤖 All 18 open threads addressed in cdabaaf64. Grouped by what they were:

Snippets that did not run as pasted. LICENSE_KEY is declared in both files, with a line tying it to the dashboard or the test account already linked in Prerequisites. useEffect is imported in the permissions snippet. The torch example is now a TorchScreen component rendering the ScanScreen that exists on the page, instead of a bare JSX expression referencing something out of scope. The first scanning screen is mounted inside the provider, so step 2 ends in something runnable. Prerequisites names both Scandit packages and flags @react-navigation/native and @react-navigation/stack as not part of the SDK.

Terms used before they were defined. A new Calling the View Directly section introduces the handle through a ref, with an enable() / disable() example — so the term is defined on first use, and the navigation page links to it rather than assuming it. frameSourceState is removed from Get Started rather than introduced: no snippet on the page uses it, and the ScanditProvider reference covers it properly.

Framing. "Keep the frame alive" is replaced by what it buys the reader — doing asynchronous work such as a product lookup before the next scan is processed — with the async didScan example. The two symbologies are now named as common retail ones and linked to the Symbology reference.

Additions. A three-symptom Troubleshooting section: symbology not enabled, two views competing for the camera, and no permission dialog. An AIO-versus-classic sentence in the intro linking to the classic Barcode Capture guide. Where to Go Next now has four entries including the provider API reference and that classic guide.

On the disabled versus handle hazard, which asked what a reader would actually see. Read from useLifecycleHook: the effect that reacts to disabled runs only when disabled itself changes, while the focus and app-state handlers read its current value. So an imperative disable() is undone at the next focus or foreground event, because the prop still says enabled. That is now stated as the observable behaviour in a warning, rather than "can disagree".

One item is deliberately not done: linking the classic-versus-AIO comparison guide. That page is in flight under SDC-33130 and does not exist yet, and onBrokenMarkdownLinks is throw, so the link goes in when that lands. The intro links the existing Barcode Capture guide in the meantime.

[konradgapinski]

Heads-up: this is being reverted in #441, and not because of anything wrong with the content.

These pages document components that ship in 8.7, but docs/ is the current version and lastVersion is current, so merging published them immediately — roughly a month before the 8.7 beta. The pages describe an API readers cannot install yet.

Nothing is lost. The branch feature/SDC-33129 stays at cdabaaf64, and when the 8.7 beta publishes the content comes back by reverting #441 or by opening a fresh PR from that branch.