Bleecker

01 / Context

The problem behind the project

A portfolio of applications needs a consistent visual language and interaction model without rebuilding the same controls in every repository.

A portfolio of operational products quickly becomes expensive to maintain if each application implements its own tables, dialogs, navigation, themes, and typography. I built Bleecker as the shared web foundation for those products, including this website, rather than treating visual consistency as an application-by-application exercise.

The design system also provides contracts that native libraries can implement. Sharing semantic names and tokens matters; forcing a native platform to import browser code does not.

02 / Implementation

Design and implementation

I design and build the shared web component system, its tokens, and the contracts consumed by the native implementations.

I designed the visual language and built the React components, layout primitives, theme system, bundled typography, Storybook fixtures, and platform-neutral token/contract exports. Canonical TypeScript token data generates the CSS layer and provides shared inputs to the sibling implementations.

The library includes operational layouts and continuously updated feed primitives, not just isolated buttons. Attention surfaces use a continuous intensity model, while applications own the domain meaning of that intensity. Form and overlay components own focus, label relationships, controlled state, and dismissal behavior.

I keep renderer-neutral exports dependency-light so native consumers can reuse vocabulary without loading the DOM, CSS, Radix, or chart implementation. Hand-authored components retain their platform behavior even when consuming generated conformance artifacts.

03 / Architecture

Architecture and workflow

1. 01

   Define a shared vocabulary

   Canonical tokens and component contracts define semantic roles, variants, and visual foundations.

2. 02

   Render for the web

   React components and layout patterns turn those contracts into accessible browser behavior.

3. 03

   Verify complete interactions

   Storybook compositions and interaction fixtures exercise state, focus, reset, nested overlays, themes, and responsive layouts.

4. 04

   Consume through public boundaries

   Applications use stable package entry points; native siblings reuse the neutral leaf exports rather than web renderers.

04 / Approach

Engineering decisions

05 / Evidence

Evidence and outcomes

The controlled Select reset work checks the parent value, placeholder, native form value, and actual submitted data together. The modal lifecycle work covers mounted focus, Tab containment, nested dismissal, and focus/scroll restoration.

The build checks generated tokens for drift. A separate conformance proof consumes a pinned neutral artifact without overwriting the existing components; unsupported behavior stays explicit rather than being counted as complete parity.

Source and technical notes