Charaf Mrah About Component Driven Development

Hi everyone! Welcome to the first episode of our series that shares community insights on the topics we discuss. Today, I’m excited to introduce my dear online friend, Charaf Mrah, who will share his thoughts on component-driven development. If you haven't had a chance to read the original article yet, I highly recommend checking it out later 👇

Charaf's thoughts is in my opinion a must-have addition, as they provide much more useful knowledge and real world examples. Thank you, Charaf, for your time and valuable contribution! We all highly appreciate this 🙏

What's your role in the development process?

PH: Hi Charaf, Thank you for joining us today. Tell us a little about yourself. What are you doing on daily basis? What's your role in the development process?

I am Charaf, a developer on the Bricks team. My role involves developing and maintaining features for our WordPress visual site builder with an extraordinary team, improving capabilities to build performant and accessible websites whilst giving users full freedom to dive into code when necessary. I also interact with users, sometimes creating articles and videos. Some of my day-to-day tools include PHP, JS, and Vue.

How does the component-driven development help you?

PH: It sounds great! You have a great experience, so tell us what do you think about component-driven development? Does it help you in the projects you manage?

Imagine you're building a house. Instead of constructing it as one gigantic block, you install systems like plumbing and electrical wiring as separate components. If the plumbing in the bathroom needs fixing, you don't rip out the entire house's structure. You simply address the plumbing issue. That's component-driven development for you.

Our code becomes a series of systems, each designed to function independently but contributing to the overall structure. Of course, it's not always perfect. A plumbing issue might affect the wall where the wiring is, but it's usually easier to isolate and fix this.

In the world of WordPress, it's technically possible to write an entire plugin or theme in one huge file. But much like combining all your house's systems into one tangled mess, it's a recipe for disaster. When something breaks (and trust me, it will) you end up wading through a swamp of code, trying to pinpoint the problem. By breaking everything into components, we make debugging and maintenance much simpler.

A book I read and enjoyed, "Thinking in Systems", isn't directly about software engineering but offers valuable insights into how we can approach complex systems. Systems thinking teaches us to view the whole as a collection of interconnected parts. Each part (or component) plays a specific role, much like organs in a body. If your stomach has an issue, it doesn't mean your lungs stop working instantly.

PH: That's interesting. I like such analogy so can you elaborate more how to fit the ideology described in the book in the development process?

In a software context, we get even more benefits due to its abstract nature. Not only can we reuse components, but we can also pass properties to alter their behavior based on context or where they are used if needed. This makes our components versatile and adaptable to various situations:

• Modularity & Reusability: Each component is a self-contained module. It allows us to reuse components across different projects, saving time and reducing redundancy.
• Isolation & debugging: Problems in one component don't cascade through the entire system. For instance, if a particular function in a WordPress plugin fails, we can isolate and fix that function without disrupting the rest of the plugin. Of course, this is the ideal situation, but it's not always true. Once you start doing state management and need to share state, it gets a bit more tricky. But that's a topic for another day :)
• Scalability: Thinking in systems helps us build scalable solutions. Just as a city can expand by adding new neighborhoods without disrupting existing ones, our projects can grow by adding new components seamlessly (ideally). At different levels, these components can take various forms. In architectural design, we see components as modules in patterns like MVVM or MVC, which help separate concerns and improve system organization. In the frontend scope, components are reusable UI elements. In the backend systems, microservices can be thought of as components, each handling specific tasks. Docker containers represent components too at the deployment level, encapsulating applications and their dependencies.

While no single pattern is perfect for all scenarios, simply having a structured approach makes it easier to reason about the system & navigate it.

What's the well-designed component for you?

PH: I must admit that I didn't have a chance to read this book, but after your words, I'll definitely try it out! Having those concepts in mind, what's a well designed component for you? What are the core attributes?

A well-designed component, from a systems thinking perspective, is like the perfect piece of a puzzle. It fits seamlessly into the larger picture, serving its specific purpose without unnecessary complexity. Here are some key attributes for me:

• Reusable: It can be used in various contexts.
• Configurable: It should allow customization via props or parameters. For example, a chart UI component should let users customize aspects like colors, labels, and data points without altering the core component.
• Specialized: It performs a specific task efficiently, much like a subsystem designed for a singular purpose. However, the interpretation of "single purpose" can vary. Some developers might create highly granular components, while others might opt for more comprehensive ones. There isn't a definitive answer to how specialized a component should be, but a good rule is: if you find yourself needing to reuse parts of a component in another component, it might be time to break it down further.
• Replaceable: It can be swapped out without extensive changes to the rest of system.

When it's worth to use component-driven development?

PH: That's right! We all might have a differend definitions, but the tip you provided about breaking down components is something I believe too. So in your opinion, when its worth to use component-driven development?

Components are always there as an abstract concept, whether we use a component-driven approach or not. It’s up to the developer to think of their software as components as a mental model and thinking tool. This abstraction can manifest in various ways: separating them into different files, using separate functions, deploying different servers, or even logically separating them within the same file.

At the end of the day, HTML is simply text, not inherently a series of components, but thinking of it in terms of components makes it easier for us to manage and reason about. Similarly, an application is just moving electrons around to make things happen, but thinking of the system in terms of subsystems or components helps us understand and control it better. For instance, code running on the client versus the server represents two major components. Even within the server, whether using microservices or a monolithic architecture, separating it into sub-systems makes it easier to manage.

So, the short answer: It's always worth it to think in systems, identify different components, and separate them when appropriate :)

PH: Is there anything related to the topic that you wish to share with the readers?

Read "Thinking in Systems" ;)