Ezoic Open-Sources Framework SDKs for React, Vue, and Angular

You built the site the modern way. Routes change instantly. Components mount and unmount without a full refresh. Maybe part of the app renders on the server, then hydrates in the browser. Then monetization enters the picture, and suddenly an ad integration that was designed around traditional page loads has to understand a single-page app.

That is the moment these SDKs are meant for.

Ezoic has open-sourced three official framework SDKs for publishers building JavaScript single-page apps: @ezoic/react-sdk, plus equivalent SDKs for Vue and Angular. The public repositories are live at github.com/ezoic/ezoic-react-sdk, github.com/ezoic/ezoic-vue-sdk, and github.com/ezoic/ezoic-angular-sdk. All three are MIT-licensed.

The important part is not just that the SDKs exist. It is how they meet the way publisher sites are actually being built now.

One Provider, Then Ad Components

For React, setup starts with:

npm install @ezoic/react-sdk

Vue and Angular follow the same pattern with their own package names.

Instead of hand-editing script tags and remembering the exact order of consent, queue setup, and ad loading, you wrap the app once in an <EzoicProvider>. The provider injects Ezoic's Gatekeeper CMP scripts first, then the ezstandalone.cmd queue stub, then Ezoic's ad scripts in the correct order automatically.

After that, display ad placement becomes component-level work:

<EzoicAd location="..." />

You can drop that component where the ad belongs in the tree, next to the page layout and content logic your team already maintains. That is a better fit for React, Vue, and Angular apps than scattering ad script choreography across templates.

The provider also marks the page as a single-page application by default at boot by calling setIsSinglePageApplication(true). That detail matters. SPA integrations have historically been easy to get almost right and hard to get fully right because ad stacks often expect a full document load. Client-side route changes do not naturally behave like new page loads, so the ad stack needs an explicit signal. If you have a page that does not need SPA handling, singlePageApp={false} opts out.

Route Changes Are Part of the Integration

The SDKs include a page-view tracking hook, useEzoicPageView(), so ad placeholders can refresh correctly when the URL changes without a full reload. The React docs show it with both React Router's useLocation and the Next.js App Router's usePathname, which are exactly the kinds of routing layers publisher engineering teams are using in production.

There is also a useEzoic() hook with an isReady flag. That flag becomes true after the provider has injected the scripts, giving your components a clean way to gate ad-dependent logic instead of guessing whether the global scripts have finished loading.

This is the larger shift: Ezoic is moving SPA monetization from "paste this, then manually wire up the edge cases" toward framework-native primitives. Install a package. Add a provider. Place an ad component. Track route changes with the router you already use.

Consent Is Not an Afterthought

Consent handling is one of the places where SPA ad integrations can become fragile. Publishers serving EU or UK visitors need to account for GDPR and UK GDPR requirements, and many ad integrations rely on TCF consent signals. In a client-rendered or server-rendered JavaScript app, timing can get messy: the CMP may not be present yet, the app may render on the server first, and components still need a safe way to react to consent-string changes.

The SDKs address that through useEzoicConsent().

The hook returns consent state including cmpPresent, tcfReady, tcString, gdprApplies, eventStatus, and cmpStatus. It subscribes to window.__tcfapi consent-string changes in the browser, returns { cmpPresent: false, tcfReady: false } on the server, and does not throw if no CMP is present.

That last part sounds small until you have debugged an SSR page that crashes because a browser-only consent API was accessed too early.

Rewarded and Video Ads Fit the Same Pattern

The SDKs also cover rewarded and video ads, not just display. The rewarded hook, useEzoicRewarded(), wraps ezstandalone.initRewardedAds(...) and the separate window.ezRewardedAds queue as promises. It also surfaces the ezRewardedInitiated, ezRewardedDisplayed, and ezRewardedClosed window events.

That gives you the building blocks for a "watch an ad to unlock content" flow without hand-rolling queue-draining logic around global ad objects. You still need to design the user experience carefully. The SDK does not decide what content should be gated, how you present the offer, or how you handle a user who closes the ad. It gives your engineering team the framework-level integration layer so those product decisions can live in your app code.

Why MIT-Licensed SDKs Matter

Open source changes the relationship between a publisher and an ad-tech integration. With public MIT-licensed repositories, your team can read the code that runs in your app, audit how scripts are injected, inspect the TypeScript types, open issues, and contribute improvements.

Each repo includes TypeScript types, a CHANGELOG.md, a CONTRIBUTING.md, and an examples/ folder with runnable demo apps. The Vue SDK includes a Vite-based demo. The React SDK references demos for Next.js and React Router. The Angular SDK uses a projects/angular-sdk workspace layout and includes its own examples app, with recent history showing it reaching v1.0.0 feature-complete status.

That fits a broader industry direction: publishers are no longer all shipping static pages with vanilla JavaScript snippets pasted into templates. Many are running typed, component-based applications, and integrations need to meet them there.

If your site runs React, Vue, or Angular, start with the public repo for your framework, install the package, wrap your app in the provider, add your first <EzoicAd location="..." />, wire useEzoicPageView() to your router, and test consent plus route changes before you ship.