Configuration Driven Development in React

One year back we started transforming our project from not following any specific pattern to most talked about and sort after pattern configuration driven development aka CDD. I remember it being a huge transformation since we were trying to change previously written code to follow this new configuration style approach.

Shh........ if it works please don't become Daredavils

It actually is a lot of boilerplate work, you might be writing twice the amount of code you usually write for a normal react component but trust me it is all worth it. Now we come to the question.

🌳🌳🌳🌳🌳

What is configuration driven development ?

You will find a lot of very difficult to understand definition for CDD, but you can understand it as deep copy of the implementation.

wow !!..... as if i made it any easier

Just stay with me a little longer you will be able to understand exactly what I am talking in here. Consider the following form...... what do you think would be a deep copy or so to say Configuration for the html

{
  label: "Simple Form",
  description: "Probably way to basic...",
  components: [
    {
      id: "input_1",
      type: "input",
      label: "first Name",
      placeholder: "Code SandBox"
    },
    {
      id: "input_2",
      type: "input",
      label: "Email",
      placeholder: "Code SandBox"
    },
    {
      id: "text_4",
      type: "text",
      label:"About you",
      rows:2,
      cols:25,
      placeholder: "Code SandBox"
    },
    {
      id: "button_1",
      type: "button",
      buttonText: "submit"
    },
  ]
}

This object as you can very easily interpret is the configuration for the form above. we simply defined what components we wanted to have in our form. as you might have guessed it that this alone can not cause of the rendering of the form above (remember i said a lot of code). to have that problem solved you will build components such that it accepts the configuration for each component, for instance take the input configuration inside the components

 {
      id: "input_1",
      type: "input",
      label: "first Name",
      placeholder: "Code SandBox"
    }

This input box has few configuration where it takes placeholder , label associated. so we will build a small component which render out the above input box with label

const inputBox=(config)=>{
    return (
      <div key={config.id} className="inputContainer">
        <label htmlFor="">{config.label}</label>
        <input placeholder={config.placeholder} type="text" />
      </div>
    );
  }

All of this comes very handy once you have all the smaller component needed for the development. for instance you want a text box that accepts different maximum number of rows before scroll starts to appear. you would difine following object similar to the input box.

      id: "text_4",
      type: "text",
      label: "About you",
      rows: 2,
      cols: 25,
      placeholder: "Code SandBox"
    }

☘☘☘☘☘

Benefits of Configuration Driven Development

I bet! you must be having wild amount of ideas that you can implement with this approach and you are absolutely correct. As in the developer land we get a lot of CRs(change requirements) where we are asked to add couple of new input fields,textbox and buttons, guess what this turns a day of work into hours because you now don't have to worry about the html part. Let me show you how.......

{
  label: "Simple Form",
  description: "Probably way to basic...",
  components: [
    {
      id: "input_1",
      type: "input",
      label: "first Name",
      placeholder: "Code SandBox"
    },
    {
      id: "input_2",
      type: "input",
      label: "Email",
      placeholder: "Code SandBox"
    },
   {
    id:"new_input_1",
    type:"input",
    label:"new Input",
    placeholder:"New Added input"
   },
    {
      id: "text_4",
      type: "text",
      label:"About you",
      rows:2,
      cols:25,
      placeholder: "Code SandBox"
    },
   {
      id: "new_text_4",
       type: "text",
       label:"Added Text",
       rows:2,
       cols:25,
       placeholder: "Code SandBox"
    },
    {
      id: "button_1",
      type: "button",
      buttonText: "submit"
    },
  ]
}

and there you have it rendered right for you ......

Don't worry i'll leave codesandbox link for you to play around

🌴🌴🌴🌴🌴

Cons of using Configuration Driven development

Well in my opinion there aren't any, but some new developer might counter argue that this pattern is only useful for forms and require a lot of boilerplate. well not exactly in my opinion, you could utilize this approach for almost anything if you want really. take buttons for instance, you could design a component that renders different number of buttons each with different border configuration, animation, and what not. Only con that I see for real here is that you will have to break down your application into very small configurable fractions like buttons, checkboxes, dropdowns, breadcrumbs etc. but once you have done this part you cant imagine how easy of your development will become.

🎄🎄🎄🎄🎄

Conclusion

Atomic design system combined with Configuration driven development make your application easy to design, change and debug. well basically paradise for frontend developer.

I would be writing CDD Level 2 approach (if I get enough motivation, so please 👍 if you found it useful) and will link it down in this section.

CodeSandbox: