Angular forms work beautifully with standard HTML. input, textarea, and select all slot into Reactive Forms without extra effort. The framework understands their events, their values, and their states.
But modern applications rarely get by on standard elements alone. You might need a star rating widget, a composite date selector, or a custom color picker. Drop one of these into a form group, and Angular treats it as dead HTML. patchValue does nothing. Validators ignore it. The form has no idea when a user interacts with the control, and form.disable() leaves the custom widget fully interactive.
This is the problem ControlValueAccessor exists to solve.
What ControlValueAccessor Actually Does
ControlValueAccessor is the contract that turns a custom component into a first-class form citizen. It acts as a translator between the Angular Forms API and your own UI. Once you implement it correctly, your component becomes indistinguishable from a native input from the form’s point of view. It can receive values, emit changes, report touches, and respect disabled states just like a built-in element.
The interface requires four specific methods. Each one handles a distinct direction of communication.
writeValue: Form to Component
writeValue(obj) is the inbound lane. Whenever the form model updates and needs to push a new value into your UI, Angular calls this method. If you invoke patchValue({ rating: 4 }) on a form group, that value of 4 arrives inside your component through writeValue. If you reset the form, writeValue receives the new initial value or null. Your job inside this method is to take that incoming data and map it onto your component’s internal state. If you are building a color picker, writeValue receives a hex string like #ff4400, and you must update your view to show that color as selected.
There is a practical wrinkle here. Angular can call writeValue before your view is fully initialized, especially inside dynamically rendered components, dialogs, or tabbed interfaces. If your component tries to touch the DOM or child components too early, you can hit runtime errors. A solid pattern is to store the value in a local property and apply it after the view initializes, or to guard against undefined child references. Never assume writeValue only fires when your template is stable.
registerOnChange: Component to Form
registerOnChange(fn) sets up the outbound lane. Angular hands you a callback function, and you must keep a reference to it. Every time the user changes the value inside your component, you call that function with the new value. In a star rating component, when the user clicks the third star, you invoke the stored callback with 3. That call flows back into the FormControl, updates the model, triggers any valueChanges subscriptions, and re-runs validators.
Skipping this step is the most common way to silently break a form. The widget might look alive. The user sees stars light up, colors shift, or dates populate. But the form model never updates. Validators continue to evaluate stale data. Submit handlers send old values. The component appears to work, yet the form is effectively blind. If your custom control accepts user input but the surrounding form never notices, this is almost always the culprit.
registerOnTouched: Reporting Interaction
Forms do not just track values. They track whether a user has interacted with a field. Angular uses the touched state to decide when it is appropriate to show validation errors. A required text input should not flash red the instant the page loads. It should wait until the user tabs away or clicks elsewhere.
Native inputs handle this automatically through blur events. Custom components do not. You must use registerOnTouched(fn) to report these interactions yourself. Angular gives you another callback; you call it when you decide the user has meaningfully engaged with the control.
The exact timing depends on your component. For a text-like custom input, you might call it on blur. For a star rating, the first click is probably the right moment. For a color picker that opens a popover, you might wait until the palette closes. The key is consistency. If you never call the touched callback, Angular keeps marking the control as pristine. Validation errors stay hidden even after the user has clearly finished editing. That leads to confusion and poor user experience.
setDisabledState: Respecting Form Commands
Dynamic forms constantly enable and disable fields based on business logic. When you call .disable() on a FormControl, Angular needs your custom component to respond. setDisabledState(isDisabled) receives a boolean. When it is true, you should lock down your UI.
This means more than just ignoring clicks. You should disable internal buttons, remove focusable states, and apply visual treatments like reduced opacity or pointer-events: none. If you ignore this method, your component stays fully interactive while the form model insists it is disabled. That creates hard-to-trace bugs. Users can modify values that the form supposedly rejects. Save buttons might enable based on invalid states. The form group and the UI drift apart.
A well-built custom control treats setDisabledState as a first-class requirement, not an afterthought.
Mistakes That Will Cost You Debugging Time
Several recurring mistakes trip up developers who are new to this interface.
Forgetting to call the change callback. Your component updates its internal state, but the form never hears about it. Validators stall, and parent forms submit stale data. Always fire that stored onChange function the moment the user commits a new value.
Skipping the touched callback. Without it, Angular never marks the control as touched. Error messages tied to touched or dirty states refuse to show. Users stare at a form that looks correct but will not submit, with no visible indication of what is wrong.
Neglecting the disabled state. A visually enabled control that the form thinks is disabled creates a broken trust boundary. The user can keep typing or clicking, but the model ignores them. Or worse, the model sporadically overwrites their input during sync cycles.
Omitting the NG_VALUE_ACCESSOR provider. This is the silent killer. If you implement the four methods but forget to add the NG_VALUE_ACCESSOR to your component’s providers array, Angular never registers your component as a value accessor. The code compiles. The view renders. Nothing binds. There is no error message, just a component that floats outside the form entirely. Always include it in the decorator metadata.
Signals, Validators, and Modern Angular
ControlValueAccessor is not legacy API surface. It fits cleanly into modern Angular development. Whether you manage internal state with Signals, plain properties, or RxJS subjects, the four methods remain your public contract with the forms module. You consume values in writeValue, mutate your Signals or state, and emit through the callbacks Angular provides.
Standard validators work without modification. Validators.required, Validators.min, Validators.pattern, and custom cross-field validators all evaluate your CVA-backed component exactly as they would a native input. The form control sees a value and a state. It does not care whether that value came from a text box or a hand-crafted month-picker.
That portability is why CVA matters for design systems and shared UI libraries. One team builds a robust phone-number input or a file upload widget. They implement the interface once. Every other team in the organization drops it into their Reactive Forms with zero additional wiring. The component behaves predictably, validates uniformly, and disables consistently across every feature module.
The Real Takeaway
ControlValueAccessor is not just another interface to memorize for interview questions. It is the bridge that lets your custom components participate in Angular’s form ecosystem as equals to native HTML elements. Mastering it means understanding the full conversation between your widget and the form: receiving values, reporting changes, announcing touches, and respecting disabled states. Get these four pieces right, and you can build complex, reusable form controls that feel invisible to the developers who use them. That is the mark of a professional Angular component.