react-facebook wraps the Facebook SDK in typed React components and hooks

One package covering the parts of the SDK a React app actually uses

The repository description says it plainly: skip the Facebook SDK boilerplate, with drop-in React components for social login, sharing and analytics, with full TypeScript and hooks support. The README frames it as the Facebook SDK for React, covering Login, Pixel, Share, Like, Comments, Graph API, one package, fully typed, SSR safe.

The all-in-one claim is concrete in the component list. FacebookProvider handles SDK initialisation and context. Login offers Facebook Login with render props and children as a function. Like is a like button with layout, colour scheme and share options. Share and ShareButton cover the share dialog and an inline share button. Comments and CommentsCount cover the comments plugin and the count display. EmbeddedPost and EmbeddedVideo embed posts and videos. Page is the Facebook Page plugin with tabs. FacebookPixelProvider is a standalone pixel provider that needs no SDK. FacebookErrorBoundary catches SDK failures with a customisable fallback.

That is a wide surface, and it is wide in a specific direction. Every item here is something the underlying Facebook SDK can do, wrapped so that it can be used as a React element. Nothing in the package adds a capability of its own, and nothing in the list is vendor-neutral.

The audience is therefore React applications that already have a Facebook app id and want login, tracking and sharing without writing the SDK loader themselves. For an application with no Facebook presence, the package has no use at all, and for one that wants to support several social providers at once, a single-vendor wrapper is the wrong shape.

SSR safety is the feature that saves you the most code

Two of the listed reasons to choose the package are about how it behaves in a modern build, and they are the ones a React developer will feel first.

The first is SSR and Next.js readiness. The package uses 'use client' directives and window guards built in, and the README's phrasing is that this means no window is not defined errors. That is the classic failure of a Facebook SDK integration in a React application: the SDK script expects a browser at module evaluation time, and a server render has no window, so the whole render blows up unless you guard every access.

The second is the modern React shape. The package offers a hooks API, with useLogin, usePixel, useGraphAPI, useLocale and more, and a context-based provider. The context provider is what makes the SDK instance available without prop drilling, and the hooks are what let a component reach the SDK without a class component or a consumer wrapper.

TypeScript-first is the third: every component, hook and return type is fully typed. For the Graph API in particular, where responses are untyped JSON from a Graph endpoint, a typed hook with data, loading and error states is worth more than the wrapper it sits in.

Two more claims round out the picture. The package is tree-shakeable and under 15 KB gzipped, which matters if you only want the Login button and not the Page plugin. And it is described as error resilient, because FacebookErrorBoundary gracefully handles ad blockers and network failures, which is a genuinely common condition rather than an edge case.

The hook surface is the part that carries the API

The hooks table is longer than the component table, and it is where the practical API lives.

useLogin gives programmatic login and logout. useProfile fetches user profile fields, and the example passes a field list, so you ask for name, email and picture rather than pulling the whole profile. useLoginStatus checks the authentication status. useGraphAPI makes typed Graph API calls with loading, error and data states. useShare, useFeed and useSend open the corresponding dialogs. usePixel and usePageView handle pixel event tracking and automatic page views. useLocale does dynamic language switching without a page reload, and useFacebook gives direct access to the Facebook SDK instance when you need to drop down to the raw SDK.

That last one is the escape hatch that makes the rest safe to adopt. The wrapper covers the common paths, and when you need something the wrapper does not model, you can reach the underlying SDK instance and use it directly rather than maintaining a fork.

The component side overlaps with the hook side deliberately. Login can be used with render props or with children as a function, which means a component can either render its own button or hand the state to the caller. The Like component takes layout, colour scheme and share options, and Share and ShareButton cover both the dialog and the inline case, so the choice is about how much of the UI you want to own.

Provider, pixel provider and an imperative API for the pixel

The quick start shows the smallest useful setup, a provider wrapping the components you want:

import { FacebookProvider, Login } from 'react-facebook';

function App() {
  return (
    <FacebookProvider appId="YOUR_APP_ID">
      <Login
        onSuccess={(response) => console.log('Login success:', response)}
        onError={(error) => console.error('Login failed:', error)}
      >
        Login with Facebook
      </Login>
    </FacebookProvider>
  );
}

The provider takes the app id and supplies context; the Login component takes success and error handlers and children.

Pixel tracking comes in two shapes. The first is the hook inside a provider that carries both an app id and a pixel id:

import { FacebookProvider, usePixel } from 'react-facebook';

function TrackingExample() {
  const { track, pageView, grantConsent, revokeConsent } = usePixel();

  return <button onClick={() => track('Purchase', { value: 29.99, currency: 'USD' })}>Buy Now</button>;
}

The hook returns track, pageView, grantConsent and revokeConsent, and those last two are the GDPR story: the README lists built-in consent management for Pixel tracking, and the consent calls are part of the hook rather than something you wire yourself.

The second shape is an imperative API that needs no provider at all:

import { ReactPixel } from 'react-facebook';

ReactPixel.init('YOUR_PIXEL_ID');
ReactPixel.pageView();
ReactPixel.track('Purchase', { value: 29.99, currency: 'USD' });

That is the drop-in path for a site that only needs tracking and no login.

Graph API calls return data, loading and error

The Graph API hook is the clearest example of what TypeScript-first means in practice.

import { useGraphAPI } from 'react-facebook';

function UserProfile() {
  const { data, loading, error } = useGraphAPI({
    path: '/me',
    params: { fields: 'name,email,picture' },
  });

  if (loading) return <p>Loading...</p>;
  if (error) return <p>Error: {error.message}</p>;

  return <p>Welcome, {(data as { name: string })?.name}</p>;
}

The path and the params object are the request, and the return value has three states rather than one. The loading and error branches are handled by the caller, which means the component decides what a pending request and a failed request look like, which is the point of putting it in a hook.

The cast in the render line is also instructive. The response is typed, but the hook does not know the shape of your particular Graph query at compile time, so the narrow type is applied at the point of use. That is a fair trade for a generic hook, and it is a small piece of friction in a package whose selling point is that everything is fully typed.

The login flow follows the same pattern. useLogin returns login, logout and loading, useProfile takes a list of fields and returns the profile, and the example branches on whether the profile is present to choose between the authenticated view and the button that starts the login with an explicit scope:

const { login, logout, loading } = useLogin();
const { profile } = useProfile(['name', 'email', 'picture']);

The scope argument, email,public_profile in the example, is the part to get right, because it determines what the user is asked to consent to and what comes back in the profile.

The error boundary treats ad blockers as an expected condition

FacebookErrorBoundary is the component that most directly reflects how the package thinks about failure, and the README's reason for having it is worth quoting: it gracefully handles ad blockers and network failures.

An ad blocker that blocks the Facebook script does not throw a normal JavaScript error. It leaves the SDK absent, so a component that assumes window.FB exists fails later, in a place that has nothing to do with the network. Catching that at a boundary and rendering a fallback turns a broken page into a degraded one.

import { FacebookProvider, FacebookErrorBoundary, Login } from 'react-facebook';

<FacebookProvider appId="YOUR_APP_ID">
  <FacebookErrorBoundary
    fallback={(error, reset) => (
      <div>
        <p>Facebook failed to load: {error.message}</p>
        <button onClick={reset}>Try again</button>

The fallback receives the error and a reset function, so the user can retry rather than being stuck on a dead control.

This is a small component with a large effect on perceived reliability, and it is the sort of thing that is usually written by the first team that hits the problem in production and then copied between projects. Having it in the package is an argument for the package.

The documentation set behind it is organised by topic, with a getting started page covering installation, provider setup and the first component, separate pages for components, hooks, the Facebook Pixel and a guides section that includes the migration guide from v10 to v11.

Where react-facebook is the wrong tool

The limits follow from the package being a single-vendor wrapper.

First, it is Facebook only. There is no abstraction here that a second provider could be plugged into, so an application that needs Google and Facebook login ends up with two libraries rather than one. For a product that wants to be independent of any particular social platform, this is the wrong dependency.

Second, the package does not remove the vendor's platform requirements. The app id, the app configuration, the domains that are allowed and the review process for Facebook Login are all still Facebook's, and a wrapper cannot change that. It removes boilerplate, not policy.

Third, the version history has a jump in it. The visible releases are 8.1.2 and 8.1.4 from November 2019, then v11.0.1 on 2026-03-04. A major version gap like that usually means breaking changes, and the documentation links a migration guide for v10 to v11, so an upgrade from an older 8.x install is a project rather than a version bump.

Fourth, the bundle size claim has conditions. Under 15 KB gzipped and tree-shakeable is good, but only if you import the parts you use; the all-in-one surface means a careless import pulls in more than a login button needs.

On the repository itself, the layout is a pnpm monorepo with a private root package named react-facebook-monorepo at version 11.0.1, workspaces for packages/react-facebook and apps/docs, and a pnpm-lock.yaml. The scripts are workspace-filtered, with separate unit and end-to-end test commands, a typecheck, a lint, prettier formatting, and version bump scripts at scripts/bump-version.mjs for patch, minor and major. The author is Zlatko Fedor, the licence is MIT with a LICENSE file at the root, and the last push was on 2026-06-01, so the repository is receiving work even though the newest tag is from March.

Editorial conclusion

React teams that need Facebook Login, Pixel tracking or social plugins should adopt react-facebook, because it removes the manual SDK loading and the window guard boilerplate that every React project otherwise writes itself, and it ships typed hooks for the Graph API and the pixel. It is the wrong choice for a product that does not use Facebook at all, since the package is a wrapper around one vendor's SDK rather than a general social layer, and it is the wrong choice if you want to stay off the vendor's platform entirely. Before adopting, read the migration guide for the v10 to v11 upgrade, since the published version is a major version above the 8.x line, and check that your app's Facebook app configuration matches the provider setup described in the getting started guide.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. seeden/react-facebook on GitHub