This is similar to symbols or components in Figma, but here each component corresponds to an actual React component in the code. By creating reusable components, you ensure consistency and DRY (Don’t Repeat Yourself) principles in both design and code.

  • Creating a Component: To make a reusable component, select the UI elements (layers) you want to encapsulate – for example, a button design with its icon and label – then choose “Create Component” (look for a context menu option or a button in the UI toolbar that says Create Component). Give the component a name (e.g., Button or NavBar). Shaper will convert that selection into a component element. On the design canvas, it might move into a Components library panel, and any instances of it on your canvas become linked. Under the hood, Shaper generates a new file in the project (e.g., Button.tsx with the JSX for that component). This file is stored in the Git repo and can be edited by developers if needed.
  • Using Components: Once a component is created, you can reuse it anywhere in your designs. Drag it from the Components panel onto a page, or copy-paste an existing instance. Changes to the master component will update all instances. For example, if you adjust the padding or token usage in the NavBar component, every page using NavBar will reflect those changes (just like in design tools). This ensures global consistency.
  • Props and Variants: Advanced use – if a component needs variations (say a Button component with a “primary” and “secondary” style), Shaper might allow variants or properties for components. For instance, a toggle in the design panel to switch the Button’s style, which may correspond to a prop in code. In fact, Shaper includes support for shadcn/UI components which use variant props – Shaper provides a Variant Editor to adjust component variants by updating className or props. If you’re using such library components, you can create storybook-like “stories” in Shaper to preview different variants. Plan your component structure to accommodate states and variants where possible, instead of having separate components for each style.
  • Naming Conventions for Components: Use clear, PascalCase names for components (since they become React component names). For example: UserCard, PricingTable, MainFooter. Avoid spaces or special characters. A good name is descriptive of the component’s role. If a component is specific to a context, include that (e.g., DashboardSidebar vs. Sidebar if you will have multiple sidebars). Consistent naming makes it easier for developers to find the corresponding files in the repo. Also, maintain consistency between design and code naming – Shaper will usually keep the same name in the code export.
  • Organizing Components: If your project grows, you might have dozens of components. Shaper’s UI might allow grouping components (maybe via folders in the component panel). Reflect a logical structure – for example, group by feature or page (Auth components, Dashboard components, etc.). On the code side, components might reside in a directory structure (like components/auth/LoginForm.tsx). While Shaper likely handles file creation automatically, work with your devs if you need to reorganize component files – moving files in code could potentially break the link to the design, so follow Shaper’s recommended method for renaming or moving components (often renaming in the Shaper UI will also rename the file).
  • Design System Components: Some components are “building blocks” of your design system (e.g., Button, Input, Card). Define these early on and reuse them instead of duplicating styles. Not only does this speed up design, it ensures that if a fundamental component like a Button needs a change, you do it once in Shaper and it updates everywhere. Meanwhile, the code for that Button is shared, so developers also only maintain one place. This is the essence of a unified design-development system.

​
Example: Maintaining Consistency with Tokens & Components

To illustrate, imagine you have a Primary Button component that uses a Primary Color token for its background. Initially, the token is a blue. Your design system evolves and you want to adopt a new branding color (say a green). Instead of updating dozens of buttons manually, you simply change the Primary Color token in Shaper’s token editor. Instantly, every Button instance updates to the new green, and Shaper commits the token change to Git. Developers see a commit like “Update primary color token to green” and know the UI changed. The design remains consistent everywhere – including in code – and the change is traceable. This tight integration of tokens and components, all under version control, is what makes iterating in Shaper so powerful.

Tip: Use the Live Preview as you adjust tokens or components. Shaper’s real-time sync means you can have the app preview running (or open the published link) and see updates instantly as you tweak your design system values. This helps catch any contrast or spacing issues early.