feat(components): add MetaPixel component with event tracking

[jontsai]

Summary

Adds a reusable Meta Pixel (Facebook Pixel) component for Next.js sites.

Features

• MetaPixel component with parameterized pixelId prop
• trackMetaEvent() helper for standard events (Lead, Purchase, PageView, etc.)
• trackMetaCustomEvent() helper for custom events
• Follows same patterns as the existing GoogleAnalytics component
• Full TypeScript support with proper Window interface extension

Usage

// In _app.tsx or layout.tsx
import { MetaPixel } from "@hacktoolkit/nextjs-htk/components"

<MetaPixel pixelId="1234567890123456" />

// Track events anywhere
import { trackMetaEvent } from "@hacktoolkit/nextjs-htk/components"

trackMetaEvent("Lead")
trackMetaEvent("Purchase", { value: 99.99, currency: "USD" })

[Copilot]

Pull request overview

This PR adds a Meta Pixel (Facebook Pixel) component for Next.js applications, following the same patterns as the existing GoogleAnalytics component. It provides a declarative way to integrate Facebook Pixel tracking with proper TypeScript support and event tracking helpers.

Changes:

• Added MetaPixel component with configurable pixel ID, load strategy, and PageView tracking options
• Exported tracking helper function trackMetaEvent() for programmatic event tracking
• Extended Window interface with TypeScript definitions for the fbq function

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.

File	Description
packages/core/src/components/index.ts	Exports the new MetaPixel component
packages/core/src/components/MetaPixel.tsx	Implements the MetaPixel component with initialization script, noscript fallback, event tracking helper, and TypeScript types

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The TypeScript Window interface extension for fbq is incomplete. The Facebook Pixel fbq function supports multiple actions ('init', 'track', 'trackCustom', etc.), but the current type definition only supports 'track'. This will cause TypeScript errors when using fbq('init', pixelId) as seen on line 40. The function signature should be updated to support multiple overloads or use a more flexible type that accommodates all fbq actions.

Suggested change

	fbq: (
	action: string,
	eventName: string,
	params?: Record<string, unknown>
	) => void
	fbq(
	action: 'init',
	pixelId: string,
	options?: Record<string, unknown>
	): void
	fbq(
	action: 'track' | 'trackCustom',
	eventName: string,
	params?: Record<string, unknown>
	): void
	fbq(action: string, ...args: unknown[]): void

[Copilot]

The PR description mentions a trackMetaCustomEvent() helper function, but this function does not exist in the code. Only trackMetaEvent() is implemented. Either the PR description should be updated to remove this reference, or the function should be added to match the documentation. Note that Facebook Pixel distinguishes between standard events (using fbq('track', eventName)) and custom events (using fbq('trackCustom', eventName)).

[Copilot]

The documentation comment states this function can be used for custom events (line 66-67), but the implementation only uses fbq('track', ...) which is for standard events. Custom events in Facebook Pixel should use fbq('trackCustom', eventName, params). This could lead to confusion or incorrect event tracking. Consider either updating the implementation to handle custom events differently or clarifying in the documentation that this function is for standard events only.

[Copilot]

The conditional logic to check if params exists is unnecessary. Facebook Pixel's fbq function accepts an optional third parameter, so window.fbq('track', eventName, params) can be called even when params is undefined. This simplifies the code and removes the redundant if-else branch.

Suggested change

	if (params) {
	window.fbq('track', eventName, params)
	} else {
	window.fbq('track', eventName)
	}
	window.fbq('track', eventName, params)

[Copilot]

When disablePageView is true, the JavaScript code skips PageView tracking, but the noscript fallback image still includes 'ev=PageView' in the URL. This creates inconsistent behavior between JavaScript and non-JavaScript environments. The noscript fallback should respect the disablePageView prop and conditionally render based on its value, or omit the 'ev' parameter when PageView tracking is disabled.

Suggested change

	<noscript>
	<img
	height="1"
	width="1"
	style={{ display: 'none' }}
	src={`https://www.facebook.com/tr?id=${pixelId}&ev=PageView&noscript=1`}
	alt=""
	/>
	</noscript>
	{!disablePageView && (
	<noscript>
	<img
	height="1"
	width="1"
	style={{ display: 'none' }}
	src={`https://www.facebook.com/tr?id=${pixelId}&ev=PageView&noscript=1`}
	alt=""
	/>
	</noscript>
	)}