symfony-ux-live-component: hydrating via the NormalizerBridgePropertyHydrator

[johanv]

While trying out symfony-ux-live-component (which is awesome btw; thank you for creating this!), I stumbled upon an issue.
The project I am experimenting with, uses a lot of value objects, and I have a decent amount of normalizers in place to normalize these value objects. Since a class NormalizerBridgePropertyHydrator exists, I thought using my value objects with the live components might work.

When I tried that, I got these kinds of error messages:

An exception has been thrown during the rendering of a template ("Cannot dehydrate property "playerIdentifier" of "App\Components\PlayerSwitchComponent". The value "App\Domain\ValueObject\Player\PlayerIdentifier" does not have a dehydrator.").

With the help of XDebug, I noticed that the NormalizerBridgePropertyHydrator was trying to use Symfony's DateTimeNormalizer to normalize/denormalize my value objects, which obviously failed.

Now I have managed to fix this by adding these lines to the services.yml file of my project:

    Symfony\UX\LiveComponent\PropertyHydratorInterface:
        class: Symfony\UX\LiveComponent\Hydrator\NormalizerBridgePropertyHydrator
        arguments:
            - '@Symfony\Component\Serializer\Normalizer\NormalizerInterface'

I'm not completely sure this is how this hydrator is intended to be used. But it seems to work for me.

[benr77]

I think I'm having the same issue in #133

[benr77]

It seems that NormalizerBridgePropertyHydrator is injected with the DateTimeNormalizer.

Surely this should be renamed to be something like DateTimePropertyHydrator (to match the existing DoctrineEntityPropertyHydrator).

Or instead, inject the entire object normalizer so it can deal with any object and not just DateTime objects.

[kbond]

Hey @johanv & @benr77. NormalizerBridgePropertyHydrator exists so that any Symfony normalizer can be used with a property hydrator.

Or instead, inject the entire object normalizer so it can deal with any object and not just DateTime objects.

I believe this is the solution but can't quite remember why we only chose DateTime. @weaverryan, do you remember?

[benr77]

Yes, for the time being I have this in my service configuration to inject the object normalizer instead:

$services->set(NormalizerBridgePropertyHydrator::class)
        ->arg(
            '$normalizer',
            service('serializer')
        );

[kbond]

Ok, things are coming back to me now. I believe the reason we didn't include the entire full normalizer is DoctrineEntityPropertyHydrator. This one looks at objects and checks if they are managed by doctrine. There is a bit of a performance cost to this so we wanted it run last. If we added the "full" normalizer, this hydrator is never hit because by default, the full normalizer can normalize/denormalize objects.

[benr77]

Ok this is now sorted. The custom service configuration is no longer required. Cheers!

[johanv]

Thank you very much for fixing this!