This is a guided walkthrough of the Windblocks workflow. Each area exists for a reason: project settings define reusable defaults, sections give pages clean structure, prepared or third-party UI can become reusable project components, component contracts prepare generated TSX, and instance fine-tuning remains available when a real exception is needed.
Prepare global settings, routes, sections, responsive areas and reusable components — including compatible third-party UI.
Set project component appearance, defaults and TSX actions before relying on instance overrides.
Generate a structured Next.js and TypeScript project and continue normal application development.
Project settings
Website settings define the global project context before you build individual pages. The walkthrough below follows the actual settings flow and explains what each group contributes to the final project.
General settings define the website identity, locale and shared layout values such as the project container. These become the baseline for every saved page instead of being configured again route by route.
Why it matters
A predictable global baseline means fewer overrides in the builder and fewer repeated values in the generated application.
Project design settings establish the default background and theme values used across the website. Page and component settings can still override them when a real exception is required.
Why it matters
Windblocks works best when common visual decisions live at the highest reusable level. That keeps both the builder project and exported source easier to maintain.
Set title rules, descriptions and other project-wide metadata that should apply by default. Individual pages resolve these values and can replace only the fields that need to differ.
Why it matters
SEO configuration becomes part of the project model rather than an afterthought added manually after export.
Open Graph and social sharing values can be prepared at project level so newly created pages start with sensible metadata instead of empty fields.
Why it matters
Shared defaults reduce repetitive configuration while still allowing page-specific social cards and descriptions.
Navigation is configured against saved routes rather than being copied as unrelated links into every page. This keeps site structure connected to the pages that actually exist in the project.
Why it matters
A single navigation model can be reused by the global header and exported consistently with the rest of the project.
Header and footer are website-level elements. Their layout, navigation and shared content are configured once and then applied across the public pages.
Why it matters
Global chrome should not become duplicated page content. Keeping it at project level produces a cleaner application structure.
Logos, favicons and other website-level assets are assigned centrally so the builder knows which files belong to the application shell and metadata.
Why it matters
Asset references can then be resolved consistently when the application is generated.
The metadata preview shows the result after project defaults and page-level values are combined. This is the useful final state, not just the individual settings that produced it.
Why it matters
You can catch missing or conflicting metadata while still inside the builder instead of discovering it after the source project is generated.
Sections & grid
Sections are not decorative wrappers. They are the main structural units of a page, own the responsive grid and provide useful context for the generated source.
Structure mode reveals section boundaries and named grid areas directly on the page. It is intentionally different from Content mode: the goal here is to understand layout ownership, not edit copy.
Why it matters
The exporter can produce cleaner source when the page has explicit structural boundaries instead of one undifferentiated canvas.
A page is composed from sections. Selecting a section opens the settings that belong to that boundary rather than to one of its child components.
Why it matters
Sections become meaningful source-code boundaries, so their responsibilities should stay clear.
Section settings include a human-readable name. Use names such as Hero, Features, Pricing or Contact instead of leaving every section anonymous.
Why it matters
Windblocks uses section context while generating source identifiers. Good names make the exported TSX easier for a developer to read and navigate.
If a section is not named, Windblocks may need to infer context from its contents. Explicit naming is therefore recommended.
The section owns its grid. Start from a prepared structure or create the arrangement required by the page, then place components into the resulting areas.
Why it matters
Grid decisions belong to the section layout, while components remain reusable content units inside that structure.
Additional grid controls let you adjust area names, column spans and row spans when a preset is not enough. These controls describe the responsive structure rather than visually dragging arbitrary pixels.
Why it matters
Named areas make complex layouts understandable both in the builder and later when the generated structure is inspected in source.
Components
Windblocks includes prepared Complex and Simple components, but the catalog is only a starting point. Project components can be created from supported HTML, saved into the library, given mapped props and reused alongside the built-in components.
The component sidebar separates building blocks by purpose so the page can be composed at the right level of granularity instead of treating every element as the same kind of block.
Why it matters
Choosing the right component type reduces unnecessary nesting and keeps the generated page structure clearer.
Complex components are prepared assemblies such as heroes or larger content blocks. They are intended to fill a larger section region without rebuilding the same composition from many small elements.
Why it matters
Prepared larger blocks accelerate visual work while still retaining a known source structure for export.
Components can expose variants for common arrangements. Select the closest structure before placing it instead of immediately creating a one-off modification.
Why it matters
Variants keep common differences reusable and are cleaner than repeating ad-hoc edits across many instances.
The component preview lets you inspect the chosen building block without committing it to the page first.
Why it matters
This keeps the page document cleaner while you evaluate variants and component fit.
Simple components are smaller building blocks designed to sit inside named grid areas: text, cards, buttons and similar local content units.
Why it matters
The distinction between Complex and Simple components encourages a page hierarchy that is predictable instead of deeply improvised.
Prepared components are not black boxes. You can inspect their editable structure and use the component tooling when you need a project-specific version.
Why it matters
Windblocks is intended to hand code back to developers, so component structure remains visible rather than being hidden behind a proprietary runtime.
Add HTML Container lets you paste or write supported HTML/Tailwind markup and turn it into a reusable project component instead of leaving it as anonymous page markup.
Why it matters
Promoting useful markup to a project component gives it a stable identity that can be reused, configured and exported consistently.
Windblocks detects editable values in the HTML and component tree. You choose which values should become public props and give them stable names such as title, description or buttonText.
Why it matters
Prop mapping is what turns pasted markup into an actual reusable component contract instead of a copied template with hidden values.
Once the reusable values are mapped, save the component so future page instances use the same project definition rather than creating another unrelated copy.
Why it matters
A shared project component is the foundation for consistent defaults, actions and generated source.
The library brings the built-in catalog and your saved project components into the same building workflow.
Why it matters
You can start from prepared blocks where they fit and introduce custom components only where the project actually needs them.
When a component has several intentional arrangements, variants give those differences a reusable home instead of forcing every page instance to carry its own styling changes.
Why it matters
Reusable differences belong in the component layer. One-off differences belong at the instance layer.
Third-party components
A third-party component does not have to remain a pasted black box. Start with an HTML container, apply compatible HTML and Tailwind markup, let Windblocks build the editable tree, detect reusable values, save the result into the project library and then configure it like any other project component.
01
Import
Bring compatible HTML/Tailwind markup from an external component source.
02
Normalize
Detect editable values and convert the imported markup into mapped props.
03
Reuse & export
Save it as a project component, then apply project-level appearance and actions.
The component sidebar includes an HTML container specifically for project-defined UI. It gives you a neutral starting point instead of forcing every reusable component to come from the Windblocks catalog.
Why it matters
The builder can therefore act as a component workbench, not only as a consumer of prepared Windblocks components.
Once the HTML container is placed, open it in the component editor. The editor exposes the component source, visual tree, element controls and responsive preview in the same workspace used for project components.
Why it matters
Third-party markup is useful only if it becomes understandable and editable inside the project rather than remaining an opaque pasted fragment.
Paste a compatible component or web snippet into the component source. Windblocks parses the supported HTML structure, applies the Tailwind classes and builds an editable element tree around the imported markup.
Why it matters
This lets you start from external component sources without giving up the visual editing and source-generation workflow that follows.
Import is based on supported HTML/Tailwind markup. Windblocks is not claiming that every arbitrary React package can be imported unchanged.
After the markup is applied, Windblocks can inspect editable text and supported values in the component tree. Review the detected values, keep static content static, and name the values that should become reusable component props.
Why it matters
Prop detection converts imported markup from a one-off snippet into a component contract that can be reused with different content across the project.
Once prop mapping is ready, give the component a name and slug and save it into the project library. From this point it is managed like the other reusable project components instead of being tied to the page where it was created.
Why it matters
Saving a shared definition is what makes later Appearance, Defaults and TSX action mapping useful across every instance.
The saved project component can be loaded back into the editor and previewed as a reusable unit. This is where you verify that the imported structure, mapped props and supported interactions still behave as expected.
Why it matters
The goal is not merely to paste third-party UI. The goal is to normalize it into a component Windblocks can reason about and export cleanly.
The converted component appears in the project library and can be inserted into other sections and areas. Each placement can use different mapped content while still sharing the same project-level component definition.
Why it matters
This closes the loop: external markup becomes a reusable project component, and the same project-level appearance and action settings can then guide the generated TSX.
Project component settings
Project Component Settings are intentionally separate from page-level editing. They let you define reusable Appearance, Actions and Defaults for the component before individual instances start accumulating exceptions.
Recommended order
Prepare reusable behaviour before page exceptions.
Map reusable props
Expose content and values that should remain editable across instances.
Set project appearance
Create the shared styling baseline for that component.
Map JSX / TSX actions
Attach explicit event attributes to the correct interaction targets.
Place and edit instances
Change content freely; use element-level appearance overrides only where necessary.
Generated-code effect
Windblocks can preserve the event attribute, expose the callback contract and create the required client boundary in the exported component.
It does not invent application business logic. That stays where it belongs: in the generated project you continue developing.
Project Component Settings are the most important fine-tuning layer for source generation. The configuration targets the component definition across the project. Appearance establishes the reusable style baseline, Defaults define shared values, and Actions let you write explicit React/TSX event attributes for the selected interaction target.
Why it matters
These settings survive the visual phase as source-generation information. When an event such as onClick={somethingToDo} is mapped to the correct element, the exporter can place that attribute in generated TSX, expose the callback input and create the smallest required client boundary.
Windblocks does not invent the application handler. It prepares the component contract and wiring; the generated application still owns the business logic.
Instance fine-tuning
Instance editing is intentionally powerful: content, element selection, visual controls, Tailwind values and raw classes are all available. The walkthrough explains how to use that power without turning the exported code into a collection of unrelated one-off overrides.
When a placed component is selected, Windblocks exposes instance editing while still giving you a path back to Project Component Settings. This decision is important: reusable behaviour should be fixed at project level first.
Why it matters
The cleaner the reusable definition is, the fewer special-case instructions the exporter has to preserve for individual page instances.
Instance editing is useful because you can see the component exactly where it lives in the section and judge whether this placement truly needs different content or appearance.
Why it matters
Contextual editing is valuable, but it should not replace reusable project settings for changes that belong everywhere.
Content editing works against the fields and props exposed by the component. This is the normal place to change the actual copy, labels, links or instance-level action values.
Why it matters
Content differences are expected between component instances and do not require duplicating the component definition.
Appearance editing exposes the component element tree so you can target a specific internal part instead of applying an opaque style to the whole component.
Why it matters
Element-level overrides remain explicit, which makes them possible to represent during export when a true exception is needed.
The Designer provides visual controls for spacing and related styling on the selected internal element. It is useful for a local exception that is easier to express visually than by typing classes.
Why it matters
This is deliberately an instance override. If the same adjustment is needed repeatedly, move it to Project Component Settings instead.
The Tailwind editor gives more explicit control over the selected element when the visual Designer is not precise enough.
Why it matters
The override can be exported, but repeated instance-level utility changes make the resulting source more specific and harder to read than a shared component baseline.
Direct classes are available when you know exactly what the one component instance needs. This keeps the builder flexible rather than preventing advanced changes.
Why it matters
Use this as an exception layer. Large amounts of ad-hoc classes can create noisy generated code, which is why reusable styles should be prepared at project component level first.
A dedicated component workspace gives more room for content and appearance work without losing the relationship to the selected page instance.
Why it matters
Complex editing remains possible without turning the main canvas into an overloaded development environment.
After editing, the component returns to the page with the instance-specific changes preserved. You can continue composing the rest of the page or preview the result responsively.
Why it matters
The builder keeps the exception attached to the exact placement that needs it rather than silently mutating every use of the component.
Forms
The form workflow covers layout, fields, behaviour, validation, appearance and export naming. It is not just a screenshot of a form — the configuration is intended to become a usable React Hook Form and Zod based implementation.
Forms are created through their own builder instead of being assembled from unrelated input elements on the page.
Why it matters
A form has behaviour, validation and export requirements that deserve a structured model of their own.
The form builder lets you arrange rows and fields, configure field types and prepare the responsive form structure without hand-writing the initial JSX.
Why it matters
The visual layout becomes a structured form definition rather than a static mockup.
Form settings define how the form behaves, how validation should work, what success and error states look like and how the generated form should be named in source.
Why it matters
These decisions are necessary for generating a developer-ready form rather than exporting only the visible inputs.
Appearance controls let the form use the same project-aware styling approach as the rest of the builder instead of becoming an isolated widget.
Why it matters
The generated form layer is designed around React Hook Form and Zod, so visual structure and validation configuration can continue as normal application code after export.
File manager
The File Manager keeps uploaded images reusable and exportable instead of treating them as temporary browser uploads.
The File Manager accepts JPG and PNG source images, organizes them for reuse and stores their references inside the builder project. Uploaded images are converted by the backend into optimized WebP assets.
Why it matters
The exporter can package known project assets with the generated application instead of leaving pages dependent on temporary local files.
Responsive preview
The editor canvas and the responsive preview solve different problems. Preview removes most builder constraints and gives the page an isolated viewport so responsive rules can evaluate against the selected display width.
390px
Mobile viewport
768px
Tablet viewport
1280px+
Desktop viewport
Content and Structure modes need room for builder controls, selected states and side panels. Preview renders the page in an isolated viewport at the selected width, so CSS and Tailwind breakpoints respond much closer to the final application.
Why it matters
Changing display size is most meaningful in Preview because the preview frame represents the actual responsive viewport rather than the available editor workspace.
Application export
The Code area generates the handoff to development. It combines project structure, components, mapped props, actions, styles, forms, assets and the chosen Next.js project profile into a downloadable application source project.
This is why Windblocks recommends reusable configuration first and ad-hoc overrides second. Both can be exported, but the former produces source that is easier to read, reuse and continue developing.
Explore exportExport starts by deciding how the application should be organized: project layout, source directory and how page sections should be represented in the generated codebase.
Why it matters
Export is not a generic HTML download. It creates a project intended to be opened and continued by a developer.
Optional frontend libraries can be selected as part of the export profile so the generated package configuration matches the project you are actually preparing.
Why it matters
The goal is a useful boilerplate, not a repository filled with unrelated dependencies.
Formatter and code-quality options can be included during generation so the downloaded project already follows the chosen development workflow.
Why it matters
The handoff starts closer to a real project baseline instead of requiring the same tooling setup after every export.
Generation combines pages, named sections, used components, mapped props, project-level appearance, TSX actions, forms, assets and export settings into the downloadable source project.
Why it matters
The quality of this step depends on the decisions made earlier. Clean reusable configuration produces a cleaner source handoff; heavy ad-hoc instance styling naturally produces more specific generated code.
Windblocks is not trying to hide source code forever. It removes repetitive setup while keeping the project structured enough to become a useful Next.js and TypeScript starting point. The better the reusable project configuration, the cleaner that handoff becomes.
Preferred order
Project defaults → routes → section structure → reusable component contract → page content → exceptional instance overrides → responsive preview → export.