What is the best approach for component development? Is it one complex component or many simple ones? Let’s consider it in this article.
One complex component
There is no doubt that there is a fairly common approach that is used all the time. You can see this approach in a lot of libraries.
<x.button type="primary">
This is button
</x.button>
<x.button type="secondary">
This is button
</x.button>This component is stored in one file button.blade.php. Here is an example of this file
@props(['type' => 'primary'])
@php
$classes = $type === 'primary'
? 'bg-blue-500 text-white px-4 py-2 rounded'
: 'bg-gray-500 text-white px-4 py-2 rounded';
@endphp
<button {{ $attributes->merge(['class' => $classes]) }}>
{{ $slot }}
</button>As you can see, here we have conditions inside the component. Imagine that you need to add several more types of buttons to the button, then you need to add an icon, and also animation. You need to understand how complex this component will be.
Also, the downside is that you have to be very careful with this component. If you add something, you need to be sure that you did not break other options. This requires some attention.
Let’s also think about working in a team. Your colleagues see a Pull Request with changes in the button.blade.php file. Everyone also needs to carefully check that other button options are not broken in this file.
Of course, the advantage is that there is less Copy/Paste and you can combine something common in the buttons. Speaking from my experience, some of these components turn into very complex components that are incredibly difficult to understand.
Lots of simple components
Now let’s make an example for creating 2 components in different files.
<x.button.primary>
This is button
</x.button>
<x.button.secondary>
This is button
</x.button>button/primary.blade.php
<button {{ $attributes->merge(['class' => 'bg-blue-500 text-white px-4 py-2 rounded']) }}>
{{ $slot }}
</button>button/secondary.blade.php
<button {{ $attributes->merge(['class' => 'bg-gray-500 text-white px-4 py-2 rounded']) }}>
{{ $slot }}
</button>There are no conditions inside the components. Everything is simple, just layout.
Of course, the advantage here is the simplicity of the component and that it is quite clear at first glance.
Also, if someone makes a Pull Request with a change to the primary button, you will only see the changes in the primary.blade.php file. You can accept such a PR quite easily, since you will be sure that the changes apply only to one version of the button and do not affect other options.
I would like to be more detailed here. In practice, I see that it is difficult for me personally when I see a lot of changes in different files in a Pull Request. It is difficult for me to be sure that everything is in order there. If we have simple components, then we can lower the importance of some Pull Requests. For example, we can devote more time to those Pull Requests that do something more complex. Simple Pull Requests can be accepted much faster and without much checking.
Of course, there are also disadvantages. The main one is that we do not reuse some code. You can notice that the buttons are quite similar and the code base will be larger. Imagine how many button options you can have. Incredible.
Summary:
These 2 approaches have a right to exist. You can choose any of these approaches, if used correctly, it works great.
If we talk about my opinion, then I like the approach of using simple components more. It looks more transparent and beneficial when working in a team.