Shared Hooks

For developers

How the shared providers and hooks keep event tracking close to business logic so screens reuse the same behavior.

Why hooks are used here

The example keeps analytics close to business logic in providers/hooks. This improves reuse because screens consuming the same hook share the same event behavior.

Cart provider (shared/hooks/useCart.tsx)

addToCart

• sends BasketAdd for new item insertion
• payload includes productId, quantity, price

removeFromCart

• sends BasketRemove
• payload uses the line’s catalog productId, removed quantity, and line price

updateQuantity

• reuses BasketAdd with updated quantity

clearCart

• sends BasketClear

Reference: Checkout and Basket Events.

Wishlist provider (shared/hooks/useWishlist.tsx)

addToWishlist

• sends FavoriteAdd

removeFromWishlist

• sends FavoriteRemove

clearWishlist

• no dedicated batch clear event method in current SDK usage

Reference: User and Wishlist Events.

Auth provider (shared/hooks/useAuth.tsx)

logout

• sends Logout before auth state reset

login

• after login() succeeds, LoginScreen persists the user with Initialize.setUser({ email }) and sends events.Login({ email })

Reference: User and Wishlist Events.

Hook-level hardening suggestions

• Use catalog productId consistently for basket events.
• Guard repeated event calls triggered by render loops.
• Keep type unions aligned with real payload values (INTERACTION use-cases).

For search/popup interaction hooks, see Search, Interaction, Form and Custom and Popups, Search and Push.