Discussion: Best approach to structure the Builder system

[JMauclair]

Hey everyone 👋

I’m opening this thread to align on how we want to architect the visual builder for Klickbee CMS.

✅ What’s already in place in branch feature/builder

• A first version of global settings (typography, color, spacing)
• A smart autoclamp system for responsive units

---

💡 Initial idea

I'm currently leaning toward a config-driven approach for components:
Each component would come with its own config file defining its props, and each prop would use a typed fieldProp (like text, number, date, color, select, etc.).

The goal is: one component = one React UI + one config file
This keeps things modular, maintainable, and easy to extend.

---

❓ Open questions

1. Where should we store the component config files?

   • Co-located in the same folder as the component?
   • Registered globally via a loader?

2. How do we structure and validate the config?

   • JSON or TS object?
   • With Zod/Schema validation?

3. How do we render components dynamically in the builder?

   • Idea: use a render(config) function that maps a JSON tree to React output
   • But the rendering pipeline is still very fuzzy right now — suggestions welcome!

---

📦 Example structure (WIP)

/components
  /Hero
    index.tsx
    config.ts  ← defines props + types + default values

---

Looking forward to your thoughts!
Let’s make this builder clean, visual, and scalable 🚀

[jpouvrard]

My thoughs, I write down what's on my mind.

1. Where should we store the component config files?
   Co-located in the same folder as the component : I think it's more explicit and easier to understand and maintain. It's ok when create component from code (duplicate and create new one).

Can we create component from builder ? I think we should be able to. In that case, components can be created from code based (based components) components ?

2. How do we structure and validate the config?
   TS with Zod validation. A more modern approach ? For global/project consistency ? Easier to maintain.

[JMauclair]

Where should we store the component config files?
Co-located in the same folder as the component : I think it's more explicit and easier to understand and maintain. It's ok when create component from code (duplicate and create new one)."

I'm 100% okay with that. I think that the easiest way to maintain and add components.

Can we create component from builder ? I think we should be able to. In that case, components can be created from code based (based
components) components ?"

This feature is really interesting. We thought about this, but for this we need to manage a complete config file structure that will support large cases of use.

How do we structure and validate the config?
TS with Zod validation. A more modern approach ? For global/project consistency ? Easier to maintain."

I understand how Zod would be useful, but for what we would use TS in this case ? For types only ?

[jpouvrard]

I understand how Zod would be useful, but for what we would use TS in this case ? For types only ?

For DX and documentation.

[JMauclair]

I understand how Zod would be useful, but for what we would use TS in this case ? For types only ?

For DX and documentation.

My bad, what does DX stand for ?

[jpouvrard]

Oh sorry, developer experience.