Every components starts simple enough, a few fields. Some basic state, clean, straightforward and manageable.But then reality hits.

More fields. More validation. More business logic. More state. Before you know it, you're staring at a 500-line component and it’s still growing. And this is just one component.

During my previous work at a major telecom company, I experienced what seemed like a revolutionary solution: metadata-driven component configuration.

This article is a journey through:

• Why traditional component development becomes unsustainable at scale
• The metadata solution that promised to save us (but didn't)
• How graph data structures might offer an unexpected way forward

Let me share what I learnt, and the interesting solution that emerged from an unlikely source.

A Classic Example: Building a component

Here’s how we used to build form at Unisala:

A normal approach to write this component i'd take:

1. Create form component:

import React, { useState } from "react";


const UniversityForm = () => {
  const [studyLevel, setStudyLevel] = useState("");
  const [major, setMajor] = useState("");
  const [gpa, setGpa] = useState("");
  const [testScoreType, setTestScoreType] = useState("");
  const [preferredLocation, setPreferredLocation] = useState("");
  const [additionalDescription, setAdditionalDescription] = useState("");

 validation  && conditional rendering code i.e 100+ lines

return (
 <form>
  <h2>Suggest me University 🎓</h2>

  {/* Level of Study */}
  <label>Level of Study</label>
  <select value={studyLevel} onChange={(e) =>     
    setStudyLevel(e.target.value)}>
    <option value="">Select level of study</option>
    <option value="Undergraduate">Undergraduate</option>
    <option value="Graduate">Graduate</option>
  </select>

  {/* GPA */}
  <label>GPA</label>
  <input
    type="text"
    placeholder="Enter your GPA"
    value={gpa}
    onChange={(e) => setGpa(e.target.value)}
  />

  {/* Additional Description */}
  <label>Additional Description</label>
  <textarea
    placeholder="Write more about your preferences..."
    value={additionalDescription}
    onChange={(e) => setAdditionalDescription(e.target.value)}
  />

  <button type="submit">Submit</button>

</form>
);
};

Sound familiar? This is how most of us code. But what’s wrong with this approach?

As the app starts to grow:

The Traditional Approach:

In modern app development, we’ve accepted certain patterns as normal:

• Copy-paste development: Duplicating code across components.
• Boilerplate UI patterns: Recreating the same <label> + <input> structures endlessly.

As your app scales, this pattern repeats across dozens or hundreds of components. What began as a simple solution becomes a maintenance nightmare.

The Core Problems:

1. Component Hell

• Problem: Components grow into massive, unwieldy blocks of code.
• Each field requires its own state, validation, and UI markup.
• The same patterns (e.g., <label> + <input>) are repeated endlessly.
• Components balloon to 500–1500 lines, becoming hard to read, maintain, and test.

A simple example of HTML Structure Repetition

<label>Level of Study</label>
<select>...</select>

<label>Major</label>
<select>...</select>

<label>GPA</label>
<input>...</input>

The same pattern is repeated over and over.

Each field requires multiple lines of JSX boilerplate.

2. Change Management Nightmare

Problem: Every new field introduces multiple layers of complexity:

• State Management: New state variables and setters.
• Validation: Custom validation logic for each field.
• UI Code: Additional JSX for rendering the field.
• Error Handling: New error states and messages.
• Submission Logic: Updates to form submission logic.

Impact:

• Linear Growth, Exponential Complexity: Adding a single field requires changes across multiple parts of the component.
• Maintenance Overhead: Developers must navigate and update interconnected code blocks.
• Copy-Paste Development: Developers duplicate code across forms, leading to inconsistencies and bugs.
• No Single Source of Truth: Changes must be manually replicated across multiple components.

So what's the solution?

The Twist: A Metadata-Driven Approach

While working at a major telecom company, I encountered a different approach: defining forms through metadata.

Big thanks to Basanth, my CTO for this one he introduced me to this whole metadata way of building components. It really opened my eyes to different ways of thinking about component architecture.

At first glance, the metadata-driven approach seemed like a game-changer. Instead of manually coding each component, forms were defined through configuration. The idea was to make components highly customisable and reduce the need for repetitive manual coding.

To address these issues, the metadata-driven approach was introduced.

For example, Instead of manually coding each component, components are defined through configuration (metadata):

[{
    type: 'select',
    name: 'studyLevel',
    label: 'Level of Study',
    options: [
     { value: 'Undergraduate', label: 'Undergraduate' },
     { value: 'Graduate', label: 'Graduate' }
    ],
    validation: { required: true }
   },
   {
    type: 'text',
    name: 'gpa',
    label: 'GPA',
    placeholder: 'Enter your GPA',
    validation: { 
     required: true,
     pattern: /^[0-4]\.?\d*$/,
     message: 'Please enter a valid GPA between 0-4'
    }
   },
   {
    type: 'textarea',
    name: 'additionalDescription',
    label: 'Additional Description',
    placeholder: 'Write more about your preferences...'
 }]

This approach promised to:

• Reduce Boilerplate: No more rewriting the same <label> + <input> patterns.
• Increase Customisability: Forms could be dynamically configured without touching the code.

By defining forms and components through configuration, developers could dynamically adjust behavior and appearance without touching the underlying code. This approach had significant upsides.

This alternative approach to traditional form architecture is brilliant.

Instead of writing components traditionally, we defined everything through metadata.

The promise? Less code, more flexibility, better maintainability.

Oh, how wrong we were.

What was pioneered as an elegant solution turned into configuration hell.

1. Metadata files grew to thousands of lines.
2. Simple changes required duplicating entire configuration blocks.
3. Understanding how different pieces connected became a nightmare.

But as we scaled the application, the cracks began to show.

If we want a simple changes in the input, we need to replicated the whole metaData for that input:

    type: 'text',
    name: 'gpa',
    label: 'updated GPA',
    placeholder: 'Enter your updated GPA',
    validation: { 
     required: true,
     pattern: /^[0-4]\.?\d*$/,
     message: 'Please enter a updated GPA between 0-4'
    }
   },

Now, instead of copying components, which are straightforward and easily understood by developers, we end up playing a copy-paste game with metadata configurations.

Without a clear understanding of how these configurations link up or function, the result is a tangled, complex mess of code.

Due to complexities that arose: One thing that dawn on me quickly was, this metaData was more painful than the manual approach of UI development.

1. How are things connected (config with components),
2. Which configs are linked to what?
3. The complexity of different attributes in metadata and channeling it into the component.

This approach became a major issue. Frustration grew quickly as it was difficult to comprehend . This make me reflect on how this architecture is not scalable. Metadata grew so absurd in some files, it grew more than tens of thousands of lines.

An analogy would be metadata is like energy/soul and component is just like a body

Those metadata are consumed in React component like:

// metadata are passed in this form 
const generateHTML = (item) => {
 switch (item?.type) {
  case "input":
      return InputComponent({ item, postData, setPostData });
  
  case "checkbox":
     return CheckboxComponent({ item, postData, setPostData });
  
  case "select":
        return item?.rating
          ? GenerateRatingComponent({ item, setPostData })
          : generateSelectTag(item);
  case "textarea":
        return Textarea({ item, postData, setPostData });
  
  case "date":
        return DateComponent(item, postData, setPostData);
  
  default:
        return null;
    }
  };

export default SmartForm;

// example of how form can be generated using Metadata
 return (
  <div className="px-2">
     {metaData?.edges?.map((item, index: number) => {
      <div className="mt-4">
        {item && generateHTML(item)}
       </div>
        })}
    </div>
  );

As every solution give birth to new problem.

While this approach seemed promising, it introduced its own challenges:

The New Problems: 2.0

• Complex configurations that were hard to track
• Difficulty understanding relationships between configs
• Massive metadata files
• Meta data redundancy

Conclusion: A Need for a Better Way

The metadata-driven approach was a bold attempt to solve the problems of traditional form development. While it introduced new challenges, it also highlighted the importance of:

The root problem isn’t just about forms or components—it’s about how we structure our UI architecture. We need a fundamentally different approach that:

• Promotes reusability and abstraction.
• Separates business logic, validation, and UI rendering.
• Scales gracefully as the application grows.

This realisation suggests that the solution lies not in choosing between code and configuration, but in finding a scalable, maintainable architecture that addresses complexity at its core.

React Components as Graph Nodes: A New Model for Frontend Development

In the next thread, we’ll explore how graph data structures can address these challenges by modeling the relationships between components and their configurations in a more intuitive and scalable way.

This approach aims to combine the benefits of abstraction and reusability while avoiding the pitfalls of metadata-driven development.

#softwareDevelopment #GraphDataStructure #ComponentsAsNode #frontendDevelopment #newAlgorithmicParadigm #differentApproach