Skip to content

SYSTEM Cited by 1 source

Yelp Cookbook

Definition

Cookbook is Yelp's internal cross-platform design system — "a collection of reusable components, standards, and guidelines that help teams build consistent, scalable, and cohesive interfaces across different platforms." Cookbook provides component libraries for Android, iOS, and web, and — via Konbini — a Python library for backend services that need to instantiate Cookbook components server-side in a server-driven-UI context.

Public URL: www.yelp.com/styleguide. Maintained by Yelp's Design Systems team.

What Cookbook covers

Yelp supports two applications — Yelp (consumer) and Yelp for Business — across three platforms (web, iOS, Android), producing six variations. Cookbook is the cross-cutting abstraction that keeps these six consistent.

Components (e.g. buttons, forms, cards) are defined per platform in Kotlin/Swift/React but share the same public interface and visual identity. Verbatim: "Cookbook ensures that a UI component like a button looks and behaves consistently on Android, iOS, and the Web. While each platform may have slight variations due to native conventions, the overall appearance and behavior of components remain uniform."

Beyond widget consistency, Cookbook encodes "implementation discipline": "Feature teams are encouraged to use the components as defined by Cookbook and avoid customizing them beyond the provided interfaces." The escape-hatch for customisation is opt-in, not default.

Platforms supported

  • Android — Kotlin Compose components (ButtonSmall, ButtonStandard, ButtonLarge, etc.).
  • iOS — Swift components.
  • Web — React/TypeScript components.
  • Python/CHAOS — the fourth platform added when CHAOS was designed, so that backend services could instantiate the same components server-side and serialise them to clients. This fourth platform is what motivated Konbini.

Design tokens

Cookbook owns a set of design tokens — pre-defined, semantic values for colours, icons, gradients, shadows. Tokens live in a separate repository curated by designers and are published as JSON. When components serialise tokens on the wire, Konbini sends them as {name, raw_value} records — the name is stable across platforms, the raw_value is the platform-resolvable default. See concepts/design-token-as-named-reference.

Relationship to Konbini

Konbini is the cross-platform plumbing that makes Cookbook work as an SDUI backend vocabulary. Where Cookbook authors the component catalogue (via Swift / Kotlin / TypeScript / Python implementations), Konbini auto-generates the serialisation/deserialisation code for those interfaces from a single JSON interface-definition file per component. The two systems are owned by the same team.

Every CHAOS view that renders a Cookbook button, text, illustration, or other widget does so by:

  1. Backend instantiates a Konbini-generated Python class (e.g. CookbookButton(text=..., style=...)).
  2. Konbini Python serialises it to JSON.
  3. CHAOS wraps that JSON in a JSON-string parameters field inside its stable GraphQL schema.
  4. Client (iOS/Android/web) Konbini library deserialises the JSON into a platform-specific interface model.
  5. A hand-written render extension method binds the interface model to the platform-native Cookbook widget.

Position on the wiki

  • First canonical wiki disclosure of a design-system-aware SDUI framework — most SDUI corpus instances (Airbnb Ghost Platform, Lyft SDUI) describe the SDUI substrate without the upstream design-system coupling.
  • Counterpart to Zalando's design-system stack: Zalando pairs StyleX + react-strict-dom + ZDS tokens for a runtime-resolved cross-platform design system (tokens resolve per-platform at build/runtime). Yelp Cookbook + Konbini does it differently — pre-build codegen from JSON interface definitions. Different mechanisms, same end: one design system, N platforms, guaranteed to stay in sync.

Seen in

Last updated · 550 distilled / 1,221 read