react-native-autocomplete-input: a suggestion field you can theme and extend

You supply the data, the component supplies the list

The contract is short enough to state in one sentence. The data prop is an array of suggestion items, and the component decides what to show from its length: any array with length greater than 0 opens the suggestion list, and any array with length below 1 hides it. There is no internal fetching, no debounce and no request handling, because the README describes the component as pure JavaScript for React Native written in TypeScript, and the usage shape makes the split explicit. Your component holds the query state, filters the data with your own hook, and passes the result down. The suggestion items are rendered by the internal FlatList, and the default renderItem is Text(String(item)), so a bare array of strings works with no configuration, and item rendering is customised through flatListProps.renderItem. The component manages the data of the list itself, while the style passed through flatListProps is merged with the default list style, which is why passing your own style does not wipe out the built-in layout.

Android needs the list in an absolutely positioned wrapper

The platform section documents a real constraint rather than a preference. Android does not support overflows, which is the reason the suggestion list cannot simply extend past the bounds of its parent on that platform, and the issue is tracked as number 20. The fix is to wrap the autocomplete in an absolutely positioned view on Android so the suggestion list is allowed to overlap other views inside your component. The styles needed are small, one container with absolute position and a zIndex of 1, and the rest of the screen stays in normal flow underneath it:

const styles = StyleSheet.create({
  autocompleteContainer: {
    flex: 1,
    left: 0,
    position: 'absolute',
    right: 0,
    top: 0,
    zIndex: 1
  }
});

This is the kind of detail that decides whether a component is a pleasant dependency or a source of one hour of layout debugging, and the fact that it is written down with a working snippet is the most useful thing in the README. It is also the clearest sign that the component is aimed at teams that understand the platform differences, rather than at a cross platform abstraction that hides them.

Two known issues: ScrollView and Jest

The known issues section names two problems and gives the fix for each. The first is the ScrollView. By default the autocomplete will not behave as expected inside a ScrollView, and the fix is a prop on the scroll view itself, keyboardShouldPersistTaps set to true for React Native 0.39 and earlier, or to always for React Native 0.40 and later. The second option is to use renderResultList to render a custom result list that does not use FlatList, and the tests contain a case of it. The second issue is about testing rather than running. If you want to test with Jest, add a mock for the module that renders the component as a simple string, which keeps the test tree shallow when the component is not the thing under test. Neither issue is deep, but both are the kind of thing that turns a component from a pleasure into a chore, and having them written down with the exact prop values saves the round trip.

Ten props, and what each one actually controls

The prop list is where the design of the component shows. Four are styling hooks applied to the containers around the parts, with containerStyle for the wrapper around the autocomplete, inputContainerStyle for the wrapper around the text input, and listContainerStyle for the wrapper around the result list. hideResults is a boolean that hides the suggestion list outright, which is different from supplying an empty array because it also stops the list from being laid out. onShowResults is a callback that receives a boolean telling you whether results are showing, which is how you drive a spinner or a layout change from outside. onStartShouldSetResponderCapture is passed to the result list container, which lets you control when the list takes over the touch responder. Then there are the two escape hatches, renderTextInput for a custom TextInput that receives all the TextInput props, and renderResultList for a custom result list component that defaults to FlatList and receives the FlatList props. The point of that pair is that the component owns the behaviour and you own the appearance.

Installing it and trying the interactive page

The installation is the standard pair of package manager lines:

# Install with npm
$ npm install --save react-native-autocomplete-input

# Install with yarn
$ yarn add react-native-autocomplete-input

There is also an interactive page linked from the README where you can play with the component before installing anything, and the project homepage at byteburgers.com/autocomplete is the same address. The usage shape is a small React component. You keep the query in state, derive the filtered data with your own hook, and pass both to the component, with onChangeText writing back into the state:

function MyComponent() {
  const [ query, setQuery ] = useState('');
  const data = useFilteredData(query);

  return (
    <Autocomplete
      data={data}
      value={query}
      onChangeText={(text) => setQuery(text)}

The flatListProps that follow are where you plug in your own row rendering, with a keyExtractor and a renderItem. Nothing here is React Native specific beyond the components themselves, which is what makes the component usable from a plain JavaScript project as well.

The repository is an Nx monorepo around one package

The source layout deserves a look if you plan to contribute. The root package.json declares npm workspaces over packages/* and examples/*, and the build and test scripts are Nx fan-outs, with build running the build target across all projects and test running lint first and then the test target across all projects. The tooling around it is current, with Nx 23.3.0, TypeScript 6, ESLint 10, Prettier and typescript-eslint as the dev dependencies, and a flat eslint.config.mjs, a .prettierrc, a .node-version and a .nvmrc at the root. The workspace holds the library under packages/ and a full application under examples/ whose name tells you what it is, StarWarsMovieFinder, which is a small movie search app used to exercise the component. The local development loop is three commands, install the dependencies, link the package into the workspace app so your changes show up there, and then run the app:

# Install Dependencies
$ npm i

# Locally link the autocomplete package into the example project
$ npm link react-native-autocomplete-input -w starwarsmoviefinder 

# Enable package rebuild on changes
$ npx nx watch --projects=react-native-autocomplete-input -- npm run build 

The nx watch command rebuilds the package as you edit it, which is the piece that makes the link useful rather than a one time trick.

Licence, versions and where the badges point

The licence is MIT, which is the permissive choice for a component you are likely to copy into an app at some point. The npm version badge and the release history show a component that was actively patched in early 2025, with v5.5.4 on 2025-01-01, v5.5.5 on 2025-01-02 and v5.5.6 on 2025-01-24, so the line was on the 5.5 series with patch releases arriving over a few weeks. The last push to the main branch was on 2026-10-17 and the repository is not archived, so work continues on the branch even though the tagged releases have not moved since 2025. One detail is easy to trip over when you read the README. The test badge at the top points at the workflow of a different account, mrlaessig, rather than at the byteburgers organisation that hosts the repository now, and the earlier versions of this project were published under that account. If you are tracking releases, check the npm package rather than the badge, and if you are upgrading an existing app, read the release notes for the 5.x line before assuming a new version number means a new API.

Editorial conclusion

react-native-autocomplete-input fits a React Native team that needs a type-ahead field with a suggestion list and nothing more, especially if you already filter your data in the component and hand the result array to the component, which is exactly the shape the code assumes. It is the wrong choice if you want a search field with debouncing, grouping, highlighting or recent queries, since none of that is in the component and you would be building it yourself around the data prop. It is also a poor fit for a screen that relies on a ScrollView, unless you apply the documented keyboardShouldPersistTaps change. Before you adopt it, check the Android layout wrapper, since the suggestion list needs an absolutely positioned container there, and confirm the version you install matches the React Native version your app uses, because the last published releases are from January 2025.

Frequently asked questions

Official sources

1. byteburgers/react-native-autocomplete-input on GitHub
2. License: MIT
3. Project website
4. README
5. Releases