A screen should be able to ask for a familiar control without owning its implementation. Wildo’s component system separates that request from the registered component that renders it.
That separation lets a product refine its interface in small, deliberate choices. Shared services keep participating components connected to the same design, language and interaction rules.
Example: Refine one interaction across its callers
A product replaces an injectable date control while keeping the wrapper’s accepted values and callbacks. Screens using that registration receive the new implementation; their business actions do not need to be rewritten just to select a different control.
For engineers
The framework’s button wrapper illustrates the boundary. It accepts the public props, resolves the named preset, and forwards the result to the implementation. This excerpt is from button.tsx:
export const Button = forwardRef<HTMLButtonElement, ButtonWrapperProps>(
({ preset = CorePresetNames.DEFAULT, ...props }, ref) => {
const Component = createComponentResolver<ButtonProps>(FrontendComponentType.LOW_LEVEL_BUTTON, 'Button')(preset)
return <Component ref={ref} {...props} />
}
)
The wrapper does not decide what a primary button looks like. The registered preset consumes ButtonProps and retrieves its visual recipe through useUI. A replacement must preserve the element/ref expectations and interaction props, not only produce a similar-looking rectangle.
Keep customization at its semantic home
| Change | Keep stable | Update deliberately |
|---|---|---|
| Theme treatment | Component props and caller intent | Recipes, required tokens and visual verification |
| Component implementation | Wrapper contract and selected preset key | Registration and implementation behavior |
| Container behavior | Child contracts | The policy and its participating consumers |
| Wording | The action’s meaning | Its specification, generated language files and review |
The application’s startup loader establishes which implementations exist. Its design configuration establishes their common visual rules. Specifications explain how to use them; they do not substitute for runtime registration.
This separation is useful only while the joins remain accurate. Keep the caller, implementation, registration, specification and label ownership aligned when making a change, and test the composed screen rather than treating each file as an independent success.