Column from builder alias

[leesherwood]

Just now I needed to add a Column with a value taken from a subquery join & alias. Why doesn't matter but for some context it was to get the latest updated_at amongst a group of models and present this in a latest updated at column.

Pseudo-SQL-code:

SELECT foo,bar, latestPerGroup.latest_updated_at
FROM mytable
JOIN (
   SELECT MAX(updated_at) as latest_updated_at, root_id FROM mytable GROUP BY root_id
) as latestPerGroup ON mytable.root_id = latestPerGroup.root_id
WHERE
mytable.is_root = 1

The problem I hit was Column::make('Latest Updated At', 'latest_updated_at) would add a duplicate invalid select field mytable.latest_updated_at. And Column::make('...', 'latestPerGroup.latest_updated_at') would instead try to load a relationship.

Luckily Anonymous Columns to the rescue, BUT that requires me to do extra code like defining how sortable would work.

Column::make("Latest Updated at")
 ->label(fn($row) => $row->latest_updated_at)
 ->sortable(fn(Builder $query, string $direction) => $query->orderBy('latest_updated_at', $direction) ),

Which made me wonder if there was a potential DX improvement...

Could there be a way of saying to library: "trust me bro - this column value will exist, i'll handle it". I was thinking Column::make('...', DB::raw('latest_updated_at') or it could be a ->valueDeveloperHandled() method.

If the library just accepted that the field would be selected by the developer, and just added on the latest_updated_at ASC/DESC then it would work, without me needing to specify a custom sortable. Same thing could be said for searchable.

Admittedly, it's not a huge amount of time saved, and I haven't considered the side effects, maybe it's not worth it. But figured i'd share the thought.

[lrljoe]

It does make sense to standardise it, perhaps an AnonymousColumn or LabelColumn would be sensible to make life simpler for a very generic label style Column.

This would avoid any potential breaking changes as well.

If you want to do a PR for that, then I'd be happy to review it. The standard Column shouldn't be amended in this way at this point, due to how many sites use the package, and potential impacts.