Introducing the FeedbackKit React Native SDK

On 9 February we released React Native SDK 1.0, the npm package that brings FeedbackKit into a React Native app on iOS and Android. It gives your app a board where people read what others have asked for, vote for what they want, and file their own requests, without leaving the app. Your team then reads, sorts and answers those requests in the FeedbackKit admin app.

The short version

• One provider, FeedbackProvider, that holds the client, the current user id and the theme.
• Five components: FeedbackList, FeedbackCard, VoteButton, StatusBadge and CategoryBadge.
• Six hooks: useFeedbackList, useFeedback, useVote, useComments, useSubmitFeedback and useFeedbackKit.
• It is built on the JavaScript SDK and re-exports it, so the enums, the types and the error classes come from the same import.
• It needs React 18, React Native 0.70 and AsyncStorage 1.17 or later.

What is in React Native SDK 1.0

The provider

Everything sits inside FeedbackProvider. It takes your project's API key, plus an optional userId, theme and baseUrl. The default address is FeedbackKit's production server, so most apps pass the key and leave baseUrl alone. A component or hook used outside the provider throws an error that says so.

Five components

FeedbackList is the board. It loads the project's requests and shows each one as a card with its status, its category, the title, two lines of the description and a vote button, with pull to refresh. filterByStatus and filterByCategory narrow what it loads, and onFeedbackPress hands you the tapped request so you can open your own detail screen. With showAddButton and onAddPress set, it draws a round plus button over a list that has requests, and a Submit Feedback button inside the empty state. While loading it shows a spinner, and when a request fails it shows the error message with Tap to retry.

The parts of the card are exported too. FeedbackCard draws one request and can hide its status, category, vote button or comment count. VoteButton comes in three sizes and calls onVoteChange with the new state. StatusBadge and CategoryBadge draw the coloured labels, in two sizes.

Version 1.0 has no ready-made submit form or detail screen. Both are a few lines with the hooks below, and the React Native SDK 1.0 tutorial builds them.

Six hooks

• useFeedbackList(filter) returns feedbacks, isLoading, error, refetch, and setFilter to change the status or category.
• useFeedback(id) loads one request.
• useVote() returns vote(id, options) and unvote(id). The options carry an email and a notifyStatusChange flag for status emails.
• useComments(id) loads the comments and returns addComment(content), which appends the new comment to the list it returns.
• useSubmitFeedback() returns submit({ title, description, category, userEmail }), which resolves with the created request.
• useFeedbackKit() returns the JavaScript client itself. Its users.register({ userId, mrr }) reports what a user pays, so your team can rank requests by the revenue behind them.

Failures are FeedbackKitError subclasses you can tell apart: AuthenticationError for a wrong key, PaymentRequiredError for a plan limit, NotFoundError, ConflictError for a repeat vote, ValidationError and NetworkError.

Voting

VoteButton sends the vote, waits for the server's answer and then draws it. There is no optimistic update: the button shows a spinner while the request is in flight. It is disabled on requests that are Completed or Rejected, and the server refuses votes on them too. The button sends no email with the vote. To let voters sign up for status emails, call vote(id, { email, notifyStatusChange: true }) from a control of your own.

Users

Votes, requests and comments each belong to a user id, and the SDK does not make one up. Pass your own account id as userId. An app without accounts can create an id itself and hand it to setUserId, from useFeedbackKitContext(), which saves it in AsyncStorage. On the next launch the provider reads it back before the hooks load anything. Without an id, reading the board works, while voting, filing and commenting throw "User ID is required".

Theming

The theme prop takes any part of the theme: primaryColor, the background, card, text and border colours, a colour per status and per category, borderRadius and spacing. Whatever you leave out keeps the default. A darkTheme is exported for you to pass when the device is in dark mode.

Two things to know before you ship

Counts and voted state do not come through. The FeedbackKit API writes field names in snake case, such as vote_count, has_voted and comment_count. The JavaScript SDK 1.0 hands responses over without renaming them, so on a Feedback the camel-case voteCount, hasVoted, commentCount and createdAt are undefined. The id, title, description, status and category read correctly. In practice VoteButton shows its arrow with no number, never switches to the voted look, and a second tap sends another vote, which the server refuses as a repeat, instead of removing the earlier one. Cards show no comment count. The tutorial shows a small helper that reads both spellings and a vote control built on it.

The README uses names the code does not have. It shows FeedbackKitProvider with a projectId prop, createTheme, and submitFeedback from useSubmitFeedback. The package exports FeedbackProvider, which has no projectId, mergeTheme, and a hook that returns submit. Use the names in this post.

Getting started

Install the package with its two peer dependencies:

npm install feedbackkit-react-native feedbackkit-js @react-native-async-storage/async-storage

npm resolves 1.0.1, which republished the same code later the same day. On bare React Native, run pod install in the ios folder for AsyncStorage's native side. In an Expo project, add AsyncStorage with npx expo install.

Then wrap your app in the provider with your project's API key, which you find in the FeedbackKit admin app under the project's settings, and show the board:

import React from 'react';
import { SafeAreaView } from 'react-native';
import {
  FeedbackProvider,
  FeedbackList,
  FeedbackStatus
} from 'feedbackkit-react-native';

function useTrailmateUser(): { id: string } {
  // Your own account state.
  return { id: 'hiker-1042' };
}

export default function App() {
  const user = useTrailmateUser();

  return (
    <FeedbackProvider apiKey="sf_your_api_key" userId={user.id}>
      <SafeAreaView style={{ flex: 1 }}>
        <FeedbackList filterByStatus={FeedbackStatus.Approved} />
      </SafeAreaView>
    </FeedbackProvider>
  );
}

filterByStatus={FeedbackStatus.Approved} shows the requests your team has accepted and keeps new, unreviewed ones off the board. Leave it out to show everything. The React Native SDK 1.0 tutorial walks through the rest: user ids for apps without accounts, the submit and detail screens, a vote control that shows its count, MRR and status emails. The reference is in the React Native SDK docs.

How FeedbackKit fits in

The SDK is the part your users see. Your team works in the FeedbackKit admin app for iPhone, iPad and Mac: read new requests, merge duplicates, reply in the comments, sort by votes or by the MRR behind them, and move a request through Approved, In Progress and TestFlight to Completed. Android users see the same status names, TestFlight included. When a request's status changes, the person who filed it and left an email can be told by email, and your team gets a push notification for new requests and comments. On Pro and up, requests can go to GitHub, Linear, Notion, ClickUp or Monday.com, and new ones can be posted to Slack. See pricing for what each plan includes.

Here is how the board looks in FeedbackKit, with sample data from a fictional hiking app:

What comes next

Later releases each have their own post, beginning with React Native SDK 1.1. If you are starting today, the current React Native tutorial covers the latest version.

Every plan includes the React Native SDK. Start free, create a project, and put the board in your next build.