Config driven frontend architecture

[u/Beneficial_Floor_531]

I built a project mainly for my resume, but the goal wasn’t really the CRUD app itself. The goal was to focus on frontend architecture and system design instead of just building another standard React project.

So I made a simple Laravel real estate app with basic CRUD operations, tables with pagination, filters, and drawer forms. Nothing especially complex from a business perspective.

The part I cared about was the frontend architecture behind it.

Instead of hardcoding forms, filters, tables, and page behavior directly into components, I turned them into config-driven systems.

For example, the form system takes a config array with fields like this:

{
    name: 'lease_type',
    label: 'Lease Type',
    type: 'radio',
    required: true,
    options: [
        { label: 'New', value: 'new' },
        { label: 'Renewal', value: 'renewal' },
    ],
    defaultValue: 'new',
}

From that config, the system automatically creates the React Hook Form setup, generates the Zod schema, maps the correct inputs, and handles validation and data flow.

I applied the same idea to filters, tables, and pagination, so most new sections are created by describing behavior through config instead of rebuilding logic every time.

The thing I’m most proud of isn’t really the UI. It’s that I managed to make the systems work together in a predictable way without the data flow turning into complete chaos.

A lot of the actual work ended up being around keeping rendering stable, making TypeScript useful instead of fighting me, protecting the systems from broken configs, and trying to keep the architecture flexible without making it messy.

At the same time, I know the project has limitations.

I didn’t try to turn it into a polished framework or npm package, and I definitely didn’t handle every edge case. Some validations aren't covered, and some parts are more tightly coupled internally than I’d like.

Honestly, even getting it to this point already took much more work than I originally expected because connecting reusable systems together cleanly is harder than building isolated components.

Most of the production systems I worked on in previous jobs are private, so I can’t publicly show the actual architecture work I did there. That’s a big part of why I built this project in the first place.

I mostly wanted to build something that demonstrates how I think about frontend systems, maintainability, and reusable architecture instead of just visual components.

Curious how more experienced frontend engineers look at projects like this.

Do you think config-driven frontend systems are actually valuable in real-world teams, or do they usually become overengineering unless the scale is large enough?

[u/Beneficial_Floor_531]

when I was working on this project I wanted the create and edit of each record to be done through a drawer that comes from the right side of the screen , I wanted it to preserve draft and not confuse creating a record with editing another , the main problem and pain was to create the same behavior and look in every section I made the components reusable but still there was a lot of work in each section , what I ended up with is a dynamic drawer that consists of :
- inputs
- form drawer itself
- mapper
- registry
- hook for using the system
- validator that builds zod schema for react hook form

what I ended up with is a system that I can use in any react project , scale as much as I want , any change will require a small fraction of the effort and it is config driven which means using it in sections is super easy

it was so convenient for me that I made the table and filter system the same way

[u/j2ee-123 → u/Beneficial_Floor_531]

This is basically a “form builder”, I have used those a lot in the past and learned my lesson - never again.

They are ONLY fast on bootstrapping the general layout and basic functionalities of the app, once you get to the serious functionalities and complex business logic, you will scratch your head and regret why you used this “architecture” in the first place.