Application development with 100% customization. Customization Driven Development (CDD)

In this article I want to share my experience in developing interfaces with a level of customization up to 100% (real 100%). At the same time, backward compatibility and the possibility of updates are preserved. Magic? - No, it's CDD.

It all started back in 2018 in a large international company. I was invited to the main office to explain to the top management how we were going to solve the problem of customizing our product, and specifically the UI part. Clients needed to slightly change it for themselves and add something. It was necessary to maintain backward compatibility so that customers could receive product updates. Then I knew only the possibility of adding "holes" in the code (slots), where you can add any functionality. Well, also I knew about the API for changing already developed functionality. It is clear that there was no talk of any possibility of customization at 100%, because then you need to change the source code, and this is a loss of backward compatibility by itself.

Of course, not everyone needs a CDD. This technique will be extremely useful when developing a product whose customers need a deep customization. I mean, not just change the logo and the name, but also change absolutely everything your heart desires. And at the same time not to lose the possibility of future updates of the product.

How to achieve almost 100% customization without losing backward compatibility?

CDD uses "declarative customization", i.e. the entire view with logic must be turned outside for full customization. If it is necessary to customize certain parts of a rather complex component, then we just render its simpler internal components. These components can be packaged in a so-called "black box" with a rich API and "holes" (slots), or they may be rendered with even simpler components.

And here you can object: “But how, if we change the internal content, then we lose the possibility of updates!”. No, that's not entirely true, and that's why:

1. A component of any complexity (except for a primitive one) is just a set of simpler components. This set is always freely available and we clearly see what and where has changed in this set (when it is updated) and can update it very simply and quickly manually (if it is necessary);
2. A complex component consists of simpler components. They can be rendered in their standard, packaged form (if we do not need deep customization) and then we will receive their updates automatically;

Well. But how can this be achieved? What are the steps?

First you need to develop the most primitive components. They can, and some of them even should, have 2 versions:

1. The standard component, the "black box" with a rich API and "holes" (slots). Easy to use, but has limited customization options;
2. The wrapper component, that extends the capabilities of the content that you place inside. Less convenient to use, but much more customizable, up to 100%. Required for standard HTML elements:

<button>, <a>, <form>, <input>, <textarea>, <select>, …

When developing more complex components, you need to use a set of simpler ones. Like primitive components, more complex components can have 2 versions. It’s not necessary to create a wrapper component: if you can wrap only a declarative template from simpler components into a standard component (without code to manage it). And then you can just use the inner content when customization is needed.

In theory, everything is fine. How are things in practice?

You can see this right now in the example of the localization widget. There are tabs, switching between you can see the difference. Sources: Github. Also, I am currently preparing a smaller project for publication and it is fully Open Source. There you can clearly see all the advantages of CDD. The project will be extremely useful for those who often work with complex and custom HTML forms with dynamic fields and validations. I would like to talk about it in more detail, but this is a topic for another article.

In conclusion, I would like to recall the project of customizable mobile phones Project Ara. Using this example, you can see that not everyone and not always needs customization. And few people want to overpay for the possibility of customization. But the few who really need customization are willing to experiment and try different approaches to get exactly the result that meets their expectations.

I will be glad to read your comments and opinions on this technique and feel free to write me a personal message. Thank you!