← Back to Design Systems and Frontend Team

Skill · Version 1.0.0

Framework-native components

Keeps shared visual behavior consistent while implementing components in the conventions of the actual framework.

framework-specific-components

Team members using this skill

See how it helps

When is it useful?

Use when adapting a design system to React, Vue, Angular or native web components.

What does it help you do?

  • Separates common tokens and interaction rules from framework bindings.
  • Uses native state, event, form and lifecycle patterns.
  • Preserves attributes, references and accessibility contracts across wrappers.

Try asking this

Implement the same validated text field in our framework without copying another framework's lifecycle assumptions. Connect the field to the project's actual form mechanism. Verify value updates, touched state and announced errors without duplicating form ownership in the wrapper.

Detailed documentation

Read the skill’s original instructions, examples and checks in their authored language.

Details…Show less

Framework-Specific Component Implementation

While design tokens, visual scales, interaction state matrices and accessibility contracts can be shared across a product ecosystem, component implementations must follow the idiomatic reactivity, slot/projection, typing and lifecycle patterns of the project's actual frontend framework. Never force a React-style API onto Vue or Angular, or assume a component works across frameworks without verification.

1. Separate Shared Visual Foundations From Framework Bindings

  • Framework-agnostic layer: design tokens (CSS Custom Properties --*), typography/spacing scales, SVG icon assets, semantic CSS classes and state/accessibility specifications.
  • Framework-idiomatic layer: component state, event emission, content projection/slots, template refs, form-control integration and portal/teleport mounting.
  • Coordinate complex framework-specific patterns with the team's corresponding frontend framework specialist.

2. Idiomatic Patterns by Stack

React (React 18 / 19+)
  • Forward refs (ref prop in React 19 or forwardRef in React 18) and spread remaining native HTML props (...rest typed via ComponentPropsWithoutRef<'button'>) onto the underlying element.
  • Use useId() for deterministic SSR-safe ARIA/label IDs and createPortal for modals/popovers when needed.
  • Support both controlled (value + onChange) and uncontrolled (defaultValue) usage cleanly, and compose multi-part widgets with React Context (Dialog.Root, Dialog.Trigger, Dialog.Content).
Vue 3 (<script setup lang="ts">)
  • Use typed defineProps<...>(), defineEmits<...>() and defineModel<...>() (for v-model two-way binding) rather than React-style onChange props.
  • Use named <slot name="header" :open="isOpen"> and scoped slots (defineSlots<...>()), useId() (Vue 3.5+) for accessible IDs, provide/inject with InjectionKey<T> for compound components, and <Teleport to="body"> for overlays.
  • Understand inheritAttrs (defineOptions({ inheritAttrs: false }) + v-bind="$attrs" on the inner <input> or <button> when wrapping a field in a container <div>).
Angular (Standalone Components, Signals, Reactive Forms)
  • Build standalone components with ChangeDetectionStrategy.OnPush, typed inputs (input() / @Input()) and outputs (output() / @Output()).
  • Prefer attribute/component selectors (button[appButton]) on native <button> and <a> elements so consumers retain full access to native attributes (disabled, type, aria-*) without wrapper-div indirection!
  • Use <ng-content select="..."> or ng-template for slots, Angular CDK (@angular/cdk/a11y, Overlay, Portal) where present, and implement ControlValueAccessor (or Signal forms integration) for custom form controls.
Native Web / Vanilla TypeScript & Web Components
  • Build on semantic HTML (<dialog>, <details>, <button>, <form>), progressive enhancement, scoped data attributes (data-variant="primary", data-state="open"), and clean event listener teardown (AbortController signals).

Included files 1

  • SKILL.md