Type-based definition, its developer experience and maintainability

[Kreyu]

Using the discussion to write down my thoughts about the type-based definition this bundle (and Symfony Form) relies on.

I've always seen Symfony Form as a incredibly flexible library that over the years allowed me to use regardless of complexity of the forms. I could throw anything at it, and it would handle it with great success.

That is what I wanted to achieve in this bundle. Therefore, after reading through the source code of Form component multiple times, I'd decided to go with type-based definition for data tables, columns, filters and all of that. Time passed and now I see multiple issues with that.

Issues (in my opinion)

First of - types are defined by an array of options. Without Symfony OptionsResolver component it would be unacceptable in my opinion. There's absolutely no autocompletion for that without using a Symfony plugin for PHPStorm, so other IDE's have it rough. Without plugins, I cannot provide a good DX for this bundle. Options can come from multiple places - from the type itself, from its parent or even from some extension, which directs us into second issue.

The type extensions - a very cool tech that allows to extend even the built-in or 3rd party type classes. It is possible to add new options to the type, modify its defaults, it can do a lot of stuff. This seems incredibly powerful, and it really is, but not without drawbacks. Those classes can be scattered all around the project, in any namespace, or even in 3rd party bundles - and developer can not see them all. Since extensions are tagged services, those can be defined with a priority to load them in a specific order.

Type extensions also require a different type inheritance - instead of relying on standard class inheritance, we have to use getParent(). I completely understand the reasoning which is provided in the Symfony Form documentation, but this adds another layer of complexity, which I'm getting more and more exhausted by.

Possible solutions?

Take EasyAdmin for an example. Each field is defined using a class with fluent methods, so everyone gets autocompletion regardless of IDE they use. Everything is type safe without a need of OptionsResolver, since it is just PHP typehints. Another example is Filament from Laravel ecosystem.

TextColumn::new('name')
    ->sortable()
    ->icon('heroicon-m-envelope')
    -> ...

What about extensions in this case? In this scenario, I think of completely ditching the idea of extensions. If you for example use a 3rd party column and need to add a new feature to it, e.g. a new method that enables or configures it, simply create a new class in your project and extend the 3rd party one. This way everything will be in one place, which is a huge benefit for the maintainability.

What about reusing a feature in multiple classes, e.g. columns? Well, let's not forget there's traits in PHP! 😄

This would require a lot of tinkering and multiple prototypes and would require a full rewrite of this bundle, so it's incredibly hard topic. On the other hand, because it works like Symfony Form, even with its issues and drawbacks, its easier to get in, which was always the main "feature" of this bundle.