Will this be compatible with Symfony Live Components?

[bastien70]

Hey! Great job, well done! I was wondering, will we be able to use this directly with LiveComponents? Perhaps this would require adding a custom trait as well as a stimulus controller?

[Kreyu]

Hey, thank you for kind words :) Currently, I'm focusing only on the bugfixes and adding tests for everything already present in the bundle, to make it more stable to begin with. After that, I can look into some sort of integration. However, can you describe in more details what's needed, or what is not possible with the bundle when using it with live components?

[bastien70]

Creating the trait should allow us to simply add the essential elements to our component.

For example, look at how the ComponentWithFormTrait works which allows you to manage forms :

#[AsLiveComponent(name: 'create_meeting', template: 'app/components/meeting/create_meeting.html.twig')]
final class CreateMeetingComponent extends AbstractController
{
    use ComponentToolsTrait;
    use ComponentWithFormTrait;
    use DefaultActionTrait;

    #[LiveProp(fieldName: 'meeting_field')]
    public ?Meeting $meeting = null;

    protected function instantiateForm(): FormInterface
    {
        return $this->createForm(CreateMeetingType::class, $this->meeting);
    }
}

Using this trait, we must implement a form via the instantiateForm method.

A "DataTableTrait" trait could force us to also implement your datatable form

Then, the trait would contain all the necessary methods and actions, which would be called automatically by the template or the stimulus controller.

I know that saying it like that, it's difficult to explain my thoughts! I will probably make some example files, but in itself, the use of a trait in our component should simply be used to define the global parameters of the datatable (form, options, max results, events, queryBuilder...), and everything else allowing you to retrieve the results, change pages, etc., must be generic and part of the trait.
On the front-end side, we could simply render the datatable the same way:

{# templates/components/product/index.html.twig #}
<div class="card">
    {{ data_table(products, { title: 'Products', live: true }) }}
</div>

The generated pagination will have items that will refer to a LiveAction called from the line, allowing you to dynamically change pages.

Same for search fields, filters, each button, input, will be processed using LiveAction, rather than going through Turbo

[Kreyu]

Thanks for the explanation! I will look into it, unfortunately not soon, but definitely as soon as possible :) Maybe moving into live components will help a bit with the theming (which I'm not satisfied with the current implementation) - but these are just my guesses

[bastien70]

The problem with the current implementation is that (tell me if I'm wrong), on the back side, we still have a lot of things to do to reload the results to the right page, apply filters, etc..

It's true that if we just had to create our DataTableType, and implement a trait and then everything worked like magic, that would be great!

I'll try to give you a little help on this part, even if I'm still far from being an expert :)

[Kreyu]

Hmm, looking on the ComponentWithFormTrait, the form gets submitted using the submit() method (instead of the handleRequest()). For the data tables, the handleRequest() can be replaced with:

• paginate()
• sort()
• filter()
• personalize()
• export()

These are the methods the HttpFoundationRequestHandler class is calling when using the $dataTable->handleRequest($request);.

Maybe thats the hint, although I do not (yet) understand the lifecycle of the live component, and how it gets data from request.

[bastien70]

indeed, your file can be very useful!

I will try to create a draft of this feature in the near future, hoping that this will give us some visibility on how we will go about completing it.

Maybe we can ask for help from Ryan Weaver, he will certainly know what is the most optimal way to do it