Skip to main content

React Native project requirements

The library requires React Native 0.85.3+ with a react version that satisfies React Native’s declared peer dependency (^19.2.3 for react-native@0.85.3). Also requires Node ≥ 24.0.0 and npm ≥ 11.0.0.
To install the npm libraries provided by FlowX.AI you will need access to the private FlowX.AI Nexus registry. Consult your project DevOps.
react must satisfy React Native’s published peer dependency. For react-native@0.85.3 this is ^19.2.3; newer RN 0.85.x patches may shift it — check with npm view react-native@<your-version> peerDependencies. Installing React Native via the official template (Bare CLI) or Expo SDK 56 picks a compatible react automatically — don’t override it with a manual pin unless you have a reason.

Installation

For new projects, bootstrap with the official React Native template so react and react-native ship as a matched pair that satisfies the peer dependency in the Warning above:
For existing projects, ensure react already satisfies your installed react-native’s declared peer (npm view react-native@<your-version> peerDependencies) before installing the FlowX SDK.Then install the FlowX SDK and peers:
Replace <version> with the correct version corresponding to your platform version.To find the right version, navigate to: Release Notes → Choose your platform version → Deployment guidelines → Component versions.
Then install iOS pods:
Some peer dependencies require additional setup beyond npm install: Babel plugins, Expo config plugins, native project edits (Podfile, styles.xml, AndroidManifest.xml), or app-root providers. Check each library’s install guide and apply its setup steps. Examples: react-native-worklets needs a Babel plugin (see below), react-native-keyboard-controller needs an Expo config plugin in managed projects, and react-native-screens / react-native-safe-area-context rely on autolinking plus the providers shown later in this page.

Babel plugin

react-native-worklets/plugin must be the last plugin in your Babel config.
No manual config needed. babel-preset-expo (SDK 54+) auto-adds the worklets plugin when react-native-worklets is in node_modules.

Android Material 3 date picker (opt-in)

FlxDatePicker on Android renders the legacy AppCompat calendar by default. To use the Material 3 picker, the host app’s AppTheme must inherit from a Material 3 parent and the toolkit runtime flag material3 must be true. With the flag off, the legacy calendar renders and the theme change is irrelevant.
Register the @flowx/react-native-ui-toolkit config plugin. It rewrites AppTheme to a Material 3 parent and injects extra.flxUiToolkit.material3 = true into the app config, so no JS opt-in is needed:
Then run npx expo prebuild --clean --platform android.
The toolkit reads the injected extra.flxUiToolkit.material3 value at runtime through expo-constants, which is already present in every Expo project. No JS opt-in call is needed.
No Gradle changes required. com.google.android.material:material is already on the classpath via androidx.appcompat. Skip both steps and FlxDatePicker keeps rendering the legacy calendar with no crash.

App-root providers

The renderer expects safe-area and keyboard providers above it in the tree:
The SDK mounts its own NavigationContainer internally, wrapped in NavigationIndependentTree. A host NavigationContainer is not required. If your app already uses @react-navigation/native, keep its NavigationContainer at the root. The SDK’s internal navigator stays isolated from it.

Authorization

The client app implements the authorization flow (using the OpenID Connect standard). The SDK expects a bearer token to be set via FlowX.setAccessToken(token) before starting a process.
Call setAccessToken again whenever the token is refreshed.

Configuring the SDK

FlowX.configure(cfg) sets global SDK config. Call it once at app bootstrap, before starting any process.

FlxConfig parameters

Starting a process

FlowX.startProcess(opts) starts a new process instance and returns a FlxProcessHandle. The handle exposes a ProcessView component that you mount inside a screen.

StartProcessOptions

Getting the process identifier

Open the FlowX Designer, navigate to the process, and copy the process name from the breadcrumbs. Use this value as processName.

The process handle

startProcess resolves to a FlxProcessHandle:
To capture the running instance UUID, pass an onProcessStarted callback to startProcess; it receives the new processInstanceUuid. The handle itself does not expose it.
Always call handle.dispose() when the host screen unmounts. Skipping it leaks SDK store state into the next process.

Resuming a process

FlowX.continueProcess(opts) resumes an existing process instance instead of starting a new one. Pass the processInstanceUuid of the instance you want to reattach to. Like startProcess, it resolves to a FlxProcessHandle you mount through its ProcessView.

ContinueProcessOptions

continueProcess reattaches to an already-started instance, so it takes no processName, params, or onProcessStarted. Those apply only when starting a new process. Configure the SDK with FlowX.configure(...) and set the access token before calling it, exactly as for startProcess.

Custom components

Register host-authored custom components through the components field of FlowX.configure(...). Each key is the component identifier defined in the FlowX process; the value is the React Native component that renders it. The registration is read when the process view mounts, so configure the SDK before starting or continuing a process.
The keys in the components object MUST match the custom component identifiers defined in the FlowX process.
React Native supports self-managed custom components only: components you author in your app and register by identifier. Bundled custom components (source compiled from the backend at runtime) are browser-only; on React Native they are skipped and a warning is logged in development. Re-author any bundled component as a self-managed one.

Component contract

Each custom component receives the same contract as the React SDK:
Process data mapped through inputKeys is available on input.data. Process actions are available on input.actionsFn, keyed by action name; calling one triggers the process action and returns a Promise that resolves when it completes.

Example

Make sure any action names you call through input.actionsFn match the process action names bound to the component in the FlowX Designer.

Custom validators

Define custom validators on your form fields in the FlowX Designer, then pass their implementations through the validators field of FlowX.configure(...). The SDK honors the error messages configured on each field in the process. Each key in the validators object is the validator name referenced in the Designer; the value is a factory that receives the validator’s configured params and returns the predicate the SDK runs against the field value. Return true to pass or false to fail. When it fails, the message configured on that validator in the Designer is shown.
The keys in the validators object MUST match the custom validator names defined in the FlowX process. If a field references a validator name that is not registered, the SDK logs Custom validator <name> not found and skips it.

Example

Full example

Last modified on July 15, 2026