Why You Might Need Your Own Page Creator

Context

Let’s say you work in a big company building the main website. Such a site seems simple, but there are plenty of requirements.

For example, finance wants a page for shareholders with the annual reports, some products or services are vital in one country and might need a special page, marketing wants a blog to share content, HR wants a page on careers that updates when they add a new role in their system, etc.

Solutions

There are two main options when it comes to this kind of website:

• No-code: Use a page creator. For example, Wix or Webflow.
• Full-code: Hire an agency or team to develop the pages.

Spectrum

Both choices are at opposite ends of the no-code, full-code spectrum:

Building a custom page creator puts us in the middle of this spectrum. We develop a website from scratch but allow content managers to build new pages with no-code.

Why?

With such a solution, we embrace the best of both worlds.

• Full customization of a full-code solution, where the tool does not limit the project.
• The speed of a no-code solution to build new pages.

Simple Page Creator

The custom page creator must not be a full SaaS in terms of functionality. It only needs to give enough functionality to the editors to build pages without development.

This is the objective of this article:

Build a page creator where new pages can be built with no code.

It Comes With a Cost

• The website isn’t developed as fast as using Webflow.
• The initial design is custom, but new pages must stick to the design and are not fully customizable without some development.
• The company needs recurrent access to an engineering team to maintain such a website.

How Do We Build a Simple Page Creator

We need a headless CMS (Contentful, Strapi,...) and a component-based frontend library such as React, Vue, or Svelte.

The main idea is to couple each type of content of the CMS to a UI component built with the library.

Static Pages

For example, let’s say we have the following mockup:

We split up the mock-up into three components:

• Page Title
• Content
• Carousel

We develop each component, and the page looks like the following:

<PageTitle />
<Content />
<Carousel />

In the CMS, we also have the same structure for a Page:

• Page
  • Page Title
    • Title
    • Subtitle
  • Content
    • Text
    • Image
  • Carousel
    • List of images

Now, we can easily create a new page with the same mockup by building a new entry of the type Page in the CMS.

What if a department comes and asks for a new page with a different structure:

Dynamic Pages

The structure of this page is as follows:

<PageTitle />
<Carousel />
<Content />
<Content />

Our Page in the CMS has the same structure.

• Page2
  • PageTitle
  • Carousel
  • Content
  • Content

Do we create a Page2 component? No.

We generalize the concept of a page:

• Page
• List of [PageTitle | Content | Carousel ]

Then, in our code, we map through all the entries of the list and render the appropriate one:

{
  entries.map((entry) => {
    // Check the type of entry, for example, with a switch
    switch (entry.type) {
      case “PageTitle”:
        return <PageTitle />;
      case “Content”:
        return <Content />;
      //…
    }
  })
}

The editors can easily create any page they want as long as it uses the components available.

Custom Page Creator

This idea of having a list of types of content and then mapping them to UI components is enough to have a custom page creator. It’s a page creator that doesn’t take long to develop and allows editors to create new pages without development.

A page is a list of building blocks instead of a fixed set.

We stay in the middle of the no-code, full-code spectrum and get the best of both worlds.

If you like this post, consider sharing it with your friends on twitter or forwarding this email to them 🙈

Don't hesitate to reach out to me if you have any questions or see an error. I highly appreciate it.

And thanks to JC, Miquel, Michal and Sebastià for reviewing this article 🙏