ui_kit_component Free

Docs/Bricks/ui_kit_component

Tier

Freeversion 3.3.7

Command

archipelago generate ui_kit_component

Generates

one component with its enums, data classes, widget test and Widgetbook showcase, inside an existing UI kit

Tutorial

Step-by-step: add ui_kit_component to a project

Scaffolds a UI component with optional headless architecture, widget test, and widgetbook showcase.

What it is

Scaffolds a single new component (widget + variant/size/type enums + data classes + widget test + Widgetbook showcase) into an existing UI kit package, and wires its export into the kit's barrel file. Use it to add one more component to a UI kit that already exists (from flutter_ui_kit) without hand-writing the enum/data/widget boilerplate.

Replaces flutter_ui_component

This brick replaces the old flutter_ui_component brick. Set useHeadless: false for simple components or useHeadless: true for headless architecture with data classes and enums.

Variables

Variable	Type	Default	Description
appName	string	MyApp	Application name
prefix	string	— (required)	Unique prefix for component naming
componentName	string	— (required)	The name of the UI component (e.g., Button, Card, Dialog)
atomicType	enum (atoms, molecules, organisms, templates, pages)	atoms	The atomic design level
widgetType	enum (stateless, stateful)	stateless	The type of Flutter widget to generate
useHeadless	boolean	false	Generate a headless base class (behavior only) that the styled widget extends
hasVariants	boolean	true	Whether the component has style variants (primary, secondary, etc.)
hasSizes	boolean	true	Whether the component has size variants (sm, md, lg)
hasTypes	boolean	false	Whether the component has type variants (filled, outline, ghost)
isForMonorepo	boolean	true	Whether this is for a monorepo structure

hooks/pre_gen.dart applies the brick.yaml defaults to useHeadless/hasVariants/hasSizes/hasTypes when a --config omits them, and throws if componentName or prefix is empty — both are effectively required despite having no default: in brick.yaml.

Usage

Interactive

archipelago generate ui_kit_component

Non-interactive (CI)

archipelago generate ui_kit_component --config my_config.json

Generated Structure

Always generated, regardless of useHeadless. Matches flutter_ui_kit/template_base's own package layout (e.g. app_ui_kit/lib/src/components/molecules/otp/):

packages/{app_name}_ui_kit/
├── lib/src/components/{atomicType}/{component_name}/
│   ├── {component_name}.dart              # Barrel: exports data/, enums/, the widget (+ headless base if useHeadless)
│   ├── {prefix}_{component_name}.dart     # The styled widget class
│   ├── data/
│   │   ├── data.dart
│   │   ├── {component_name}_size_data.dart
│   │   ├── {component_name}_style_data.dart
│   │   └── {component_name}_variant_data.dart
│   └── enums/
│       ├── enums.dart
│       ├── {prefix}_{component_name}_variant.dart
│       ├── {prefix}_{component_name}_size.dart
│       └── {prefix}_{component_name}_type.dart
└── test/components/{atomicType}/{component_name}/
    └── {component_name}_test.dart

apps/{app_name}_widgetbook/
└── lib/showcase/{atomicType}/
    └── {component_name}_showcase.dart

When useHeadless: true, an additional file is generated in the same folder:

headless_{component_name}.dart   # Behavior-only base class

and the styled widget ({prefix}_{component_name}.dart) extends Headless{ComponentName} instead of StatelessWidget/StatefulWidget directly.

Public API (generated code)

/// {@template {prefix}_{component}}
/// A styled {component} widget for the {Prefix} design system.
/// {@endtemplate}
class {Prefix}{Component} extends StatelessWidget /* or Headless{Component} */ {
  const {Prefix}{Component}({
    this.variant = {Prefix}{Component}Variant.primary,   // if hasVariants
    this.size = {Prefix}{Component}Size.md,              // if hasSizes
    this.type = {Prefix}{Component}Type.filled,           // if hasTypes
    this.onPressed,   // stateful widgetType
    this.child,       // stateless widgetType
    super.key,
  });
}

DI and wiring

There is no dependency injection involved — this is a pure-widget scaffold. post_gen.dart runs BarrelUpdater.addExport(...) against the {atomicType}-level barrel (packages/{appName}_ui_kit/lib/src/components/{atomicType}/{atomicType}.dart, e.g. atoms.dart) to add export '{componentName}/{componentName}.dart'; — matching how real components (e.g. otp/otp.dart under molecules.dart) are wired, never the package's top-level barrel directly. If the {atomicType}-level barrel doesn't exist yet (e.g. a first pages-type component), it's created and wired into lib/src/components/components.dart first. Then dart format . runs over the whole output directory.

The Widgetbook showcase is registered automatically: post_gen.dart adds its import inside the archipelago:widgetbook_showcase_imports markers of apps/{appName}_widgetbook/lib/widgetbook_app.dart and its xxxShowcase() call inside the matching archipelago:widgetbook_{atomicType} markers (a category is created for pages). Re-running is idempotent. Projects generated with flutter_ui_kit older than 1.2.5 lack the markers; the hook warns and the showcase must be wired by hand.

A registered component shows up in the Widgetbook tree under its atomic layer, with its enum and flag parameters as knobs (the built-in text field is shown here):

Dependencies on other bricks

None declared in hooks — but it only makes sense to run against a UI kit package that already exists (normally created by flutter_ui_kit). Nothing in pre_gen.dart/post_gen.dart verifies the target package exists first.

Changelog

Run archipelago brick info ui_kit_component to see the latest published version. Enterprise customers can read the full CHANGELOG.md in the brick source repository.