My old way is the right way 

Many of us perceive websites as a set of pages. But websites are not books, not in 2021. We often see SPAs, PWAs, applications that bring instant reactions to user actions rather than lengthy page reloads. Often we want to display text in a page format, but that doesn’t mean that pages have to be the main building block of your model. I know content is usually viewed as the editor’s responsibility, but working together on modeling will make everyone happier. 

Having pages at the core of your content model usually means that pages contain content. The APIs will then pass this JSON structure, text embedded in the page’s layout, to the front end or business layer. You might be using Vue or React, which are heavily based on components. In the code, you need to identify which elements correspond to which components and extract the content accordingly. You need to remember how these elements are mapped to the front end. This setup works if nothing changes, but something always does. What if your marketers would like to switch sections on a page? You’d have to either adjust the content model in the CMS or change the front-end implementation. Both actions require your input.

The great thing is that with only a few simple content modeling principles you can transition to a component-friendly model that makes development, maintenance, and even framework-switching in a Jamstack project much easier. I’ll show you.

Component-friendly modeling

The component-friendly model starts with two terms: content chunks and components. So what are they?

Content chunks are the smallest reusable pieces of content—much like React components.

Components are independent and reusable bits of code. 

How awesome would it be if the whole content model were based on components? Even content authors, editors, or marketers prefer it this way as they can reuse these chunks (components) elsewhere: in newsletters, landing pages, or inside the call-to-action buttons. For developers, there are no drawbacks at all. “Build once, use everywhere” components simplify the long lists of templates usually required for any enterprise-sized project. You can still display these as pages—and even give control over the layout to editors.

You can create a wrapper content type allowing only components. The APIs will then serve ready-to-use JSON, already nicely pre-structured into predefined React components. No guessing which element corresponds to which component. You grab these in the code, use the corresponding component, and you are done. 

The component-friendly model can be expanded by adding switches (e.g., via taxonomy) to change which components should be used in the front end. 

You can even implement a custom element component selector that feeds the existing library of React or Vue components into the Kontent UI. Editors then pick which frontend component will be used to display the content item. 

And what if you decide to switch the framework? You already have nicely structured component-oriented content in JSON, so switching to another framework like Vue or Angular is more about syntax changes than functionality. 

A new model without pages

If you’d like to know more about this topic, take a look at what can go wrong or join our Discord and share your experience with us. The first step towards a truly future-proof content model and implementation is abandoning the page-centric mindset. 

Key Points

• Collaboration on model creation is key to get buy-in from every department.
• Using components (content chunks) in a component-friendly model simplifies development and reduces the number of necessary templates.
• Pages don’t translate well into a component-based framework, such as React or Vue.