DEV Community: Amith Moorkoth

Lessons from Building Bombie: SPA Deep Links, CSP, and an Iframe Preview

Amith Moorkoth — Thu, 21 May 2026 16:56:50 +0000

This is the final post in the Bombie series. The earlier ones covered what Bombie is, the JSON-tree architecture, and how to add a new component. This one is about the operational stuff that's invisible when it works — and obvious when it doesn't.

Three lessons, each with the same shape: a problem I didn't anticipate, the fix that landed in the repo, and what I'd do the same way next time.

Lesson 1: SPA deep links on GitHub Pages need a shim

The first time I deployed Bombie to GitHub Pages, the builder route worked from the homepage. Click "Open builder", land at /bombie/generate-component, everything renders. Then I refreshed the page and got a 404.

GitHub Pages serves static files. It doesn't know anything about React Router. When you hit /bombie/generate-component directly, Pages looks for a file at that path, doesn't find one, and returns its 404 page. Vercel handles this with a single rewrites rule in vercel.json — anything that doesn't match a real file rewrites to /index.html, React Router takes over from there. GitHub Pages has no equivalent.

The workaround Bombie uses lives in two files:

public/404.html — the 404 page Pages returns when it can't find a file.
public/spa-redirect.js — a tiny inline script in that 404 page.

The script reads the unfindable path, encodes it as a query string, and redirects to the root index.html with that query string attached. React Router boots, sees the query string, and pushes the real route into history. The 404 was real but it's now invisible — one extra redirect, no observable difference to the user past the initial flash.

The trick isn't novel (it's the Rafgraph spa-github-pages pattern, well-documented in the React Router community) but the part worth saying out loud is that you'll never notice the problem until you ship to a static host that doesn't do rewrites. Local dev with webpack-dev-server does rewrite to index.html by default. Vercel does too. GitHub Pages doesn't. If your deploy story might ever cross hosts, get this in early.

What I'd do the same next time: write the shim, but also pick one canonical host. Bombie ended up on Vercel (bombie-three.vercel.app) because the rewrite is a one-liner and there's no flash. The GitHub Pages workflow stayed in the repo for anyone who wants to deploy a fork there, with the shim handling the corner case.

Lesson 2: One CSP for dev and prod is wrong

Content Security Policy is one of those things that looks easy on the homepage and gets weird in practice. The default advice ("set script-src 'self'") is correct for production. It's also incompatible with webpack-dev-server's HMR client, which uses eval for hot module replacement.

So you have two options:

Make production weaker so dev works.
Make dev and prod use different CSPs.

Bombie picks option 2. The CSP is set per-mode in the webpack config:

// roughly
const csp = isDev
  ? "script-src 'self' 'unsafe-eval'; ..."
  : "script-src 'self'; ...";

'unsafe-eval' is only in the dev CSP. The production bundle gets the strict policy. There's no 'unsafe-eval' in the running app once you npm run build.

The reason I'm flagging this: it's tempting to drop 'unsafe-eval' into the meta tag and forget about it, because the dev console will stop complaining and prod won't immediately break. But CSP violations don't fail loudly in production — they just block scripts. You won't notice until someone tries to use a third-party widget you added later that happens to call eval.

Set the strict policy in prod from day one, even if you're not currently using anything that would benefit. Then if a future dependency starts calling eval and the CSP blocks it, you'll see the violation immediately and decide whether to allow it explicitly or replace the dependency. With a loose CSP you'd just ship a quiet regression.

The dev-mode 'unsafe-eval' is fine because it never ships. The build pipeline strips the dev block of the config and only the prod CSP lands in the deployed index.html.

Lesson 3: Use an iframe when you need an honest viewport

This one I covered briefly in the architecture post, but it's worth restating because it's the kind of decision you'd skip if you were optimizing for code volume.

Bombie's live preview shows your layout at mobile (~375px), tablet (~768px), and desktop (~1280px) widths. The naive approach is to wrap the preview in a <div> and set its CSS width to the target value:

<div style={{ width: 375 }}>
  <Preview />
</div>

This visually shrinks the preview, but it lies about responsive behavior. MUI's Grid uses useMediaQuery under the hood, which reads window.innerWidth. The <div> is 375px but the window is still 1280px or whatever your laptop is. xs={12} md={6} stays at one column because MUI thinks it's on a desktop.

The fix is an iframe:

<iframe ref={previewRef} style={{ width: '375px', height: '100%' }} />
// inside the iframe: render the preview tree, which now sees its own window object

The iframe has its own window, its own document, and its own viewport. useMediaQuery reads that window. Grid breakpoints fire correctly. Hover and focus styles work. Modals (Dialog) render attached to the iframe's body. Everything you'd want from "what does this look like on mobile" actually behaves like mobile.

The cost is real:

Bootstrapping the iframe means injecting the stylesheet and MUI providers (the theme, the cache) into its document.
Communicating from the outer app to the inner iframe uses postMessage or a shared module — you can't just pass props across the boundary.
The iframe takes a few hundred milliseconds to come up on a cold load.

In Bombie, the iframe receives the JSON tree via postMessage from the outer toolbar, and the preview-side bootstrap script runs render-preview.js on whatever tree it most recently received. The MUI cache and theme are injected on first load. Resize is just setting the iframe's width style.

I'd absolutely do this again. The honest viewport is worth the setup cost — especially for a tool whose entire pitch is "see what this looks like." Anything that ships responsive previews without an iframe is either accepting a lie or doing a lot of work to fake it with useMediaQuery overrides; either way the iframe is cheaper.

Things that aren't lessons (yet)

A few things in the repo are still rough and I'm holding off on calling them lessons until I've solved them properly:

Upload / Download JSON. The buttons exist in the toolbar but they're stubs. The serialization story is straightforward (it's JSON.stringify(tree)), but the user-facing flow — what filenames, what happens on a malformed paste, how to show diff between current state and uploaded state — needs more thought than I've given it.
Bundle size. MUI is heavy. Bombie's bundle is fine for an experiment but it's not lean. npm run analyze produces a bundle-report.html and the obvious targets (date pickers loaded eagerly, icon barrel imports) are still there.
TypeScript. Mentioned in the architecture post. Worth doing, not yet done.

If any of these resonate as something you'd like to tackle, the repo's open and PRs are welcome.

Wrapping up the series

The four posts together cover what Bombie is, how it's structured, how to extend it, and the operational decisions behind it:

Introducing Bombie — what and why
How I Built a Visual UI Builder for React with a JSON-Driven Tree — architecture
Add Your Own Component to Bombie in 5 Edits — extension tutorial
Lessons from Building Bombie — this post

The underlying ideas — UI as a JSON tree, two renderers from one source of truth, schema-driven property editor, iframe for honest viewports — are reusable past Bombie itself. If you're building any kind of visual editor or layout tool, the JSON-tree-plus-two-renderers split has been the single highest-leverage decision in the codebase.

Bombie itself is an experiment, not a product. But the patterns are not.

If you've read this far: try the live demo, star the repo if it was useful, and open an issue or a PR if you'd like to see something different. The whole point of writing this series was to make the project legible enough that other people could contribute to it.

Links

Repo: https://github.com/amith-moorkoth/bombie
Live demo: https://bombie-three.vercel.app/
The series: Introducing Bombie · Architecture · Add a Component · Lessons

Add Your Own Component to Bombie in 5 Edits

Amith Moorkoth — Thu, 21 May 2026 16:54:55 +0000

This is the third post in the Bombie series. The first post was an intro, the second covered the architecture. This one is a hands-on walkthrough: take a Material-UI component that isn't already in Bombie, and wire it up so it appears in the palette, drags onto the canvas, opens a property editor, and renders in the live preview.

The whole change is five small edits across the same five files for every new component. Once you've done one, the next one takes about ten minutes.

I'll use Rating as the running example. It's a single-leaf component (no children), it has a small but meaningful prop surface (value, max, precision, size, readOnly, disabled), and it's not already in the catalog.

Prerequisites

Clone and run Bombie locally:

git clone https://github.com/amith-moorkoth/bombie.git
cd bombie
cp .env.example .env
npm install
npm start

You'll get the builder at http://localhost:8080/generate-component. Open src/Lib/ComponentGenerator/ — every file you're going to touch lives under there.

Edit 1: register the component in the catalog

The catalog is the source of truth for what Bombie knows about. It lives in two files:

Data/element-base.js — display name + tag
Data/elements.js — drag-and-drop type info

Add Rating to element-base.js:

// src/Lib/ComponentGenerator/Data/element-base.js
export const ELEMENT_BASE = {
  // …existing entries
  Rating: { tag: "Rating", displayName: "Rating" },
};

And to elements.js:

// src/Lib/ComponentGenerator/Data/elements.js
export const ELEMENTS = {
  // …existing entries
  Rating: {
    type: "leaf",         // it's a leaf, no children
    accept: [],           // it doesn't accept any drops
  },
};

type controls where this component can be dropped (most things accept "leaf"). accept is what this component allows as a child — empty for leaves like Rating, populated for containers like Box / Grid / Stack.

Edit 2: write the builder UI file

This is the only new file you'll create. It defines two things: the schema (what the property editor shows) and the render (what the canvas draws).

Create src/Lib/ComponentGenerator/Container/UI/Rating.js:

// src/Lib/ComponentGenerator/Container/UI/Rating.js
import Rating from "@mui/material/Rating";
import { makeLeafComponent } from "./Common/make-component";

export default makeLeafComponent({
  tag: "Rating",

  schema: {
    Appearance: {
      size: {
        type: "select",
        options: ["small", "medium", "large"],
        default: "medium",
      },
      max: {
        type: "number",
        default: 5,
        min: 1,
        max: 10,
      },
      precision: {
        type: "select",
        options: [0.5, 1],
        default: 1,
      },
    },
    State: {
      value: {
        type: "number",
        default: 3,
        min: 0,
      },
      readOnly: { type: "boolean", default: false },
      disabled: { type: "boolean", default: false },
    },
  },

  render: ({ props }) => <Rating {...props} />,

  // Optional defaults applied when the component is dropped on the canvas
  defaultProps: { value: 3, max: 5, precision: 1, size: "medium" },
});

A few notes on what's happening here:

makeLeafComponent is a factory from UI/Common/make-component.js. It wraps the renderer with the builder chrome (selection outline, wrench button, delete button) and registers the schema so the property editor knows what controls to show.
Schema groups become sections in the property dialog. "Appearance" gets one card, "State" gets another. This is what makes the editor scannable instead of a wall of inputs.
Field types the editor knows about: string, number, boolean, select, color. Anything else falls through to a text input.
render receives the node's props (already merged with defaults) and returns plain JSX. No builder logic in this function — that's what the wrapper handles.

For container components (Box, Grid, Stack, Card, etc.) you'd use makeContainerComponent instead. It accepts the same schema / render shape but also wires up a <DropBox> around the children so things can be dropped inside.

Edit 3: register it in the renderer switch

The canvas uses a central registry to know which builder UI file handles which tag. Add Rating to it:

// src/Lib/ComponentGenerator/Container/element-render.js
import Rating from "./UI/Rating";
// …other imports

export const REGISTRY = {
  // …existing entries
  Rating,
};

This is the registry the recursive renderer (element-recursion.js) consults for every node it walks. node.info.tag looks up its renderer here.

Edit 4: add an icon + put it in a palette category

The palette in the left sidebar groups components by category. Two small additions:

// src/Lib/ComponentGenerator/Elements/icon-map.js
import StarIcon from "@mui/icons-material/Star";
// …

export const ICON_MAP = {
  // …existing entries
  Rating: StarIcon,
};

// src/Lib/ComponentGenerator/Elements/index.js
export const CATEGORIES = {
  Layout:      [/* … */],
  "Form Elements":  ["TextField", "Select", /* …, */ "Rating"], // add here
  "Data Display":   [/* … */],
  Feedback:    [/* … */],
  Navigation:  [/* … */],
};

Categories are just arrays of tags. Pick the one that makes sense — Rating is technically a form input but it's also a display element. I put it under "Form Elements" because it has a value and a readOnly mode, but "Data Display" is a defensible choice too.

Edit 5: teach the preview about it

The live preview has its own renderer (render-preview.js) that emits clean MUI JSX without builder chrome. It uses a switch keyed by tag — add a branch:

// src/Lib/ComponentGenerator/Preview/render-preview.js
import Rating from "@mui/material/Rating";
// …

const RENDERERS = {
  // …existing entries
  Rating: ({ node }) => <Rating {...node.props} />,
};

That's it. The preview will now render Rating the same way the canvas does, minus the outline and wrench.

Testing your change

Hot-reload should pick everything up. Open the builder, find "Rating" in the Form Elements category, drag it onto the canvas. You should see five stars with the third one filled in (your defaultProps.value: 3).

Click the wrench. You should see the property dialog with two sections — "Appearance" with size / max / precision, and "State" with value / readOnly / disabled. Flip "readOnly" to true, change value to 4.5 (oh wait — precision is 1; set precision to 0.5 first, then 4.5 works).

Click Preview. The iframe shows your component without any builder chrome. Toggle Mobile / Tablet / Desktop — Rating doesn't have responsive breakpoints itself, but if you'd dropped it inside a Grid it would reflow correctly.

If something doesn't render: the most common culprit is forgetting Edit 3 (register in element-render.js) or Edit 5 (register in render-preview.js). One controls the canvas, the other controls the preview, and the symptoms are different — canvas-only failures mean a missing entry in element-render.js, preview-only failures mean a missing entry in render-preview.js.

What about container components?

For containers, two things change:

Use makeContainerComponent instead of makeLeafComponent. It wraps a <DropBox> around the rendered children.
In elements.js, set type: "container" and populate accept with the tags this container will receive (usually ["leaf", "container"] to allow nesting).

The render function for a container gets children it should render the canvas-rendered subtree into. Example skeleton:

makeContainerComponent({
  tag: "MyContainer",
  schema: { /* … */ },
  render: ({ props, children }) => (
    <MyContainer {...props}>{children}</MyContainer>
  ),
});

children here is the already-rendered subtree (with builder chrome on the canvas, plain JSX in the preview).

A note on prop validation

Bombie doesn't enforce prop validation beyond what MUI itself does at runtime. If you put value: 99 on a Rating with max: 5, MUI will clamp it. The schema's min/max hints are advisory — the editor uses them for its number input UI, but the property dialog won't refuse to let you save an out-of-range value.

In practice this hasn't been a problem because the editor's controls (select dropdowns, numeric inputs with min/max) make it hard to enter nonsense in the first place. But if you're adding a component with strict prop constraints, document them in the schema using a description field — the property dialog will surface it as helper text.

Recap

For any new component, the five edits are:

Catalog — Data/element-base.js + Data/elements.js
Builder UI — one new file under Container/UI/
Renderer registry — add to REGISTRY in element-render.js
Palette — add icon to icon-map.js and tag to Elements/index.js
Preview renderer — add a branch in render-preview.js

There's no central manifest file that needs to be regenerated, no build step that needs to run, no test that needs to pass before the new component shows up. Hot-reload picks everything up in seconds.

The whole architecture is built around making this addition cheap, because the practical value of Bombie scales with how many MUI components it knows about. PRs that add components are exactly the kind of contribution I want.

In the next post — last in this series — I'll cover the operational lessons: GitHub Pages SPA deep links, the CSP-per-mode setup, and why bombie-three.vercel.app ended up on Vercel even though the repo has a GitHub Pages workflow.

Links

Repo: https://github.com/amith-moorkoth/bombie
Live demo: https://bombie-three.vercel.app/
Previous post: How I Built a Visual UI Builder for React with a JSON-Driven Tree
Next post: Lessons from Building Bombie: SPA Deep Links, CSP, and an Iframe Preview

How I Built a Visual UI Builder for React with a JSON-Driven Tree

Amith Moorkoth — Thu, 21 May 2026 16:52:15 +0000

This is the second post in the Bombie series. The first post introduced what Bombie is: a drag-and-drop builder for Material-UI in React, with a live demo at bombie-three.vercel.app. This one is about how it's actually put together.

Bombie's whole design comes from a single decision early on: represent the UI as a JSON tree, and write two renderers against it — one for the builder canvas, one for the live preview. Every other feature is a consequence of that.

The data model

Every node in a Bombie layout has the same shape:

{
  id: "<uuid>",
  info: { tag: "Button", /* catalog metadata */ },
  props: { variant: "contained", color: "primary", children: "Save" },
  child: [ /* nested nodes, same shape */ ]
}

A whole layout is a tree of these. That's it.

id — stable identifier; used by the property editor to target a specific node and by react-dnd to know what's being moved.
info — catalog metadata pulled from the element registry. The tag field (e.g. "Button", "Grid") is what the renderers switch on.
props — the props that will eventually land on the real MUI component. This is what the property editor mutates.
child — nested nodes. Container components (Box, Grid, Stack, Container, Card, etc.) use this; leaf components (Typography, Button, etc.) leave it empty.

Saving a layout is JSON.stringify(tree). Loading is JSON.parse(json). That's the whole persistence story.

Mutating the tree

Mutating a deeply nested immutable tree is the kind of thing that, done naively, spawns three helper files and a Stack Overflow tab. Bombie's lives in one file: src/Lib/Utils/json-handler.js. It's a collection of recursive walks that take the root tree and the target node's id, and return a new tree.

The pattern is the same for every operation:

function updateNode(node, targetId, transform) {
  if (node.id === targetId) return transform(node);
  if (!node.child?.length) return node;
  return { ...node, child: node.child.map(c => updateNode(c, targetId, transform)) };
}

Everything specializes from there:

setProp(tree, id, key, value) → updateNode with a transform that returns { ...n, props: { ...n.props, [key]: value } }.
appendChild(tree, parentId, newNode) → updateNode on parentId, transform adds to child.
removeNode(tree, id) → filter child recursively.
move(tree, fromId, toParentId, index) → remove then insert.

Because the tree is immutable, React's useState + useMemo works without any special diffing. The Provider that holds the tree (under Controller/ComponentGenerator/) hands it down through a context (bombie-context.js) and exposes these handlers to the canvas, the palette, and the property editor.

The other utility worth calling out is js-dom-controller.js. It does dot-path get/set on nested objects — useful when a prop like slotProps.input.startAdornment needs to be edited from the property dialog. Together, json-handler (for tree mutations) and js-dom-controller (for nested prop paths) cover most of the editing surface.

Two renderers, one tree

Here's the design call that pays off the most: Bombie has two renderers for the same tree.

Builder canvas (`element-recursion.js`)

The canvas renders every node with builder chrome: a selection outline, a wrench button (open property editor), a delete button, drop-zone overlays via react-dnd. Containers render their children recursively as drop targets, so you can nest a Stack inside a Grid inside a Box to whatever depth you want.

Two complications the canvas has to handle that a clean preview doesn't:

Drop targets need real space. An empty Box would collapse to zero pixels, so the canvas-side container components apply a minimum size and a dashed outline when empty.
Modals are inline. A Dialog in the canvas renders inline (not as an actual modal) so you can edit the dialog's content tree. If it rendered as a real modal, you couldn't see the content unless you opened it — which is fine for previewing but useless for editing.

Iframe preview (`render-preview.js`)

The preview walks the same tree and emits clean MUI JSX. No outlines, no wrench buttons, no minimum heights. A Dialog becomes a real <Dialog> with a generated trigger button: click the trigger, the dialog opens, click any button inside, it closes. That's important because dialog UX is the kind of thing you actually want to feel before you ship it.

The preview lives inside an <iframe>. Three buttons in the toolbar resize the iframe to common mobile, tablet, and desktop widths. This matters: MUI's Grid breakpoints (xs, sm, md, lg, xl) react to the window they're rendered in. If you just rendered the preview in a <div> and shrank the div with CSS, MUI would still see the outer browser width and skip the breakpoint behavior entirely. Putting it inside an iframe gives it a real, smaller window — so xs={12} md={6} actually flips to two columns when you click "Desktop" and back to one when you click "Mobile."

If you only take one architectural idea from Bombie, take that one. "Use an iframe when you need an honest viewport" is worth the cost of the iframe.

The split between the two renderers is enforced by a RENDERERS switch in Preview/render-preview.js — one branch per supported component, with props.children mapped recursively through the same switch.

The schema-driven property editor

MUI components have a lot of props. Button alone has variant, color, size, disabled, disableElevation, fullWidth, href, startIcon, endIcon, and a handful more. A generic property editor that shows them all as labelled text inputs would technically work, but it would be unusable.

Bombie's editor reads a schema declared next to each component. Schemas group props into sections and give each prop a type — select, boolean, string, number, color — that the editor knows how to render. So Button's schema groups variant / color / size under "Appearance", disabled / disableElevation under "State", and href / startIcon / endIcon under "Behavior", and each field renders as the right control. The dialog adds a section per group, so even a high-cardinality component is navigable.

Schemas live next to the builder UI files (under Container/UI/) and are declared with makeLeafComponent or makeContainerComponent factories from UI/Common/make-component.js. The factories pair a schema with a render function, and the editor + the canvas read them both.

I'll cover authoring a new component in detail in the next post — it's about five small edits — but the schema is what makes the editing experience feel deliberate instead of dumped.

Drag and drop with type guards

Drag-and-drop on the canvas uses react-dnd. Two small abstractions wrap the primitives: DragBox (a draggable wrapper, used by the palette and by placed components) and DropBox (a drop target, used inside container components).

Each component in the catalog declares type (what kind of slot it can be dropped into) and accept (what it accepts as children). The accept rules prevent, for example, a TextField from being dropped directly into a Typography, and prevent layout containers from nesting things that don't make sense. react-dnd's useDrag and useDrop enforce these at the source — canDrop returns false and the cursor + outline change.

The element catalog (the source of truth for type and accept) lives in Data/element-base.js and Data/elements.js. Adding a new component means adding a row to those — see the next post for the full walkthrough.

Putting it together

The pieces talk to each other through the context provider:

ComponentGenerator (provider)
├── Elements/        (palette — sources of DragBox)
├── Container/       (canvas — recursive renderer, holds the tree)
│   └── UI/          (per-component builder files + property schemas)
├── Preview/         (iframe renderer for the same tree)
└── Samples/         (pre-built JSON trees that hydrate the canvas)

A drag from the palette dispatches appendChild on the tree. A click on the wrench opens the property editor, which dispatches setProp per change. A click on "Preview" passes the current tree through a postMessage to the iframe, which runs render-preview.js on it. A click on "Sample → Sign-in card" calls setTree(SAMPLES.signIn) and the canvas re-renders the whole thing.

Everything routes through that single tree state. There's no hidden parallel state for the canvas. Whatever the JSON says, that's what's on the screen.

What I'd change if I started over

A few things would be different in a v2:

TypeScript from the start. The JSON-tree shape is dynamic, but the schemas are well-defined enough that they'd benefit from types. Today they're documented by example.
Schemas as the source of truth for renderers. Right now the schema (props the editor knows about) and the render function (props the canvas/preview actually uses) are kept in sync by hand. A v2 could derive both from one declaration.
Tree as a flat map. Recursive immutable updates are O(depth) per change. A Record<id, node> plus a Record<id, childIds> would let every mutation be O(1).

None of these are urgent — Bombie is small enough that the recursive walks finish in microseconds — but they're the directions a serious version would take.

What's next

In the next post I'll walk through adding a brand new component to Bombie end-to-end, covering exactly the five files you need to touch and showing how makeLeafComponent / makeContainerComponent keep the additions small. After that, a final post on the operational lessons — SPA deep links on GitHub Pages, the CSP-per-mode setup, and what bombie-three.vercel.app actually does on a cold load.

If you want to follow along, the repo is at github.com/amith-moorkoth/bombie and PRs / issues are welcome.

Links

Repo: https://github.com/amith-moorkoth/bombie
Live demo: https://bombie-three.vercel.app/
Previous post: Introducing Bombie
Next post: Add Your Own Component to Bombie in 5 Edits

Introducing Bombie: A Drag-and-Drop Builder for Material-UI in React

Amith Moorkoth — Thu, 21 May 2026 16:15:32 +0000

Most of the time, building a React UI with Material-UI looks like this: open the docs, copy a <Button variant="contained" color="primary">…</Button>, paste it into your component, tweak props, save, alt-tab to the browser, reload, repeat. It works — but for sketching layouts or onboarding new developers to MUI's prop surface, the loop is heavier than it needs to be.

Bombie is an experiment in shortening that loop. It's a drag-and-drop visual builder for Material-UI in React. You drop components onto a canvas, edit their props through a grouped property dialog, preview the result at mobile, tablet, or desktop widths, and the whole UI is serialized as a JSON tree under the hood.

You can try it right now without cloning anything: bombie-three.vercel.app.

This post is the first in a series. Here I'll cover what Bombie does, who it's for, and the design ideas behind it. Later posts will go into the architecture, how to add a new component in five small edits, and the lessons I picked up shipping it.

What Bombie actually does

Bombie ships with 40+ draggable Material-UI components organized into five categories:

Layout — Box, Grid, Stack, Container, dividers
Form Elements — TextField, Select, Checkbox, Switch, Slider, buttons
Data Display — Typography, Card, Table, List, Avatar, Chip
Feedback — Alert, Snackbar, Dialog, Progress
Navigation — AppBar, Tabs, Breadcrumbs, Menu

Drag any of them from the palette onto the canvas. Click the wrench icon on a placed component and you get a grouped property editor — variant, color, size, state, behavior — instead of one flat list of inputs. That's the bit I'm most proud of, because MUI's prop surface is wide and a generic "key/value" editor would be miserable to use. Bombie defines a per-component schema and the editor renders form controls from it.

Switch to Preview and the same tree renders inside an iframe with mobile, tablet, and desktop viewport toggles. Because the breakpoint logic is evaluated against the iframe's actual viewport (not the outer browser), MUI's responsive Grid behavior matches what end-users will see. Dialogs render as real modals in preview mode — Bombie generates a trigger button and an actual <Dialog>, and clicking any button inside dismisses it. In the builder canvas the dialog body stays flat so you can keep editing it.

If you want a starting point instead of an empty canvas, there are four sample templates you can load with one click: a sign-in card, a stats dashboard, a settings panel, and an FAQ + support page with an accordion and a dialog.

Who Bombie is for

Bombie isn't trying to replace Figma, and it isn't trying to be a no-code product builder you'd hand to a non-developer for production work. The README is explicit on that point: it's experimental, not production ready, and a couple of toolbar features (Upload JSON / Download JSON) are still placeholders.

What it's actually useful for:

Learning MUI's prop surface. New to Material-UI? Dragging a Button onto the canvas and flipping through variant, color, size, and disabled in a grouped form is faster than reading the docs page for each one.
Prototyping layouts. When you want to see whether a Grid+Card+Typography composition actually responds the way you think, Bombie's iframe preview shows you the truth at three breakpoints in seconds.
Demonstrating ideas. The JSON serialization means a layout is a single artifact you can paste into an issue or a chat.

If you're shipping a real product, keep writing components by hand. If you're exploring, teaching, or making a prototype, Bombie is meant to save you some friction.

The core idea: UI as a JSON tree

The thing that ties all of Bombie's features together is a single representation:

{
  id: "<uuid>",
  info: { tag: "Button", /* catalog metadata */ },
  props: { variant: "contained", color: "primary", children: "Save" },
  child: [ /* nested nodes */ ]
}

Everything else falls out of that:

The drag-and-drop canvas is a recursive renderer over this tree.
The property editor writes back to the props of the selected node by id.
The live preview walks the same tree and emits clean MUI JSX without builder chrome.
Save / load is just JSON.stringify and JSON.parse.

I'll dig into the renderer split — builder vs preview — in the next post in this series, because it's where most of the interesting decisions live.

Tech stack at a glance

For anyone curious before cloning:

React 18 (createRoot bootstrap)
Material-UI (MUI)
react-dnd for the drag-and-drop primitives
Webpack 5 with HMR via webpack-dev-server
Jest for unit + component tests
ESLint + Prettier + Husky for the dev loop
Deployed on Vercel; GitHub Pages workflow included as an alternative

98% of the code is JavaScript. There's no TypeScript yet — partly because the JSON-tree shape is dynamic enough that strong types would have meant a lot of any early on, and partly because Bombie started as a personal experiment.

Try it, fork it, break it

The live demo is at bombie-three.vercel.app. The code is at github.com/amith-moorkoth/bombie under ISC. To run locally:

git clone https://github.com/amith-moorkoth/bombie.git
cd bombie
cp .env.example .env
npm install
npm start

The builder lives at http://localhost:8080/generate-component. On Windows you can double-click run.bat instead of running the three commands by hand.

In the next post I'll walk through the architecture: why there are two renderers (one for the builder, one for the preview), how the JSON-tree mutation helpers work, and what the iframe responsive preview actually does under the hood. If you want to follow along, star the repo or drop a comment with what you'd like to see next.

Links

Live demo: https://bombie-three.vercel.app/
GitHub: https://github.com/amith-moorkoth/bombie
Next post: How I Built a Visual UI Builder for React with a JSON-Driven Tree

Mozilla Multiple Page Cross browser PDF Viewer

Amith Moorkoth — Wed, 26 Apr 2023 17:34:59 +0000

https://github.com/amith-moorkoth/mozilla-pdf-demo

PDF.js is a Portable Document Format (PDF) viewer that is built with HTML5.

We have tried to bind multiple pages for the pdf renderer to show for a demo purpose, it is just a few lines of code which extends the above library.

Please let me know this is interesting, will try to enhance the viewer.

Drag and drop toolkit for React Material UI {custom made}, JSON based react forms Generator.

Amith Moorkoth — Wed, 15 Mar 2023 14:41:18 +0000

Introduction

We are going to discuss about a interesting toolkit that is available for react drag and drop utility.

🚨 Note: This project is just for demo purpose, cannot be used for production

Any kind of feedback is welcome, thanks and I hope you enjoy the article.🤗

👉 Packages used.
▶️ React JS (v.18)
▶️ React DND
▶️ Material UI

👉 Clone the Project.
https://github.com/amith-moorkoth/bombie

👉 Open Visual Studio Code
npm install

👉 For starting the project
npm start

👉 Once the project start running please go to the URL http://localhost:8080/generate-component to test the project

Now from here the article is going to be the complete workflow of the react DND bundle, which we have just created now.

Assuming that the reader already have prerequisite knowledge about the react, material UI and react DND.

👉 Begins (src\Controller\ComponentGenerator\index.js)

This is the Controller component where the actual process begins, here we are setting up the context provider for the entire application.

👉 Bombie Invokes our actual component for processing (src\Lib\ComponentGenerator\index.js)

This component is responsible for drawing the entire screen, which consist of two frames

Drawer
DND Provider

👉 **Drawer

This is responsible for the showing the JSON data that got generated through the process of drag and drop

👉 **DND Provider

This component responsibility includes

Showing the Element/custom Element that are available for dragging and can be dragged to the drawer for designing a component (src\Lib\ComponentGenerator\DragBox\index.js)

Draggable Container (src\Lib\ComponentGenerator\Container\element-recursion.js)

This is a recursive container which will recursively loop and attach the respective DOM, as per the current requirement.

🟠 Why we require JSON based React Material Toolkit? (why the project got started?)

Our Industry from the beginning is very thirsty about the drag and drop design with functionality includes over it. eg: WordPress, shopify etc...
We can store react component as JSON in **mongo db and access anywhere by using a single library in react as well as in JavaScript**, this will reduce the big overhead for performance and page loading since we will get the most optimized data which will travel between server and client.
Designers can have the control over the 70% development lifecycle.

...continue

DEV Community: Amith Moorkoth

Lessons from Building Bombie: SPA Deep Links, CSP, and an Iframe Preview

Lesson 1: SPA deep links on GitHub Pages need a shim

Lesson 2: One CSP for dev and prod is wrong

Lesson 3: Use an iframe when you need an honest viewport

Things that aren't lessons (yet)

Wrapping up the series

Add Your Own Component to Bombie in 5 Edits

Prerequisites

Edit 1: register the component in the catalog

Edit 2: write the builder UI file

Edit 3: register it in the renderer switch

Edit 4: add an icon + put it in a palette category

Edit 5: teach the preview about it

Testing your change

What about container components?

A note on prop validation

Recap

How I Built a Visual UI Builder for React with a JSON-Driven Tree

The data model

Mutating the tree

Two renderers, one tree

Builder canvas (element-recursion.js)

Iframe preview (render-preview.js)

The schema-driven property editor

Drag and drop with type guards

Putting it together

What I'd change if I started over

What's next

Introducing Bombie: A Drag-and-Drop Builder for Material-UI in React

What Bombie actually does

Who Bombie is for

The core idea: UI as a JSON tree

Tech stack at a glance

Try it, fork it, break it

Mozilla Multiple Page Cross browser PDF Viewer

Drag and drop toolkit for React Material UI {custom made}, JSON based react forms Generator.

Introduction

👉 Begins (src\Controller\ComponentGenerator\index.js)

👉 Bombie Invokes our actual component for processing (src\Lib\ComponentGenerator\index.js)

👉 **Drawer

👉 **DND Provider

Builder canvas (`element-recursion.js`)

Iframe preview (`render-preview.js`)