Component
A component, in Jahia, is the association of a content item (based on a content type) and a view, which renders a piece of web page (an HTML fragment) for visitors. It is what contributors actually work with when they build a page: a news item, a banner, a callout, a list. They enter structured information, while the view takes care of presentation.
Definition and how it works
Separating substance from form allows one content item to have several views. A news item can appear as a card in a list, in full on its own page or as a simple headline in a feed. In Content Editor, the Layout section lets the contributor pick the view among those the developers have provided.
Technically, the content type defines the properties. The view is a piece of code that turns a content item stored in the Jahia repository into HTML. Developers write both and deliver them together in modules, packages of code deployed on the platform.
Academy documentation: rendering content
Related terms: View · Content item · Content Type · Content Editor
Resources that cover this term
- Ascensus
- DXP Deconstructed: what a Digital Experience Platform really includes
- Using Polymer elements as native Jahia components
- Headless CMS personalization: How to deliver truly adaptive experiences
- How Integrators Can Design the Ultimate Content Author Experience in a CMS? (Integrators Tips Pt.1)
- How to develop a DXP platform with the best UX for business users?
Component vs content type: the differences
A component does not exist on its own. It comes from combining a structure with a rendering. The three terms are often blurred in everyday project talk.
| Term | Relationship to the component |
|---|---|
| Content type | The content type defines the structure: which fields, of what kind. A component uses a content item of that type and adds a rendering. |
| Content item | The content item holds the entered values. It can exist without being displayed, for example in a folder read by an application through the API. |
| View | The view is the rendering code. The component is the visible result: this content item, rendered by this view, at this place on the page. |
Component in practice
A communications team publishes a news item once. On the home page, it appears as a card with an image and a summary. In a section’s sidebar, it shows only its title and date. On its own page, it is displayed in full. Three views, one content item to maintain.
When scoping a project, listing the expected renderings for each content type is useful, because it determines how many views need to be built.
Frequently asked questions
Where does the contributor choose a component’s rendering?
The contributor chooses the rendering in Content Editor, among the views the developers have provided for that content type. The content stays the same while its rendering changes. If the rendering you want does not exist, the answer is a view to have built, not content to duplicate.
Can a marketing team create a new component on its own?
The marketing team describes the component and developers build it. They declare the content type (its structure), write one or more views (its rendering) and deliver the whole in a module deployed on the platform. Contributors then use these components in pages. The marketing team comes in earlier, to describe the useful fields and the expected renderings.
Are components also used in a headless project?
The content is, the rendering not necessarily. In a headless setup, an application reads content through the GraphQL API, the recommended API for Jahia, then displays it with its own code. The rendering then belongs to the application, which reads the same content item. The same content item can still serve both a page rendered by Jahia and an application reading it through the API.