-
-
Notifications
You must be signed in to change notification settings - Fork 664
Description
Is your feature request related to a problem? Please describe.
I like to use components to display values in a table. This allows you to perform some operations, for example, dynamically changing the color/description/other depending on the state.
namespace App\View\Components;
use Illuminate\View\Component;
use App\Models\Order;
class OrderShortInformation extends Component
{
/**
* @var Order
*/
public $order;
/**
* Create the component instance.
*
* @param Order $order
* @return void
*/
public function __construct(Order $order)
{
$this->order = $order;
}
/**
* @return bool
*/
public function status()
{
$descriptions = [
1 => __('In the process'),
2 => __('Paid'),
3 => __('Cancellation'),
4 => __('Refund'),
];
if (array_key_exists($this->order->status, $descriptions)) {
return $descriptions[$this->order->status];
}
return 'Unknown';
}
/**
* Get the view / contents that represent the component.
*
* @return \Illuminate\View\View|\Closure|string
*/
public function render()
{
return view('components.order.short-information');
}
}
For example, there is an Order model, and depending on the status, we can show different descriptions in our components.
This is much nicer than specifying things directly in the view or creating special areas for such processing.
The problem is that Laravel does not provide by default the ability to render a component as a PHP class.
Describe the solution you'd like
I suggest adding straightforward processing to correctly handle (non-nested) components to display them in a table.
For example, recording via view:
// Before
TD::make('index')->render(function (Order $order) {
// Lots of abstract or explicit code ...
return view(...);
});
And now this some of the things into the component:
use App\View\CompochangingOrderShortInformation;
TD::make('index')->component(OrderShortInformation::class);
This will automatically substitute the value that is in the loop (row) into our component.
Describe alternatives you've considered
Using a class clearly might not be very good to use from packages. Since it is assumed that the component has a name by which it can be called, for example:
<x-order-short-information :order="$order"/>
It may be strange that the class name is used instead. This was chosen because of the IDE's and editors' auto-hints - convenience only.
In theory, we could do support for both formats.
Additional context
I also thought about passing additional arguments, but because the required data and DI are in the constructor, this is problematic to implement in the package.
For example, if we go to get something in the constructor, we get an error:
public function __construct(Application $application, Order $order)
{
$this->order = $order;
// ...
}
We can only fix this problem by passing the name of the expected argument:
use App\View\CompochangingOrderShortInformation;
TD::make('index')->component(OrderShortInformation::class, 'order');
But we may also need to pass additional things to the constructor:
public function __construct(Application $application, Order $order, int $limit = 300)
{
$this->order = $order;
// ...
}
As you can see, it requires more and more arguments each time:
TD::make('index')->component(OrderShortInformation::class, 'order', [
'limit' => 100
]);
I am not sure that it will do more good for everyone (not just me) than create confusion in DI and required arguments.
What do you think about that?