---
# System prepended metadata

title: UI Builder (Design to Code)
tags: [pitch]

---

---
robots: noindex, nofollow
tags: pitch
---

# UI Builder (Design to Code)

### Problem
There is no way for users to test production components and themes work correctly together without writing code.

### Appetite
We need a way to rapidly validate that our components can be used together successfully. This is mostly about layout and styling of the components in a given theme.

### Solution
Implement **UI Builder** - UI editor for creating UI examples:
- You can drag and drop N* components into an interface.
- You can remove components from the UI you've built.
- You can select components and show the props panel.
- You can edit props using appropriate form controls.
- Local storage is used to save/load your work.
- Sharable link - a self-contained link which allows you to share your work.
- CodeSnippet editor
    - drag & drop editor generates code you can use in real application,
    - you can edit the code directly, changes are reflected in the builder.
-  Tree view for easily selecting components and their children.

Stretch goals:
- Integrate v7 components.
- Add option to create/edit component variants (compose).

#### Similar works:
https://blocks-ui.com
https://openchakra.app
https://tailwind.build
https://create.fast.design

### Risks (Rabbit holes)
Props editor requires information about components. We will reuse work done for N* playground but it might still require additional work.

There are unknows about codesnippet editor code to builder.

### Out of scope (No-gos)
The whole UI Builder will take more time than a single iteration to be finished. There are things which are out of scope for the initial iteration:
- Editing shorthands.
- Limiting what component can be dropped into what component.
- User can add/edit functions as component props.
- Make useful for "bluelines"
    - Generate visual pointers to components with display names
    ![](https://i.imgur.com/SRnvyZ7.png)

# Tasks

- [x] Expand layout should not stomp on existing component styles.  Example, components with existing padding/margin/borders should remain if they are sufficient.
- [x] Select dropped component
- [ ] Add remaining FUI0 components, check what's broken
    - [ ] Autogenerate `DRAGGING_ELEMENTS`
        - [x] start with <Component />
        - [ ] autogenerate required props
    - [ ] Try to render all components upfront to detect all broken and inform the user in advance
- [ ] Add v7, Material UI, FUI-Icons components
- [x] Fix DebugFrame styles (https://www.toptal.com/designers/htmlarrows/symbols/)
- [x] Make root full height in Design mode
- [ ] Support single value (both string and element) in props.children (now it expects an array)
- [ ] Fix <div /> in DRAGGING_ELEMENTS
- [x] d&d selector to allow to drop before and after
    - [ ] d&d to tree? -> NOT NOW
## For the next project cycle
- Limiting what component can be dropped into what component will still be nice to have. You can break things the same way when writing code directly.
