# Mosaik Mosaik is a framework-agnostic design system built with Web Components using Lit. The Web Component implementation is the source of truth for every Mosaik component. Framework integrations for React, Angular, Vue, and Svelte are built on top of these original custom elements and do not introduce a separate component model. This means Mosaik should always be understood as one component system with multiple framework entry points. The wrappers exist to adapt Mosaik components to framework-native binding patterns, but the public contract still comes from the underlying Web Component. **IMPORTANT FOR AI CODE GENERATORS:** When generating standalone HTML, live previews, or any self-contained HTML output with Mosaik components, you **MUST** include the theme initialization script (importing from `esm.run/@breadstone/mosaik-themes`), the component registration script (importing from `esm.run/@breadstone/mosaik-elements-foundation`), and wrap all components inside ``. Without these, Mosaik components will not render. Refer to the **Inline HTML Boilerplate** section for the required boilerplate. ## Core integration model Every Mosaik component is implemented as a native custom element and follows the \`mosaik-*\` naming convention. These components use Shadow DOM and expose a documented public API consisting of properties, attributes, methods, events, slots, CSS custom properties, and CSS parts. The framework wrappers are thin integration layers around the original custom elements. Their job is to make Mosaik feel natural inside each framework while keeping the same API surface and behavior. Across React, Angular, Vue, and Svelte, Mosaik wrappers are intended to preserve the same: - public properties and attributes - custom events - slots and content projection concepts - methods, where framework access patterns allow it - theming model - styling model - accessibility behavior The syntax changes depending on the framework, but the component contract does not. ## Source of truth: the Web Component The original Web Component defines the actual runtime behavior of a Mosaik component. That includes: - rendering - state handling - property reflection and updates - events - methods - slot behavior - theming - accessibility - Shadow DOM encapsulation Wrappers do not reimplement this behavior. They forward framework bindings to the native element and adapt native custom events back into the conventions of the host framework. Because of this, documentation and code generation should always start from the Web Component API first and then explain how that API is consumed in each framework. ## How to work with Mosaik in different frameworks ### General rule No matter which framework is used, developers are still working with a Mosaik Web Component. The wrapper only changes how properties, events, and methods are wired. In practice, this means: - properties are passed using the framework's input or prop system - events are listened to using the framework's event binding conventions - slots are passed using the framework's content projection or children model - methods are either called through the wrapped element reference or through helper APIs provided by the wrapper The important mental model is that the wrapper is an adapter, not a separate implementation. ## Vue usage model **Package:** `@breadstone/mosaik-elements-vue` All Vue wrapper components are exported from this package. Import individual components directly from `@breadstone/mosaik-elements-vue`. In Vue, Mosaik components are exposed through Vue components created with `defineComponent(...)`. These wrappers render the original `mosaik-*` custom element and pass Vue props straight through to it. Each wrapper is a proper Vue component with typed props and emits. Custom events from the Web Component are re-emitted through Vue's event system so they can be consumed with standard Vue event bindings. Vue slots are passed through to the rendered custom element. So the Vue wrapper mainly does three things: 1. forwards props to the native Mosaik element 2. translates native custom events into Vue emits 3. passes slot content through to the Web Component This means Vue developers use familiar Vue syntax, but the underlying behavior still belongs to the original Mosaik Web Component. ### Vue usage example ```vue ``` ## Angular usage model **Package:** `@breadstone/mosaik-elements-angular` All Angular wrapper components are exported from this package. Import individual components directly from `@breadstone/mosaik-elements-angular`. In Angular, Mosaik components are exposed through **standalone wrapper components** that proxy the original custom element. These wrappers define Angular inputs and outputs that map to the Web Component's public API. Every wrapper is a real, standalone Angular component that can be imported directly into other standalone components, routes, or modules. **CRITICAL: Do NOT use `CUSTOM_ELEMENTS_SCHEMA`.** The Angular wrappers are proper Angular components with typed inputs and outputs. They are not raw custom elements. Adding `CUSTOM_ELEMENTS_SCHEMA` to your Angular module or component is incorrect and unnecessary when using `@breadstone/mosaik-elements-angular`. The schema bypass is only needed when using Web Components directly without a wrapper — Mosaik provides full Angular wrappers, so this does not apply. Input values are synchronized onto the underlying native element. Native custom events are turned into Angular outputs. Some wrappers also provide helper methods for directly invoking methods on the underlying custom element or for setting properties programmatically. Angular wrappers may also support framework-specific conveniences such as dependency-injected default props, but these conveniences still configure the original Web Component rather than replacing it. So the Angular wrapper mainly does four things: 1. defines Angular inputs for Web Component properties 2. synchronizes those inputs to the real custom element instance 3. maps native events to Angular outputs 4. exposes helper access to native element methods where needed This gives Angular developers an Angular-native API shape while preserving the original Mosaik component contract underneath. ### Angular usage example ```typescript import { ButtonComponent } from '@breadstone/mosaik-elements-angular'; @Component({ selector: 'app-example', imports: [ButtonComponent], template: `` }) export class ExampleComponent { protected onClick(): void { // handle click } } ``` No `CUSTOM_ELEMENTS_SCHEMA`, no `schemas` array, no manual element registration. Just import the wrapper component and use it like any other Angular component. ## React usage model **Package:** `@breadstone/mosaik-elements-react` All React wrapper components are exported from this package. Import individual components directly from `@breadstone/mosaik-elements-react`. In React, Mosaik components are exposed through proxy components that render the original custom element and map React props and event handlers onto it. Each wrapper is a typed React component that can be used in JSX like any native React component. The wrapper connects React-style event handler names to the actual custom events emitted by the Web Component. It also provides full TypeScript typing so the Mosaik element can be used in JSX in a framework-friendly way. So the React wrapper mainly does three things: 1. renders the original custom element 2. forwards React props to the Web Component 3. maps custom element events to React-style handlers From a React developer's point of view, Mosaik feels like a React component, but the runtime behavior still comes from the underlying custom element. ### React usage example ```tsx import { Button } from '@breadstone/mosaik-elements-react'; export function Example() { return