Why You Might Need Your Own Page Creator
The idea of this article helped me a lot in a project that I started five years ago. The project is still ongoing, and the idea has been one of the best decisions we made
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 🙏