A Misaki Studio Component is a reusable visual interface unit whose design, responsive structure, public inputs, behavior, animation, and generated React output live in the same project file. Components can be placed in Pages, other Components, and Documents.
File: Page · Best for: A routable application or website screen. · Runtime/export result: Default React Page export plus styles and Page-oriented metadata.
File: Component · Best for: Reusable visual UI with props, states, events, variants, slots, and timelines. · Runtime/export result: Named React Component API plus scoped styles.
File: Code Component · Best for: Handwritten implementation that participates in Misaki's component/data model. · Runtime/export result: Authored source plus a generated integration wrapper.
File: Mockup · Best for: Screenless freeform visual exploration or presentation. · Runtime/export result: No runtime preview and no React export.
Ordinary Components live below an atomic layer such as components/atoms, components/molecules, components/organisms, or components/templates. The labels are organizational rather than different runtime classes.
A Component combines several structures:
Component file
├── screens
│ └── Body and its element hierarchy
├── properties, states, events, and validators
├── variants and variant combinations
├── test cases
├── element logic and data/view mounts
├── timelines, segments, keyframes, and audio
└── local editor view state
Screens describe responsive structures. Elements form the rendered hierarchy within a screen. File-level data structures define what the Component accepts, remembers, emits, and validates. Element logic connects those structures to visible behavior. Timelines add time-based changes.
Selection, the active panel, zoom, and other local view details are not the public Component API.
The Elements panel and canvas edit the same hierarchy. A parent contains ordered children; that order affects both rendering and generated JSX.
Available node kinds include containers, text, links, inputs, iframes, SVGs and paths, images, mesh gradients, shaders, Component instances, Document instances, named child slots, and connections. Not every node can parent every other kind, and specialized nodes expose specialized Design/Logic controls.
Use intentional element names. Names make the hierarchy understandable to humans, improve MCP targeting, and help trace generated identifiers back to their source.
Properties are caller-provided values such as label, disabled, or avatarUrl. Their declared types and default values become part of the generated Props and DefaultProps contract.
Read Properties, states, and events for the complete public-input, runtime-state, event, validation, variant, and test-case model.
Variants select named design alternatives such as size: compact or appearance: outline. Generated code exposes variant keys and applies the associated style classes. Variant combinations can represent intentional multi-axis states.
A named child slot accepts React content supplied by the caller. Slots let a reusable Component own layout while the Page or parent Component supplies content such as an icon, action area, or list item.
Events are outputs the caller can react to. Element listeners and Component behavior can trigger them. Keep event names intentional and distinguish the event contract from internal state updates.
Validators describe supported validation rules for Component inputs and behavior. Their usefulness depends on how the generated or consuming application applies the resulting contract, so verify the exported code and runtime behavior for the specific validator.
States are values the Component owns while it runs. They can drive conditions, variants, text/value bindings, timeline commands, and other element behavior. A test case can provide property values, but state is not treated as a test-case input.
Conditional rendering can show or omit an element based on data. Repeat behavior can render a structure for values from a mounted view or other iterable source.
Bindings connect text, attributes, inputs, Component props, styles, or other supported fields to properties, states, events, mounted data, and logic expressions.
Elements can mount supported API, storage, Content, or database views. The generated Component then depends on the corresponding project modules and runtime endpoints. A visual binding is not proof that the external service exists or is authorized.
The Design surface applies layout and visual properties to the canvas or current selection. A Component can contain multiple screens for container-based responsive behavior. Screens are not separate Components: they describe how the same Component's structure and styles adapt at configured sizes.
The generated runtime can choose authored screen states from the Component's container width, and generated SCSS can include matching container-query rules. Always test the Component inside its real parent layout, not only in an isolated full-width preview.
A Component timeline contains layers, segments, keyframes, easing, and optional audio. Timelines can be driven by mounting, state changes, scroll/appearance behavior, or explicit commands from element logic.
Design state and timeline state are connected: the canvas identifies the element and property, the Animate inspector configures the selected timeline behavior, and the bottom timeline positions changes over time.
Adding a Component to another visual file creates an instance that references the source Component. The parent controls the instance's placement and supplies exposed properties, variants, events, and children. It does not copy the source element hierarchy into an independently editable duplicate.
Library Component instances reference a foreign/read-only source. Edit that Component in its owning project, then update the consumer through the library/sync workflow.
Open a Component file and switch the left sidebar to Elements.
Select the active screen's Body and build a small hierarchy.
Use Design for layout and visual properties.
Use Logic to declare the public inputs and internal state, then connect selected elements.
Add responsive screens or variants only when the base Component is clear.
Add animation in Animate and the bottom timeline.
Preview the Component and exercise its meaningful states.
Inspect generated code before exporting it into an application.
Coverage: UI + MCP for Component content; Partial MCP for visual/session navigation.
Select the Website project and inspect
<component path>without editing it. Report its screens, element hierarchy, properties, states, events, validators, variants, test cases, mounted data/views, and timelines. Then runexport-codeand explain the generated public API and imports. Finish with current diagnostics and do not change project content.
An agent can combine get-file-tree, get-data-structure, relevant style/logic/timeline reads, get-test-cases, export-code, and get-diagnostics. It should use returned file/node IDs and report unsupported or absent structures rather than inventing them.
After any UI or MCP mutation:
Read the affected hierarchy or data structure back.
Preview the intended variant, test case, and responsive size.
Inspect the generated TSX/SCSS when the public API or dependency graph changed.
Run Component diagnostics while remembering that an empty result is not a complete consuming-app build.
Confirm Undo reverses the intended file-content action without affecting unrelated edits.
Parent/child rules can reject an invalid hierarchy.
References to Components, Documents, tokens, APIs, storage, tables, Content, or Scripts must resolve to compatible current items.
Duplicate field or export names can produce diagnostics.
Mockups do not have a Component-level data structure or runtime export.
A generated Component still requires compatible React, styling, runtime, routing, and data dependencies in its destination.