[LiveComponent] Add support for Doctrine ArrayCollections Hydration

[jpvdw86]

Q	A
Bug fix?	no
New feature?	yes
Issues	None
License	MIT

The existing DoctrineEntityHydration could not handle Doctrine ArrayCollections. When using the EntityType with the option 'multiple' => true, it returns an ArrayCollection, which result in an error. Additionally, setting useSerializerForHydration to true, in some cases, leads to a circular error.

This PR introduces an ArrayCollectionHydration class to enable support for ArrayCollections.

Example form:

public function buildForm(FormBuilderInterface $builder, array $options): void
{
        $builder->add('items', EntityType::class, [
            'class' => Item::class,
            'label' => 'Your items',
            'autocomplete' => true,
            'multiple' => true,
            'query_builder' => function (ItemRepository $itemRepository): QueryBuilder {
                return $itemRepository->createQueryBuilder('i'));
            },
        ]);
}

public function configureOptions(OptionsResolver $resolver): void
{
        $resolver->setDefaults([
            'data_class' => ItemsDTO::class,
          
        ]);
}

Example DTO:

class ItemsDTO
{
    private ArrayCollection $items;

    public function __construct()
    {
        $this->items = new ArrayCollection();
    }

    public function getItems(): ArrayCollection
    {
        return $this->items;
    }

    public function setItems(ArrayCollection $items): void
    {
        $this->items = $items;
    }
}

[smnandre]

Can you add tests ?

[jpvdw86]

Integration test is added.

[smnandre]

Thanks for all those changes :)

Now is time for the "core" questions:

• what are the security risks ? (cc https://symfony.com/bundles/ux-live-component/current/index.html#allowing-an-entity-to-be-changed-to-another )
• how does it work when combined with "writable: true" ?

[jpvdw86]

Thanks for all those changes :)

Now is time for the "core" questions:

• what are the security risks ? (cc https://symfony.com/bundles/ux-live-component/current/index.html#allowing-an-entity-to-be-changed-to-another )
• how does it work when combined with "writable: true" ?

The behavior of this functionality is the same as the existing Entity version. You can't edit the contents of the EntityObject in the ArrayCollection. Its only allowed to add or remove a EntityObject in the ArrayCollection by the className and identifierValue.

Also just added an test with ArrayCollection as Liveprop with writable: true

[jpvdw86]

@smnandre I've addressed the feedback. Is there anything else needed from my side, or any further questions? Looking forward to your update.

[weaverryan]

Thus far, we've avoided sending PHP class names to the frontend. For example, an array($product1, $product2) is already supported, as long as the LiveProp that this is attached to properly documents that this is @var Product[]. That logic, iirc, for hydration is this: https://github.com/symfony/ux/blob/2.x/src/LiveComponent/src/LiveComponentHydrator.php#L267-L272 - and here is the fixture class that we use in the tests - https://github.com/symfony/ux/blob/2.x/src/LiveComponent/tests/Integration/LiveComponentHydratorTest.php#L1643-L1648

Not exposing PHP class info to the frontend might be paranoid. But until we get a big need for it, I'd like to continue avoiding it.

But we should definitely support your situation. Does it already work if you add documentation above the property to say that this is a collection - e.g. something like:

class ItemsDTO
{
    /** @var Item[] */
    private ArrayCollection $items;
}

If this DOES already work, then what we need is a better error: if we detect that a property can't be hydrated, but it is some sort of iterable of objects, then we can tell them extra documentation is needed. If this does not currently work, then we should make it work - but the change might be inside LiveComponentHydrator.

[jpvdw86]

@weaverryan thanks for your reply

I just tested it and indeed with the annotation and this work like a charm

class ItemsDTO
{
    /** @var Item[] */
    private array $items;
}

The ArrayCollection version does not work.

class ItemsDTO
{
    /** @var Item[] */
    private ArrayCollection $items;
}

This generates the following error. "Error rendering "form_name" component: Can't get a way to read the property "elements" in class "Doctrine\Common\Collections\ArrayCollection"."

It would be nice to have a clearer error message in this situation.

This PR is not needed anymore :)

[weaverryan]

Yay!

It would be nice to have a clearer error message in this situation.

I agree! It feels like, a bit earlier, we should check to see if the property is an iterable. And, if so, throw a better exception. I'd love a PR if you can make one - you obviously understand the technical details quite well.