Unified

Keeping Different Views of a Component Together

A component can appear in several places before it reaches an application: a design canvas, a specification, and an implementation. A change to its label or dimensions may need to be repeated across those representations. Each copy introduces another place where the descriptions can diverge.

Unified explores a workspace built around a shared component model. Design, Code, Spec, and Architecture are visible side by side, and each offers a way to edit the component. Change a property in one panel and watch its other representations respond.

The demo is deliberately small. It works with a single component that can be switched between four types rather than presenting a complete application builder. Changing the type keeps the existing label, dimensions, and colours. That boundary makes it possible to explore how the views relate without hiding the underlying data behind a larger editing system.

From Properties to a Working Preview

The Design view presents a button, card, input, or toggle alongside controls for its label, dimensions, corner radius, and colours. The preview responds to those changes. Buttons provide interaction feedback, inputs accept text, and toggles can be switched on and off.

These interactions demonstrate the component types rather than a connected application. The input does not search a dataset, and the toggle does not change the portfolio's theme. Entered preview text and the toggle's checked state are not part of the shared model or undo history; changing a model property rebuilds the preview and clears that temporary state.

The distinction keeps the model focused. It describes the component's configurable appearance and content; it does not claim to capture every aspect of application behaviour. The displayed height also becomes a minimum height in the preview and generated styles, allowing content to occupy more space when needed.

Editing Data Without Executing Code

The Code view exposes editable React/JSX with JSON-style properties. Supported edits to labels, colours, dimensions, and radius update the other panels immediately. A restricted parser extracts component data without executing the code. Incomplete or unsupported input leaves the last valid model visible and shows an explanation.

An incomplete JSX draft stays separate from the current component. Edits elsewhere still update the model without overwriting that draft. Restore current model replaces the draft with the latest accepted data. Completing a valid draft replaces the model with its contents, so it should be checked against any changes made elsewhere in the meantime.

The parser supports the displayed component structures rather than arbitrary React applications, imports, or event handlers. It reads the type, variant, content, background and text colours, width, minimum height, and corner radius. Border and padding are generated values; editing them does not update the shared model. Style keys must remain quoted, as shown in the editor.

The JSX is illustrative output rather than a pixel-exact export. For example, Outline uses a transparent background in the preview while the generated JSX retains the model's background colour. The code can be copied as a starting point, but still needs integration, review, and testing in its destination application.

Making the Specification Part of the Workspace

The Specification view provides controls for type, variant, label, description, dimensions, and colours. A card's description also appears in its rendered content; other component types do not display every descriptive field.

The variant selector records Primary, Secondary, or Outline. Primary and Secondary currently use the same styling; Outline changes the preview's border and background. These options demonstrate shared state rather than a complete set of design-system variants.

Architecture shows the component beneath an application root, with its content and style properties. Its type, variant, and label controls edit the same model. The hierarchy and dimension summary respond to changes made in the other panels. This is a single-component relationship view, rather than a general-purpose diagram editor.

Try a Change Across the Views

The embed above is a disposable playground. A short walkthrough shows the main relationships:

1. Choose Card in Spec and change its background or corner radius in Design.
2. Rewrite the label and description in Spec.
3. Change the width in Code's JSX and watch the dimensions update immediately.
4. Inspect the generated React, then edit the label in Architecture and compare the other panels.
5. Use Undo and Redo to revisit model changes, or Reset demo to start again.

The four panels share a single horizontal row, with controls inside each panel. On narrow screens, horizontal scrolling preserves their layout. With focus inside the demo, Ctrl/Command plus 1–4 requests focus on the corresponding panel, where the browser allows that shortcut. The demo has no multi-user collaboration or remote cursors.

Scope and Implementation

This standalone snapshot contains its own HTML, CSS, JavaScript, and sample model. It requires no account, external libraries, network requests, or browser storage. Changes stay in memory and disappear when the page reloads. The technology labels describe this supplied demo, including its plain JavaScript implementation; React is generated as text.

Model changes use a bounded snapshot history for undo and redo. The preview is created with browser elements, and generated source is displayed as text. The portfolio embeds the supplied file in a sandboxed frame so its document and event handlers remain separate from the surrounding page.

Persistence, multi-component layouts, arbitrary source-code editing, and production application logic are outside this prototype. Its contribution is a concrete interaction to evaluate: whether sharing an explicit model makes it easier to keep design choices, descriptive intent, and implementation output consistent as a component changes.