react-native-popover-view: anchored popovers without the positioning work

Anchoring to a React element hands your press handler to the component

The core idea of react-native-popover-view is that a popover needs an anchor, and that anchor is usually a button the user just tapped. Rather than asking you to measure that button, the component takes the element itself. You hand your Touchable into the from prop and the popover opens when it is pressed, which means the positioning is derived from a real laid out view rather than from numbers you guessed.

The cost of that convenience is stated plainly in the documentation: if you pass an onPress or ref prop to the Touchable, it will be overwritten. The component needs the press event and the node reference for itself, so your own handler on that particular touchable does not survive. If the button must also do something else, you need a different arrangement.

The whole package is written in TypeScript and ships with no runtime dependencies, which keeps the install surface small and the upgrade story uneventful for a component that will end up in most of your screens.

Four trigger paths, from a plain press to a ref you own

Installation is a single package add, and the minimal example is short enough to read in one pass:

npm i react-native-popover-view

The simplest usage passes the element directly, and the popover appears on press:

import React from 'react';
import Popover from 'react-native-popover-view';

function App() {
  return (
    <Popover
      from={(
        <TouchableOpacity>
          <Text>Press here to open popover!</Text>
        </TouchableOpacity>
      )}>
      <Text>This is the contents of the popover</Text>
    </Popover>
  );
}

When you need the anchor to be something other than the thing that opens the popover, the from prop accepts a function that receives a sourceRef and a showPopover callback. The ref goes on whichever node should look like the origin, and the callback goes on whatever gesture should trigger it, so a long press can open a popover that appears to grow out of a label inside it:

import React from 'react';
import Popover from 'react-native-popover-view';

function App() {
  return (
    <Popover
      from={(sourceRef, showPopover) => (
        <View>
          <TouchableOpacity onLongPress={showPopover}>
            <Text ref={sourceRef}>Press here to open popover!</Text>
          </TouchableOpacity>
        </View>
      )}>
      <Text>This is the contents of the popover</Text>
    </Popover>
  );
}

Two more paths exist for full control. Driving isVisible and onRequestClose yourself hands you the dismiss behaviour, and onRequestClose fires when the user taps outside the popover. Or you can keep the element anchor and reach for the requestClose method through a ref when you need to close the popover from a button inside it.

Placement, rotation and the keyboard all move the anchor for you

The interesting engineering is not the anchor but the placement. By default the popover floats in the centre of the screen, which is useful for a first run but rarely what a design calls for. Once you anchor it to a view or to a point, the component looks for the best placement that accommodates the content, and the arrow is drawn to point back at the source.

Two adjustments happen without your involvement. The popover adapts when the content size changes, which matters for a form inside a popover that grows as the user types, and it adapts to screen size and orientation, so a popover opened on a phone in portrait does not end up hanging off the edge after a rotation. The orientation case is where this kind of component earns its keep on tablets, where a hardcoded offset would be wrong as soon as the device turned.

There is a third adjustment, and it is the one that gets missed most often in hand rolled implementations: the popover moves to accommodate the on screen keyboard for text input inside it. If your popover contains a field, the keyboard would otherwise cover the very thing the user is typing into.

A fixed anchor is also possible. If you already know where the popover should point, you can build a Rect(x, y, width, height) object and show from that, and a Rect with zero width and height behaves the same as showing from the point (x, y). That path is useful when the anchor lives in a native view the component cannot see.

Native driver animation with no third party dependencies

The animations run on React Native's native driver, according to the project description, which means they continue on the native side even when the JavaScript thread is busy. For a component that animates on every tap, that detail is the difference between a popover that feels attached to the button and one that lags behind a heavy screen.

The animation setup is configurable, along with the popover and arrow styling and the placement heuristics themselves, so the component can be made to match an existing design rather than imposing a look of its own. The trade off is that a configurable component carries more props to learn than a fixed one, and the documentation pages for props and for usage with safe area context are where you will spend that time.

The build pipeline is plain TypeScript compilation. The package scripts cover watch, build and tsc, all of which run tsc, plus jest for tests and eslint over src. The jest configuration uses the react native preset with enzyme to json for snapshot serialisation, and the tests collect coverage into json and html reports. There is a patch package step in the prepare script, so the project expects patches to be applied to dependencies at install time.

The author is looking for somebody else to own the repository

This is the part to weigh before you adopt the library. The project page carries a notice asking for someone to take over the project, and the reason given is that the author no longer ships React Native apps, is detached from the community and wants to focus attention elsewhere. That is an honest handover request rather than a stalled project, but it is still a handover request.

The dates line up with that story. The last push was on 2026-04-17, which is outside the recent window, and the newest published release is v6.1.0 from 2025-01-15, preceded by v6.0.1 and v6.0.0 on 2024-12-12. The npm version in the package manifest is 6.1.0, matching that release. So the state of the project is a working 6.x line that has not been touched in a while, with an explicit invitation for a new owner.

What that means for you is concrete. Pin the version you adopt, keep the API surface you use small, and be ready to fork if nobody steps up. The MIT licence permits that without asking anyone, and the code is small enough that forking is a realistic fallback rather than a theoretical one. It is also worth noting that the project depends on deprecated-react-native-prop-types, which is a signal that some of the internals are tied to older React Native prop type conventions.

Why this and not a plain modal with your own absolute positioning

The realistic alternative is not a competing library but the pattern most teams reach for first: render a React Native Modal with a transparent backdrop, place the content with absolute positioning, and dismiss it on backdrop press. It needs no dependency and no owner, and you keep every line of the behaviour in your own codebase.

The difference is where the work lives. The hand rolled version needs to know where the button is, which means measuring on layout, converting to the right coordinate space, deciding which side has room, flipping when it does not, and redoing all of it on rotation and on keyboard show. The component takes a view as the anchor and does that work, including moving for the keyboard and re-placing after orientation change, and it also deals with the case where the content grows.

Where the component is the worse choice is when your design is modal in spirit rather than anchored in spirit. A full screen sheet with a dimmed background and no arrow to a trigger has no anchor to compute, and the machinery in this package is then overhead rather than help. The documentation also states that the component may work on Web but is not officially supported, so a project that has to ship to browsers with the same behaviour should treat web as untested territory rather than a platform.

Editorial conclusion

Adopt react-native-popover-view if you are building a React Native app on iOS or Android and need a popover that anchors to a real view without writing placement maths, especially on tablets where a fixed offset would break on rotation. Do not adopt it if you need first class web support, if you cannot accept a package whose author has asked for someone else to take it over, or if your design system insists on a modal style sheet. Before you commit, install it, try the from element pattern on a real device with your longest popover content, and check whether the visible TouchableOpacity press handler still fires once the component has taken over the anchor.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. SteffeyDev/react-native-popover-view on GitHub