amphibee/metaboxmaker

metaboxmaker's Issues

Extend addField handling in FieldTransformer to support non-field instances like Heading and Divider

In the src/Transformer/FieldTransformer.php file, the current implementation only checks for instances of Field to process through the addField method. This implementation is restrictive as there are other types of objects that need processing, such as Heading and Divider, which are not strictly fields but still require similar handling.

Issue

The code snippet:

if ($subField instanceof Field) {
    $this->addField($subField);
}

This condition only allows objects of type Field to be processed. However, instances of Heading or Divider are also valid inputs that need to be added but are currently being excluded.

Suggested Fix

We propose extending the condition to include Heading and Divider types. This can be implemented by modifying the existing conditional check to include these types, or by implementing a new interface that these classes can inherit, representing all types that are valid for addField.

A possible modification might look like this:

if ($subField instanceof Field || $subField instanceof Heading || $subField instanceof Divider) {
    $this->addField($subField);
}

Alternatively, defining a new interface like FieldCompatible could make the system more flexible and maintainable:

interface FieldCompatible {}

class Field implements FieldCompatible {}
class Heading implements FieldCompatible {}
class Divider implements FieldCompatible {}

if ($subField instanceof FieldCompatible) {
    $this->addField($subField);
}

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

This repository currently has no open or pending branches.

Detected dependencies

composer

composer.json

• php ^8.1.0
• laravel/pint ^1.13
• pestphp/pest ^2.19
• rector/rector ^1.0.0
• nunomaduro/phpinsights ^2.8

---

• Check this box to trigger a request for Renovate to run again on this repository

Refactor Field Type Declaration from Property to Constant in Field Classes

Currently, the type of input field in our Field class hierarchy is managed as a protected property, which allows for dynamic modification of the field type at runtime. This is observed in the Text class as follows:

class Text extends Field
{
    /**
     * The type of input field. Defaults to 'text'.
     */
    protected string $type = 'text';
}

Additionally, there's functionality to modify this type through a setter method:

public function type(string|InputTextType $type): static
{
    $this->type = OptionValidation::check($type, InputTextType::class);
    return $this;
}

This design, while flexible, does not enforce type immutability which might be desirable for certain field types like text, url, or email.

Proposed Change

To ensure type safety and immutability, it is proposed to define the type of each field class using constants rather than properties. This would also involve the use of an interface to enforce the declaration of this constant in all field subclasses.

Step 1: Define an Interface

interface FieldType
{
    public const TYPE = '';
}

Step 2: Modify Existing Classes

Each field class, such as Text, Email, and URL, would implement the FieldType interface and define their own TYPE constant:

class Text extends Field implements FieldType
{
    public const TYPE = 'text';
}

class Email extends Field implements FieldType
{
    public const TYPE = 'email';
}

class URL extends Field implements FieldType
{
    public const TYPE = 'url';
}

Step 3: Remove Setter Method

Since the field type will now be immutable and defined at compile-time, the setter method type() would be removed from these classes.

Impact

This change will:

• Enhance the type safety of the field classes.
• Ensure the immutability of field types, aligning with best practices for constant usage.
• Simplify the class design by removing unnecessary runtime type checks and modifications.

This approach does, however, reduce the flexibility of changing the field type dynamically but increases reliability and predictability of field behavior across our application.