Creating a Visualforce Component is a four-step flow: design the component interface, implement the markup and controller, register it in the org, and consume it from pages or email templates. The walkthrough below builds a reusable styled-button component as a concrete example.
- Design the component interface
Decide what the component does and what attributes the consumer passes in. For a styled button component, the attributes might be label, action, style class, and disabled flag. Sketch the markup and consider where the body of the component will plug in (the click handler, the label text). Document the design in a short comment block at the top of the component file so future maintainers know the intent and constraints.
- Implement the component markup and controller
From Setup, open Visualforce Components and click New. Provide a name (StyledButton, no spaces), label (Styled Button), and the API version. In the markup, define <apex:component> with attribute tags for each parameter. Inside the component body, use <apex:commandButton> with attribute values bound to the component attributes. If the component needs server-side logic, create a separate Apex class as the controller and reference it on the <apex:component> tag. Save and check for syntax errors.
- Test the component in a Visualforce page
Create a test Visualforce page that consumes the component: <apex:page><c:StyledButton label=$t$Save$t$ action=$t${!save}$t$ /></apex:page>. Verify the component renders, the click handler fires, and the styling is correct. Test edge cases: missing required attributes (should error), styled-class overrides, and disabled state. Iterate the component until it handles every expected case. Add unit tests for the controller class if one exists, targeting at least 75% coverage as required by the platform for production deployment.
- Promote the component to production
Deploy the component (and any controller class) through the standard pipeline: Change Sets for legacy orgs, SFDX or DevOps Center for modern setups. After deployment, update any Visualforce pages or email templates that should consume the new component. Document the component in the org's component library or wiki so other developers know it exists. Future Visualforce work in the org should reuse the component rather than rebuilding the same styling and behavior inline.
The unique name of the component, used in the <c:ComponentName> tag when consumed.
The human-readable label that appears in the Setup list and the Visualforce editor.
The Visualforce content of the component, wrapped in <apex:component> tags.
Required to create and edit Visualforce Components in Setup.
Required only if the component has server-side logic. Otherwise the component is markup-only and renders faster.
- Component attributes are required by default unless required="false". Forgetting this on an optional attribute causes consumers to error on instantiation.
- Each component instance has its own controller instance. A page using the same component three times has three controller objects, which affects shared state and view-state size.
- Visualforce Components do not work inside Lightning Experience natively. They render only inside Visualforce pages, which can themselves be embedded in Lightning via iframe, but the component contract is Visualforce-bound.
- Disabling escape="false" on outputText opens an XSS vulnerability unless the source data is rigorously sanitized. Default escaping is on for a reason.
- Component view-state contributes to the page's total view-state size, which is capped at 170 KB. Heavy components used multiple times can hit the limit unexpectedly.