Better default support for Laravel Accessors and Mutators

[morpheus7CS]

Hi,

first of all, I would like to thank you all for the amazing job you're doing on Filament. ❤️

I just have one minor request and it has to do with using Laravel accessors and mutators, which I would love to see working in Filament v3.

I am aware that there are currently workarounds for simple string concatenation within a table column or the work can be pushed directly to the virtualAs function within a migration. However, accessors and mutators are still a core competency even among junior Laravel developers, and therefore much more accessible to them.

Where I see this used the most is not just in simple string concatenation operations, but also in e.g. the common work of trying to store monetary values as integers, where the transformation logic is commonly stored within an accessor & mutator pair on the model.

Didn't want to open this one as an issue, but would really love to hear the thoughts of the core team on this and how tricky it would be to implement in Filament.

Thanks again,
g

[danharrin]

I don't know anywhere that accessors and mutators don't work, except database-powered sorting and searching. If you can think of any other places please let me know.

For sorting and searching, you can pass in an array of underlying database columns to sortable([...]) or searchable([...]). We have no plans to allow non-database sorting and searching since this would destroy performance. But this is a good compromise as 99% of accessors are based on real database columns that can be sorted or searched.

[morpheus7CS]

Thanks for a quick reply. Will check again today, maybe I have been using it in a sortable scenario and that was the issue.

If not, I'll push the example to a repo and link it here.

Thanks again.

[morpheus7CS]

Hey,

unsurprisingly, I was wrong and you were right 🥶
Accessors and mutators work, as long as you don't mess with sortable and searchable.

However, while this may be off-topic to a degree, I still think that there is some consistency lost between Tables and Forms when it comes to money inputs.

Here's a concrete example:
I have a model that doesn't use any accessors and mutators. It has an attribute price, which stores the price in cents
(for this example, let's say the value in the DB is set to 1000).

return $table
            ->columns([
                Tables\Columns\TextColumn::make('price')->money('eur'),
            ])

This returns the value as €10,00. I then proceed to add the following code for the edit screen:

return $form
            ->schema([
                    Forms\Components\TextInput::make('price')
                    ->mask(
                            fn (Forms\Components\TextInput\Mask $mask) => $mask->money(
                                    prefix: '€',
                                    thousandsSeparator: ',',
                                    decimalPlaces: 2,
                                    isSigned: false
                            ))
                    ->numeric(),

On the editing screen of this same model, text input now shows the same value as €1000,00.

While technically, money and mask are fundamentally different functionalities, I would still appreciate your take on how to handle such cases consistently.

Thanks,
g

[danharrin]

I agree, it is inconsistent and this is something we will change in v3. Text columns wont /100 anymore by default.

For now, you can use money('eur', shouldConvert: true)

In my own projects I do store the value in the database in cents and not euros, and use a custom cast to handle this.

[adriaanzon]

For virtual columns, i.e. mutators for attributes that to not have a corresponding database column, I had to add the attribute name to the $appends property of the model, in order for it to work with my Filament form.