DEV Community: Dhinesh K.S

The Hidden Code Sharing Problem in Micro Frontends

Dhinesh K.S — Sat, 28 Mar 2026 04:09:25 +0000

How teams go from copy-paste chaos → internal npm packages → a monorepo that finally makes sense.

⚡ TL;DR: Micro frontends help teams move independently, but they also make code sharing harder than it looks. Internal npm packages can solve part of the problem, but they often add publishing and versioning overhead. A monorepo offers the same reuse with much less maintenance.

🧩 The Scale Problem with Micro Frontends

As frontend applications grow, teams break large apps into micro frontends — so different parts of the product can evolve independently.

In an ecommerce platform, that might look like:

App	Responsibility
🔐 Auth	Login, signup, session
🛍️ Product Catalog	Listings, search, details
🛒 Cart & Checkout	Cart state, payments
👤 Account / Settings	Profile, preferences

This works great for team autonomy — different teams own, ship, and evolve their pieces without blocking each other. 🚀

But as the number of MFEs grows, a problem quietly emerges:

⚠️ The hidden cost: Even though apps are split, they still rely on the same shared building blocks — formatters, API clients, hooks, types, business logic. Managing that shared code across repos is harder than it looks.

The shared building blocks typically include:

// Common code every MFE needs
price & currency formatters
API request helpers
shared product and user types
auth / session utilities
analytics tracking helpers
reusable hooks        // useCart(), useAuth(), useDebounce()
business logic        // discounts, tax, inventory checks

This is where things start getting messy. Teams solve it in one of two ways — and both have downsides.

📦 The Polyrepo + npm Package Approach

In a polyrepo setup, apps live in separate repositories:

auth-app/
product-catalog-app/
cart-checkout-app/
account-app/

To avoid duplication, shared code gets extracted into internal packages:

shared-ui/
shared-hooks/
shared-utils/
shared-types/
api-client/

✅ This is definitely better than copy-paste. Shared code is reusable and has clean boundaries.

The Release Friction Problem

But over time, a different kind of overhead creeps in. Even a small shared change now requires this entire workflow:

1. Update the shared package
        ↓
2. Raise a PR & get it reviewed
        ↓
3. Publish a new version to npm
        ↓
4. Bump dependencies in all consuming apps
        ↓
5. Retest each app independently
        ↓
6. Release everything separately

😓 That's a lot of process for changing one helper or one hook. As shared code grows, teams end up maintaining not just apps — but a whole ecosystem of internal packages. Code sharing starts feeling heavier than it should.

🏗️ What Is a Monorepo?

A monorepo is simply a setup where multiple apps and shared packages live inside the same repository.

apps/
  auth-app/
  product-catalog-app/
  cart-checkout-app/
  account-app/

packages/
  shared-ui/
  shared-hooks/
  shared-utils/
  shared-types/
  api-client/

Apps consume shared code cleanly — just like a regular package, except there's no publish step:

import { Button, Modal }     from '@repo/shared-ui'
import { useCart, useAuth }  from '@repo/shared-hooks'
import { formatCurrency }    from '@repo/shared-utils'
import { apiClient }         from '@repo/api-client'
import type { Product }      from '@repo/shared-types'

💡 Key insight: You no longer need to publish every shared abstraction as an npm package just to reuse it. That single change transforms the developer experience.

✅ How Monorepo Solved the Problem

Once teams move to a monorepo, shared code finally has a natural home. Instead of forcing every reusable piece into a separately published package, code is shared locally through internal workspaces.

The New Workflow

1. Update the shared code
        ↓
2. All apps use it immediately
        ↓
3. Test everything together
        ↓
4. Ship in one PR ✅

That gives teams the best of both worlds:

✨ Shared like packages. Managed like one system. Modular code organisation, clean boundaries, reuse across apps — without the publishing and versioning overhead.

Now when a shared utility, hook, or API client changed:

All consuming apps could use it immediately
Changes could be tested together
Refactoring became easier
Version drift disappeared

🎯 What Teams Gain

The biggest win isn't just cleaner code — it's less friction in day-to-day development.

🧹 Less Duplication

Shared code has a clear, single place to live. No more copy-paste divergence.

⚡ Faster Development

No more publish-bump-retest cycles for every small shared change.

🔧 Easier Refactoring

Shared code and its consumers can evolve together, atomically.

🎯 Better Consistency

All apps stay aligned on the same implementation, always.

📉 Lower Overhead

No more maintaining a growing ecosystem of tiny internal package repos.

🔍 Better Visibility

One place to search, one place to review, one place to understand the system.

☝️ One Important Lesson

Monorepo is powerful — but only when sharing is intentional, not automatic.

Only extract code into a shared package when it is:

✅ Used by two or more apps (not just one)
✅ Valuable to keep consistent across the system
✅ Stable enough to centralise without frequent churn

📌 If code is specific to one app, keep it local. Over-extraction creates a different kind of mess — a shared package that nobody quite owns. Intentional sharing is what keeps a monorepo healthy.

📊 Quick Comparison

Approach	Pros	Cons
Copy-paste	Fast initially	Duplication, bugs multiply, inconsistency
Internal npm packages	Reusable, modular	Publishing overhead, version drift, slow iteration
Monorepo workspaces	Reusable + fast iteration + atomic refactors	Needs discipline, initial setup cost

💭 Final Thoughts

"The best architecture isn't the one with the most packages — it's the one with the least friction."

Micro frontends solve real scaling problems. But as they grow, your code sharing strategy matters just as much as your app boundaries.

A monorepo ends up being the missing piece for most teams — it gives package-style modularity without the publishing overhead, and that makes a huge difference in everyday developer experience. 🚀

The Hidden Problem with Embedded Chat Widgets (and How Iframes Fix It)

Dhinesh K.S — Thu, 19 Mar 2026 16:32:55 +0000

⚡ TL;DR: Embedding a widget directly into the host page means UI shares the same CSS, JS, DOM, and storage with an environment you don't control. That leads to 💥 UI breakage, 🔓 security risks, and 🎲 unpredictable behavior. A cross-origin iframe gives your widget true isolation, while postMessage keeps communication safe and controlled.

Chat widgets are embedded into customer websites that we don’t control. Those websites have their own CSS, JavaScript, and globals. Without proper isolation, the widget becomes vulnerable to style pollution, namespace conflicts, and security attacks from the host page.

In this post, we'll explore the problems embedded widgets face and how cross-origin iframe isolation creates a bulletproof boundary between your widget and its environment.

The Problem: Embedded Widgets Without Isolation

When you embed a widget directly into the host page's DOM, it exists in the same document context as everything else. This creates two critical vulnerabilities:

1. CSS Pollution

The host page's CSS cascade affects your widget globally.

Example scenario: The host page has this CSS:

/* Host page's global reset */
button {
  background: red;
  border: none;
  font-size: 24px;
  padding: 50px;
}

input {
  border: 2px dashed purple;
  width: 200%;
}

Your widget's button was designed to be small and primary-colored. But now it appears massive and red. Your text input is oversized and purple-bordered. The widget breaks visually on every site it's embedded in.

This is CSS pollution.

The host page's selectors leak into your widget. You can't control it. You can't predict it. Every site has different CSS, so your widget looks different everywhere.

Real-world consequences:

Buttons become huge or tiny depending on host styles
Colors get overridden by global stylesheets
Layout breaks because of inherited spacing and sizing
Font styles change unexpectedly
Z-index conflicts cause layering issues

2. JavaScript Security Threats

The host page's JavaScript has full access to your widget's code and state. This creates several attack vectors:

2.1 DOM Data Exposure

The threat: Host page scripts can read your widget’s DOM and extract sensitive data like session tokens, user IDs, or conversation history.

In plain English: Imagine your widget displays a secret API key. The host page’s JavaScript can inspect the DOM and steal that information.

// Host page reads your widget's DOM
const widgetContainer = document.querySelector('[data-widget]');
const widgetContent = widgetContainer.innerHTML;

// Attacker can now access everything rendered inside the widget
console.log(widgetContent);

Your widget’s sensitive data is exposed to any script running on the page.

⚠️ Note: This is technically data exfiltration via shared DOM, not classic XSS—but the risk is equally severe.

2.2 DOM Mutation Attacks

The threat: The host page can directly modify your widget’s DOM at runtime—removing elements, altering UI, or injecting malicious behavior.

In plain English: It’s like someone tampering with your app’s UI—changing buttons or redirecting users without your knowledge.

// Host page removes your widget
const widget = document.querySelector('[data-widget]');
widget.innerHTML = ""; // Widget disappears

// Host page hijacks user interaction
widget.addEventListener('click', () => {
  window.location = "https://phishing-site.com";
});

Your widget’s UI and behavior can be completely controlled by the host page.

2.3 Global Variable Conflicts

The threat: Programs store settings in "global variables" (shared memory). If the host page and your widget both use config, the host can change it to point to a fake server.

In plain English: It's like having a phone book. Your widget looks up the API server's phone number in the book. But the host page secretly changes the number to a hacker's phone, and your widget calls the wrong person without knowing it.

// Your widget needs the API server address
const apiUrl = window.config.apiUrl;

// Host page secretly changes it:
window.config.apiUrl = "https://attacker-server.com";

// Your widget now sends all data to the attacker

Your API calls can be silently redirected to attacker servers.

2.4 Event Listener Hijacking

The threat: When your widget does something (like when a user clicks a button), it sends an "event". The host page can listen to all your widget's events and capture what users are doing.

In plain English: It's like someone recording all your phone calls without permission to see what you're saying.

// Host page listens to everything your widget does
document.addEventListener('widget:action', (event) => {
  // Captures every user interaction
  console.log("User clicked:", event.detail);
  // Attacker now knows what user is doing
});

2.5 Shared Browser Storage Access

The threat: Your widget stores data like session tokens in the browser's storage. The host page can read and modify this storage.

Real example:

// Widget stores authentication token
localStorage.setItem('widget:auth_token', 'secret-token-12345');

// Host page reads it:
const token = localStorage.getItem('widget:auth_token');
// Now attacker has your user's token

// Even worse, host page can fake it:
localStorage.setItem('widget:auth_token', 'fake-attacker-token');
// Next time widget loads, it uses fake token

Browser Storage Vulnerabilities:

localStorage — Persistent data readable by any script on the page
sessionStorage — Session data readable by any script on the page
IndexedDB — Large data stores readable by any script on the page

All of this is shared memory space vulnerable to theft and manipulation.

3. Third-Party Script Vulnerabilities

The host page likely loads multiple third-party scripts (analytics, ads, chat widgets, etc.). Any of these can be compromised or malicious.

<!-- Host page loads many third-party scripts -->
<script src="https://analytics-provider.com/tracker.js"></script>
<script src="https://ads.provider.com/ads.js"></script>
<script src="https://sketchy-vendor.com/lib.js"></script>

All of these execute in the same context as your widget. One compromised script compromises everything.

The Consequences: Why This Matters

Without isolation, embedded widgets suffer from real, serious problems:

CSS Injection — Widget styling compromised by host page stylesheets, rendering visually broken across different environments
Credential Exfiltration — Authentication tokens and sensitive session data extracted by malicious host scripts
Browser Storage Compromise — localStorage, sessionStorage, and IndexedDB data accessible for reading and modification by host page
Data Injection Attack — Widget's operational data replaced with malicious payloads by host page scripts
API Redirection (MITM) — Widget's API calls intercepted and redirected to attacker-controlled servers
Session Hijacking — Stolen authentication tokens used to perform unauthorized actions as legitimate users
Denial of Service (DoS) — Widget disabled or deleted entirely through DOM manipulation
Information Disclosure — User data, conversation history, and private information exposed to untrusted host page

For users, this results in a serious breach of confidentiality and integrity. For organizations, it introduces significant legal, financial, and reputational risk.

The Solution: Cross-Origin Iframe Isolation

The only reliable way to isolate a widget from its host environment is to run it in a separate document context—a cross-origin iframe.

An iframe is a completely independent browser context. It has:

✅ Separate DOM tree
✅ Separate CSS scope
✅ Separate JavaScript scope
✅ Separate global namespace
✅ Separate local storage

When the iframe is on a different origin (different domain), the browser enforces the Same-Origin Policy, creating an impenetrable boundary.

How Cross-Origin Iframes Work

Think of an iframe as putting your widget in a separate, locked browser tab that lives inside the host page. Here's what gets isolated:

✅ Separate Document

The widget has its own HTML document, completely separate from the host. The host page's DOM is unreachable—the widget can't read it, can't modify it.

✅ Separate CSS

The widget has its own stylesheet scope. Host page CSS never reaches the widget. If the host page makes all buttons red and huge, the widget's buttons stay exactly as designed.

Host Page CSS: button { background: red; font-size: 24px; }
Widget CSS:   button { background: blue; font-size: 12px; }

Result: Widget button is blue and 12px (host CSS ignored)

✅ Separate JavaScript Namespace

The widget has its own global scope (window object). The host page's JavaScript can't access any of it.

Host page: window.config = { apiUrl: "..." }
Widget:    window.config = { apiUrl: "..." } (completely different)

If host page tries to read widget's config, it gets blocked.

✅ Separate Storage

The widget has its own isolated storage buckets:

localStorage (isolated)
sessionStorage (isolated)
IndexedDB (isolated)
Cookies (sent only to widget's domain)

The host page cannot read or write the widget's storage.

✅ Additional Hardening: Sandbox Attribute (Defense-in-Depth)

Cross-origin isolation is sufficient, but you can add an extra layer with the sandbox attribute:

<iframe
  src="https://widget-provider.com/widget.html"
  sandbox="allow-same-origin allow-scripts allow-forms allow-popups"
></iframe>

The sandbox attribute restricts what the iframe can do. You grant only the permissions needed:

allow-same-origin — Enable cross-origin communication
allow-scripts — Enable JavaScript execution
allow-forms — Enable form submission
allow-popups — Enable window.open()

This provides defense-in-depth: if a vulnerability exists in your widget code, the sandbox limits the damage it can inflict on the host page.

Communication Across the Boundary: postMessage

Since the widget is isolated in its own iframe, how does it communicate with the host page? Through the postMessage API—a secure messaging system designed specifically for cross-origin communication.

The flow:

User interacts with widget (clicks button)
Widget sends message via window.parent.postMessage()
Host receives and validates origin
Host processes action and responds
Widget receives new data and re-renders

Simple Example: Widget Sends Message to Host

Widget says: "User clicked button with action 'track_order'"

// Inside widget iframe
window.parent.postMessage(
  { action: "track_order" },
  "https://host-website.com"
);

Host receives it:

window.addEventListener("message", (event) => {
  if (event.origin !== "https://widget-provider.com") return;

  console.log("Widget says:", event.data.action);
});

Simple Example: Host Sends Message to Widget

Host says: "Widget, here's new data to display"

// Inside host page
const iframe = document.getElementById('widget-frame');
iframe.contentWindow.postMessage(
  { schema: { /* new UI schema */ } },
  "https://widget-provider.com"
);

Widget receives it:

window.addEventListener("message", (event) => {
  if (event.origin !== "https://host-website.com") return;

  render(event.data.schema);
});

Key Rules

Always check origin — Verify the message came from a trusted source
Specify target origin — Tell postMessage exactly where to send the message
Send structured data — Use objects/JSON, not code snippets

Isolation Guarantees Matrix

Here's a detailed comparison of threat protection:

Why it matters:

❌ Without isolation: Host CSS, JS, and storage directly affect the widget
✅ With isolation: Each has completely separate CSS, JS, localStorage, sessionStorage, IndexedDB, and cookies

Detailed Threat Matrix:

Threat	❌ Without Isolation	✅ With Cross-Origin Iframe
CSS Pollution	❌ Host CSS affects widget	✅ CSS fully isolated
XSS Injection	❌ Host scripts read widget data	✅ No DOM access across boundary
Global Conflicts	❌ Host globals hijack widget	✅ Separate global scopes
Cookie Theft	❌ Shared context	✅ Separate cookie jars
localStorage Access	❌ Host can read/write widget storage	✅ Completely isolated
sessionStorage Access	❌ Host can read/write widget storage	✅ Completely isolated
IndexedDB Access	❌ Host can read/write widget database	✅ Completely isolated
DOM Manipulation	❌ Host can mutate widget DOM	✅ No cross-boundary access
Session Hijacking	❌ Easy to intercept	✅ Protected by Same-Origin Policy
Storage Poisoning	❌ Host overwrites widget data	✅ Impossible across boundary
Script Hijacking	❌ Third-party scripts affect widget	✅ Independent contexts

Tradeoffs: What You Lose

Cross-origin iframe isolation provides absolute security but has drawbacks:

1. Communication Overhead

// Without isolation: direct function call
widget.updateSchema(newSchema); // Instant

// With isolation: message passing
iframe.contentWindow.postMessage(
  { type: 'update', payload: { schema: newSchema } },
  'https://widget-provider.com'
);

There is a small overhead due to message passing, but in practice it’s negligible. The postMessage API is asynchronous and designed for efficient cross-context communication.

2. No Direct DOM Access (from the host)

// ❌ Host cannot access iframe DOM
const iframe = document.getElementById('widget-frame');
const widgetElement = iframe.contentWindow.document.querySelector('.button');

widgetElement.style.color = 'red'; // Blocked by Same-Origin Policy

// ✅ Use message passing instead
iframe.contentWindow.postMessage(
  { type: 'style:update', payload: { color: 'red' } },
  'https://widget-provider.com'
);

The host page cannot directly read or modify the widget’s DOM due to the Same-Origin Policy.

This is a feature, not a limitation—it enforces strict isolation and prevents unintended or malicious interference.

3. Debugging is Slightly Harder

The widget runs inside an iframe, so its JavaScript executes in a separate context.

This means:

You won’t see logs directly in the main page context
You need to switch to the iframe in DevTools

Modern browsers make this easy by clearly listing iframe contexts, so debugging remains straightforward once you know where to look.

Why This Architecture Wins

Consistent UI everywhere — Host CSS/JS can't affect the widget.
Strong isolation by default — Same-Origin Policy blocks DOM, JS, and storage access.
Secure data boundaries — Tokens and user data stay private.
Clear debugging responsibility — Widget issues originate from widget code, never host interference.
Uniform security — Same protection across all integrations.

Bottom line: a small integration cost for major gains in security, reliability, and predictability.

Closing Thoughts

Embedding a third-party widget into an untrusted environment is inherently risky. Cross-origin iframe isolation removes that risk entirely.

By sacrificing direct DOM access and adding a message-passing layer, you gain:

Total CSS isolation
Complete JavaScript sandboxing
Protection from XSS and session hijacking
Predictable behavior across all host sites

For any widget that will be embedded in unknown or potentially hostile environments, cross-origin isolation isn't optional—it's mandatory.

Questions about iframe security or widget architecture?

Drop a comment below or reach out on LinkedIn

Decoupling UI from Code in Modern Chat Widgets

Dhinesh K.S — Tue, 17 Mar 2026 12:52:44 +0000

⚡ TL;DR: Hardcoding chat widget variations is a frontend bottleneck. A JSON-driven rendering architecture lets the server describe the UI — the widget just validates, resolves, and renders it. Flexible, type-safe, and deployable without touching frontend code.

Modern chat widgets are no longer static UI containers—they're becoming dynamic platforms that serve multiple product teams, message types, and user experiences. This evolution introduces a critical architectural question:

How do you make the widget flexible enough to evolve quickly without turning every UI change into a code change and deployment?

One effective answer is to decouple UI structure from application code.

In this post, we’ll explore how a JSON-driven rendering architecture, combined with a component interface design, helps build chat widgets that are more scalable, extensible, and easier to evolve.

The Problem with Hardcoded UI

In traditional widget implementations, each message type maps directly to a React component in the codebase. Want a new card layout? Write a component. Want to reorder elements? Modify the code. Want to test a different button arrangement? Deploy.

This coupling between product decisions and engineering cycles becomes a significant bottleneck:

Every UI variation requires code changes
Pull requests and reviews slow iteration
Full deployment cycles for small layout tweaks
Product teams depend on engineering timelines

At scale, this is unsustainable. What we needed was a way for UI to evolve independently of the widget codebase.

The Solution: Description Over Prescription

Instead of hardcoding components, we inverted the model:

The Server describes what the widget should look like using a structured JSON schema.

The Widget interprets that description and renders the appropriate components.

Responsibilities are now cleanly separated:

Server: "Render a card with text and two buttons"
  ↓
Widget: "I'll parse that schema and render the exact components needed"
  ↓
Result: Dynamic UI that matches the schema

Example Schema

{
  "type": "card",
  "children": [
    {
      "type": "text",
      "value": "How can I help you?"
    },
    {
      "type": "row",
      "gap": "8px",
      "children": [
        {
          "type": "button",
          "label": "Track Order",
          "action": "postback"
        },
        {
          "type": "button",
          "label": "Talk to Agent",
          "action": "handoff"
        }
      ]
    }
  ]
}

This represents a component tree, where layout is implicitly defined by nesting. The rendering engine receives this JSON, walks the tree, resolves each type to a registered UI component, and produces the final interface.

The widget itself has no knowledge of specific layouts—it only knows how to resolve and render components.

How the Rendering Engine Works

The rendering engine follows a strict pipeline: validate → resolve → render.

1. Validation Layer (Zod): Trust Before Render

Before anything touches the UI, incoming schemas are validated against expected types:

const ButtonSchema = z.object({
  type: z.literal("button"),
  label: z.string(),
  action: z.string().optional()
});

const RowSchema = z.object({
  type: z.literal("row"),
  children: z.array(z.lazy(() => ComponentSchema)),
  gap: z.string().optional()
});

This ensures:

Missing fields are rejected before rendering
Invalid types are caught immediately
Unsupported structures never reach the widget

Only trusted, well-formed data enters the system.

2. Schema Registry: Defining the Contract

The Schema Registry acts as a formal contract between backend and frontend. Only known component types are allowed to render.

Each component type (card, text, button, row) must exist in this registry. Unknown types are rejected immediately, preventing silent failures.

3. Component Registry: Mapping Schema to UI

The Component Registry maps schema type strings to actual React components:

const componentRegistry = {
  text: TextComponent,
  button: ButtonComponent,
  card: CardComponent,
  row: RowComponent
};

This enables:

Pluggable architecture
Easy extensibility
Clear separation of concerns

4. Component Interface Design: Props & Contracts

For the rendering engine to work reliably, every component must have a well-defined interface. This means clearly specifying what props each component accepts, how they're validated, and how they interact with the widget.

Props Validation with Zod

Each component type has a corresponding Zod schema that validates its props:

// Define what a button component expects
const ButtonPropsSchema = z.object({
  type: z.literal("button"),
  label: z.string().min(1),
  action: z.string(),
  disabled: z.boolean().optional(),
  styles: ButtonStylesSchema.optional()
});

// Define what a text component expects
const TextPropsSchema = z.object({
  type: z.literal("text"),
  value: z.string(),
  align: z.enum(["left", "center", "right"]).optional(),
  styles: TextStylesSchema.optional()
});

// Define what a row component expects (generic layout container)
const RowPropsSchema = z.object({
  type: z.literal("row"),
  children: z.array(z.lazy(() => ComponentPropsSchema)),
  gap: z.string().optional(),
  styles: RowStylesSchema.optional()
});

// Combine all schemas
const ComponentPropsSchema = z.discriminatedUnion("type", [
  ButtonPropsSchema,
  TextPropsSchema,
  CardPropsSchema,
  RowPropsSchema
]);

This ensures:

✅ Required props are present
✅ Prop types are correct
✅ Unknown props are rejected
✅ Invalid data never reaches components

Mapping JSON to Component Props

Once validated, the schema node is mapped to actual React component props:

const ComponentRegistry = {
  button: (props) => <Button {...props} />,
  text: (props) => <Text {...props} />,
  card: (props) => <Card {...props} />,
  row: (props) => <Row {...props} />
};

const renderNode = (node) => {
  // Validate props against schema
  const validatedProps = ComponentPropsSchema.parse(node);

  // Get component from registry
  const Component = ComponentRegistry[validatedProps.type];

  if (!Component) {
    return <FallbackComponent type={validatedProps.type} />;
  }

  // Render with validated props
  return <Component {...validatedProps} />;
};

Event Handling & Callbacks

User interactions (clicks, form submissions) are handled through action callbacks:

{
  "type": "button",
  "label": "Track Order",
  "action": "track_order_postback"
}

The widget captures the interaction and sends it back to the server:

const handleButtonClick = (action: string) => {
  // Send action to server via postMessage
  window.parent.postMessage(
    {
      type: "user_action",
      payload: { action }
    },
    "*"
  );
};

// In the button component
<button onClick={() => handleButtonClick(props.action)}>
  {props.label}
</button>

Flow:

User clicks button
Widget captures click and extracts action
Widget sends postMessage to server
Server processes action and responds with new schema
Widget re-renders with updated content

Type Safety Across Boundaries

For type safety between server (backend) and client (widget), define shared types in a common package:

// packages/shared-schemas/component.ts
export const ButtonSchema = z.object({
  type: z.literal("button"),
  label: z.string(),
  action: z.string(),
  disabled: z.boolean().optional()
});

export type ButtonProps = z.infer<typeof ButtonSchema>;

// Backend uses it for response validation
const response: ButtonProps = {
  type: "button",
  label: "Continue",
  action: "next_step"
};

// Frontend uses same type for rendering
const render = (props: ButtonProps) => <Button {...props} />;

This ensures type safety across the entire system — schema definition, validation, and rendering all use the same source of truth.

5. Parse → Resolve → Render

The engine recursively walks the validated schema structure:

1. Parse validated schema
2. Resolve component type from registry
3. Pass props to component
4. Recursively render children

card
 ├── text
 └── row
      ├── button
      └── button

Each level of the tree is independently resolved and rendered.

Design Tokens & Theming through JSON

Components in the registry can accept design tokens as props, allowing the server to control styling without shipping CSS changes.

This extends the rendering engine's flexibility to include visual properties:

{
  "type": "button",
  "label": "Track Order",
  "action": "postback",
  "styles": {
    "backgroundColor": "primary",
    "textColor": "white",
    "variant": "solid"
  }
}

Instead of hardcoding button colors, the server specifies a token. The component resolves it against a design token map:

const designTokens = {
  primary: "#FFD700",
  secondary: "#F5F5F5",
  text: {
    primary: "#000000",
    secondary: "#666666"
  },
  spacing: {
    sm: "8px",
    md: "16px",
    lg: "24px"
  }
};

const resolveToken = (tokenPath: string) => {
  return tokenPath.split('.').reduce((obj, key) => obj[key], designTokens);
};

Why This Matters

Server-side theming — Brands can customize colors, spacing, typography without widget code changes
Consistent design language — All components use the same token system
A/B testing — Test different color schemes or spacing by changing tokens server-side
Runtime customization — Different organizations can embed the same widget with different branding

Example with Tokens

{
  "type": "card",
  "styles": {
    "padding": "md",
    "backgroundColor": "surface"
  },
  "children": [
    {
      "type": "text",
      "value": "How can I help you?",
      "styles": {
        "color": "text.primary",
        "fontSize": "lg"
      }
    },
    {
      "type": "button",
      "label": "Continue",
      "styles": {
        "backgroundColor": "primary",
        "borderRadius": "md"
      }
    }
  ]
}

The rendering engine resolves each token reference at render time, producing a fully styled component tree that reflects both server-side intent and client-side design system.

Final Pipeline

Why This Architecture Scales

Flexible UI Composition

Product teams can ship new message types (carousels, date pickers, rich media) without coordinating a widget release. The schema evolves independently of the rendering logic.

Faster Product Iteration

Experiment with layout variations without frequent deployments. Changes ship from the server immediately.

Deterministic Rendering

The rendering engine behaves like a pure function:

JSON Input → Validated Schema → UI Output

Given the same JSON, it always produces the same UI. Easy to test, predict, and debug.

Clear System Contracts

The JSON schema becomes a formal interface between backend and widget. Both sides know exactly what to expect.

Type-Safe Development

Shared type definitions ensure correctness across the whole stack — from schema design to component props to rendering.

Graceful Degradation

Unknown component types can fail safely without breaking the entire widget:

const Component = componentRegistry.get(node.type);
if (!Component) {
  return <FallbackComponent message={`Unknown type: ${node.type}`} />;
}
return <Component {...node.props}>{node.children}</Component>;

The Tradeoff: Schema Complexity

This architecture shifts complexity from UI code to schema design. You now need to think carefully about:

Schema expressiveness — Can it describe all the UI variations you need?
Versioning strategy — How do you evolve the schema without breaking existing clients?
Backward compatibility — Can old schemas work with new rendering engines?
Props contracts — How do you handle prop changes across component types?

However, for systems that require continuous evolution, the flexibility more than justifies this upfront investment. Schema design happens once; UI iteration happens continuously.

Real-World Impact

In practice, this architecture has allowed us to:

Ship new message types without deploying the widget
Test layout variations server-side before rolling out
Support different message types across multiple products from a single widget
Keep the rendering engine lightweight, predictable, and testable
Enable type-safe development with shared schemas across backend and frontend

Key Insight

Rendering isn't the hard part—ensuring the input is valid, contracts are clear, and types are safe is what makes the system production-ready.

By combining strict validation, well-defined component interfaces, design tokens, and a pluggable registry, we built a system that's both flexible and safe.

Next in the Series

In the next post, we'll explore how cross-origin iframe isolation ensures the widget remains safe and predictable regardless of where it's embedded.

Stay tuned.

Questions? Drop a comment below or reach out on LinkedIn