New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Using Blade Components in a Table #1489
Labels
Docs
Must be added to documentation
Comments
Looks good to me! |
Why dont we use a interface for OrderShortInformation constructor, in wich we make he contract to use the params needed and pass an instantiated object of the contract to OrderShortInformation on component() TD method, that way it would be more elegant i don't know for sure if it work this is just illustrative:
|
tabuna
added a commit
that referenced
this issue
Jan 15, 2021
tabuna
added a commit
that referenced
this issue
Jan 15, 2021
* refs #1489 [TD] Added method for render component
This was referenced Nov 13, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
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:
And now this some of the things into the component:
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:
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:
We can only fix this problem by passing the name of the expected argument:
But we may also need to pass additional things to the constructor:
As you can see, it requires more and more arguments each time:
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?
The text was updated successfully, but these errors were encountered: