Since the advent of technologies such as React and Angular, we have often come to relate the term 'component' in connection to UI elements that come in various shapes and sizes, like buttons, forms, navbars, and so on. While this is not incorrect, it doesn't tell the whole picture,

In reality, components are not just confined to UI. Nearly anything we build can be a component; it's only when we think this way that we can unlock the power of component-driven, composable software.

So besides UI components, we can also have serverless components, entity components, database components, hook components, all sorts. But here's one type that many people haven't considered: content components.

In a component-driven world, where any component can be used anywhere, creating content as a component provides a level of portability, flexibility, reusability, and customizability not seen before. While the steps to creating this are small, the benefits are huge.

Simply put, we can create Markdown components. Or better yet, we can upgrade our Markdown components by using MDX components instead, which provide content creators the ability to create enriched experiences, simply by being able to render React components directly inside content. And because content is a component, we can use it just like we would with any of the other components we've created. Content becomes a first class citizen in a component-driven world.

Josh Cormeau provides an excellent explanation on the power of creating component-driven content. He discusses trying to explain the tension of mass on objects in physics, and how we was able to render a demo component inside the content, where the level of tension of adjusted with props. In Cormeau's words, "this is so much more powerful than describing the physics in words, or showing the effects with a video. By giving the reader control, we flip from passive learning to active learning.” Static content is a thing of the past. Interactive experiences are the new standard. Your readers are now users.

Here's a small demonstration to get your imagination fired up. Try dragging the teambit.people/ui/user-info@0.0.6 and teambit.people/ui/social-links@0.0.6 components into the teambit.people/user-card@0.0.6 component.

Independent components being composed into components, inside of content. The possibilities for levels of content interaction are infinite.

Besides the ability for developers to embed components to enrich and furnish static content, marketing teams can also stand to benefit from component-driven content. components related to CTAs, newsletter signups, and so on, can now be embedded into content pieces in the exact moments where your users are most responsive. CTAs no longer need to be resigned to appearing at the bottom of the article (less than 20% of your readers will ever make it this far).

It is as simple as adding a component in the position you want it to be.

Below is a Newsletter Signup component.

Typically, we would be resigned to adding CTAs such as this before/after the content piece, rather than alongside it. Now we are free to place it wherever we want. And because it's a component (and not an embed), we are free to customize it as much as we want.

Now that content is a component, open to versioning, stakeholders can now import your component, suggest and make changes, add features and so on. Your content creators can focus on creating the best possible content, while adjacent teams such as Marketing, can focus on enriching content with relevant CTAs. The Engineering team can come in and enrich the content further with coding examples that take the content experience from passive to active.

Prior to working with component-driven content, I'd be at my own mercy to know whether a post had been updated, I'd have to keep timestamps to try and keep track, I'd add notes to say that “this post had been updated on...” and so on.

With component-driven content, each piece of post is independently versioned, and can be updated in isolation from the platform/s it is used on, and the components it is a dependency for.

If a piece of content needs to be updated, it can be done so, away from anything else. It can then be versioned, creating a rich history of every update made. The components that consume the content can receive the updates simply by updating the version it is using.

Imagine having 200 blog posts, and each post had a CTA, but now your company CTA has been updated. To ensure consistency, you would have to go and update every single blog post, every time your CTA was updated. With component-driven content, you can have your CTA as a component. Whenever the CTA is updated with a new version, you can import the new version into your content.

In a world where your blog is made up of blog posts as a graph of dependencies, running commands such as bit import and bit checkout -a latest will bring in the latest version for each.

I'm fascinated by A/B testing and love the idea of being able to serve different experiences to different users as a means of learning what works better. Working with components means that we can serve different components to different users. Now that content is a first-class component, that means we can serve different content to different users.

The space for next level customization is immense. Ideas that spring to mind include: serving different SEO tags, serving different images, serving content with different CTAs, etc.

The levels of customization for A/B testing are bounded to your own imagination, and facilitated with ease through the use of component-driven content.

Search engines are placing greater emphasis on web page retrieval speed, and a lot of this can be determined by whether a page is prerendered. Now that content is a component, you have greater flexibility over what you choose to do with it. You now have the ability to fine-tune each component, so if you have a page component that renders one of your content components, you can decide to set it up to prerender, so that your content can be served lightning-fast to your users.

Users no longer have to wait for content to be retrieved from a CMS at load time. Instead, content components can be prerendered at build time.

Component-driven content is a new concept that makes sense for the composable web. It is spearheaded by toolchains such as Bit, who are actively revolutionizing how content is created, consumed, and distributed.

Stakeholders across departments now have an autonomous way to collaborate on content, where friction and frustration dissipates.

Tasks that were once tedious, such as manually updating CTAs in hundreds of old content pieces, now become as simple as updating a CTA component and sitting back as the change propagates through your content ecosystem.

The new levels of engagement and room for creativity in how stories are told and concepts are explained are bounded only by your imagination. Your content can now be as feature rich as you want it to be.

Component-driven content is here. Early adopters stand the best chance to win by capturing users with the most engaging content. As the number component-driven content increases, so does the number of high-quality, interactive experiences.

From this, we all win.