@truconsent/consent-notice-react-native
v0.1.10
Published
React Native SDK for TruConsent consent banner
Readme
@truconsent/consent-notice-react-native
React Native SDK for TruConsent consent banner. This package provides native mobile UI components for displaying and managing consent banners in React Native applications.
Changelog
0.1.10
- Added Rights Center nominee OTP verification: a submitted/updated nominee now starts "Not verified yet" and can't be treated as active until the user verifies them (OTP today, via the backend's
send-otp/verify-otpendpoints; DigiLocker shown as a disabled "Coming Soon" option). AddssendNomineeOtp/verifyNomineeOtptoRightsCenterApi, astatus/verification_methodfield onNominee, and a verify modal (choose-method → 6-digit OTP, reusing this SDK's existing non-SSO-OTP single-input pattern and 30s/3-resend cooldown convention) inNativeRightCenter's Nominee tab. Matches@truconsent/consent-notice0.0.40/0.0.41 and truKIT-flutter-sdksendNomineeOtp/verifyNomineeOtp's request shape (URL/method/body) and error handling are unit-tested in__tests__/RightsCenterApiAuth.test.ts(mockedfetch, same pattern as the existing non-SSOsendOtp/verifyOtptests). This repo has no working component-render test infrastructure (@testing-library/react-nativeisn't wired up, and this repo's own Jest config replacesreact-nativewith a hand-written mock and runs undertestEnvironment: 'node', not jsdom — a deliberate, pre-existing setup, not an oversight), so the Nominee tab's UI state machine itself (step transitions, cooldown, re-render on verified) is verified by code parity with truKIT-flutter-sdk's identical logic, which was exercised end to end there, rather than by a render test here
- Fixed
Reject Allincorrectly triggering the H-Case "Consent Required" warning popup whenever any mandatory purpose was configured (the common case) —handleRejectAllbuilt a synthetic all-declined purposes array and ran it through the same mandatory-decline intercepthandleAcceptSelected/"I Consent" uses, which always found the mandatory purpose "declined" in that array and blocked the action. Reject All is a deliberate, explicit decline of everything (mandatory included); it no longer runs through the intercept at all - Fixed
HCaseWarningModal(the "Consent Required" popup) rendering with a fixed white background, black title, and grey message text regardless of the notice's configured theme — now defaults to the samebannerTheme(background/text/textMuted/buttonText)BannerUIandModernBannerActionsalready render with, so it always matches the configured colors. Admin-configuredh_case_*color overrides still take priority when set - Fixed the same popup's proceed button silently using the modal's Background Color as its own background whenever
h_case_proceed_button_colorwasn't explicitly configured — the fallbackprimaryColorprop resolved to Background Color, not Button Color, despite its name; now resolvesbannerTheme.buttoninstead. Matches@truconsent/consent-notice0.0.40
0.1.9
- Fixed
I Consentstaying enabled (and clickable) even when the user switched a Necessary/mandatory purpose's toggle off. Necessary toggles stay interactive by design — the user can still switch one off — but doing so must disable the "I Consent" action itself; only Reject All / Only Necessary remain available at that point, matching the existing H-Case warning popup's own definition of "mandatory purpose declined". Matches@truconsent/consent-notice0.0.38
0.1.8
- Fixed
I Consentbeing disabled whenever every optional purpose was declined, requiring at least one optional acceptance on top of the normal scroll-gating — Reject All and Only Necessary never had this extra requirement. Optional purposes are the user's free choice to accept or decline;Only Necessaryalready exists as the dedicated "decline everything optional" action, so gatingI Consenton an optional acceptance just made it redundant withOnly Necessaryand confusingly disabled in the all-declined state - Fixed the Consent tab's purpose groups rendering in
Necessary → Optional → Profile Basedorder — nowNecessary → Profile Based → Optional, matching@truconsent/consent-notice0.0.37
0.1.7
- Changed the Tabbed Banner's active tab label and underline to use Primary Text Color (
theme.text) instead of Button Color (theme.button) — Button Color is picked for contrast against a button's own background, not the banner's background, so a light banner paired with a bright accent Button Color read as low-contrast for the active tab. Primary Text Color is guaranteed legible against the banner's own background. Matches@truconsent/consent-notice0.0.36 and truKIT-flutter-sdk
0.1.6
Three-way parity audit against @truconsent/consent-notice (the reference web SDK) — Consent Notice, Rights Center, and their underlying logic, not just appearance:
- Fixed
ModernBannerActions's "Only Necessary" button disappearing once any optional purpose was toggled on, and its default colors not matching the reference (Reject All/Only Necessary are now always-visible, solid red/orange buttons; the third button dynamically submits "Accept All" or "Accept Selected" without ever changing its own label) - Fixed "I Consent"/Reject All/Only Necessary being clickable immediately, without the user having scrolled through every purpose card first — they're now gated on scroll position (skipped only when there's a single optional purpose), matching the reference exactly, including the "Please scroll to the bottom to enable actions" warning text
- Fixed Legitimate Interest purposes (no toggle, no accept/decline concept) being counted as "optional purposes" in that same gating logic — a banner mixing Legitimate Interest + mandatory + exactly one real optional purpose could leave "I Consent" permanently disabled
- Fixed the toggle switch rendering nothing at all for Legitimate Interest purposes now excluded consistently from every place that checks "any optional purpose accepted"
- Fixed the Data Processors section splitting Legal Entities/Tools into two separately-labeled subsections instead of one flat combined list
- Fixed the consent notice's disclaimer box being hardcoded blue regardless of the configured theme — now derived the same way the reference SDK's fixed light/dark presets are, based on whether the configured background is light or dark
- Added the missing Grievance chat header Open/Resolved status pill (Rights Center)
- Fixed the toggle switch thumb using the Primary Text Color instead of the Primary Button Text Color
- Fixed the footer's inline links using the button color instead of the primary color
- Fixed the purpose card's expiry label showing a fabricated "1 Year" default (and sometimes a raw UUID) instead of "Until withdrawn"
- Fixed the H-Case mandatory-purpose-declined intercept firing for Legitimate Interest purposes, which have no accept/decline concept to intercept
- Fixed Rights Center's Access/Delete request Cancel buttons (and Nominee edit form's Cancel) using a destructive red style — only the actual destructive action button should be red, not Cancel
- Fixed the Grievance chat's non-user message bubble using a hardcoded light-gray background instead of the configured theme
0.1.5
- Fixed "Common Appearance" theme colors (background, button, text) and font family not applying correctly to the consent notice
- Fixed disclaimer/title and decline-rights text not translating in non-English languages
- Redesigned consent notice buttons and language picker for mobile-friendly, responsive layout
- Fixed Rights Center Nominee "Edit" button using a hardcoded purple instead of the configured button theme colors
- Fixed Data Elements/Data Processors/Tools pills not using the configured background and secondary text colors
- Applied the configured font family consistently across all consent notice text, not just a subset
- Bundled real font files for every "Font Type" option in the admin dashboard (see
CONSENT_NOTICE_FONTSexport — requiresexpo-font'suseFonts()in the consuming app; see Integration Guide) - Fixed "Allow Only Necessary" incorrectly submitting/reporting
approvedinstead ofpartial_consent - Fixed the banner auto-hiding and firing a false
no_action/rejection close on every subsequent app open after a user had already completed consent once - Fixed the mandatory-purpose badge showing "Mandatory" instead of "Necessary"
📚 Documentation
👉 Complete Integration Guide - Step-by-step guide with real-world examples from the Mars Money React Native app.
The integration guide includes:
- Detailed installation instructions
- Configuration setup (Expo & React Native CLI)
- Consent Modal integration with hook consistency patterns
- Rights Center implementation
- Complete code examples
- Troubleshooting guide (including React Native-specific issues)
- Best practices
Installation
npm install @truconsent/consent-notice-react-native
# or
yarn add @truconsent/consent-notice-react-nativePeer Dependencies
This package requires the following peer dependencies:
react>= 18.0.0react-native>= 0.70.0react-i18next>= 16.2.3i18next>= 25.6.0
Usage
import { TruConsentModal } from '@truconsent/consent-notice-react-native';
function App() {
return (
<TruConsentModal
apiKey="your-api-key"
organizationId="your-org-id"
bannerId="your-banner-id"
userId="user-id"
onClose={(action) => console.log('Consent action:', action)}
/>
);
}API
TruConsentModal
Main component for displaying the consent banner modal.
Props
apiKey(string, required): API key for authenticationorganizationId(string, required): Organization IDbannerId(string, required): Banner/Collection Point IDuserId(string, required): User ID for consent trackingapiUrl(string, optional): TruAPI root URL (e.g.https://api-dev.truconsent.io)logoUrl(string, optional): Company logo URLcompanyName(string, optional): Company nameonClose(function, optional): Callback when modal closes
License
MIT
