
Core SDK
Choose the core SDK when your team wants to design every screen and connect the SDK state to your own components, router, analytics, and checkout behavior.| Pros | Tradeoffs |
|---|---|
| Full UI control | You own every state and edge case |
| Works with any framework | More application code |
| Best fit for custom flows | Requires deeper understanding of JourneyView |
React components
Choose React components when you want a supported UI layer but still need branding, slot overrides, callbacks, and custom copy.| Pros | Tradeoffs |
|---|---|
| Fastest React setup | The widget owns the default layout |
| Supported journey UI | Deep customization uses slots or render props |
| Built-in theming and i18n | You still need to handle checkout and app routing |
ExperienceWidget, then move specific sections into slots as your design becomes more bespoke.
Web components
Choose web components when you need to embed Fanfare into a static page, CMS, tag-managed page, or non-React application.| Pros | Tradeoffs |
|---|---|
| Framework-agnostic embed | Customization is mostly attributes, theme config, and host CSS |
| Good for CMS and static pages | Complex UI customization usually moves to core or React |
| Events bubble through the DOM | Type checking depends on your host tooling |
Hybrid path
Many teams use more than one path:- Use
ExperienceWidgetfor the first launch. - Add slots for brand-critical states.
- Move to
useExperienceJourneyor core SDK for a fully custom UI.
JourneyView/SequenceView) and the actions it exposes. Do not build behavior around private implementation details or assumptions about why a consumer reached a state.