Symfony 4 Forms: Build, Render & Conquer!


Autocomplete Endpoint & Serialization Group

With a Subscription, click any sentence in the script to jump to that part of the video!

Login Subscribe

To get our autocomplete fully working, we need an API endpoint that returns a list of user information - specifically user email addresses. We can do that! Create a new controller for this: AdminUtilityController. Make that extend the normal AbstractController and add a public function getUsersApi(). To make this a real page, add @Route("/admin/utility/users"). And, just to be extra fancy, let's also add methods="GET".

... lines 1 - 10
class AdminUtilityController extends AbstractController
* @Route("/admin/utility/users", methods="GET")
public function getUsersApi(UserRepository $userRepository)
... lines 18 - 22

The job of this endpoint is pretty simple: return an array of User objects as JSON: I'm not even going to worry about filtering them by a search term yet.

Add the UserRepository $userRepository argument and fetch every user with $users = $userRepository->findAllEmailAlphabetical(). Finish this with return $this->json() and, it doesn't really matter, but let's set the user objects into a users key.

... lines 1 - 15
public function getUsersApi(UserRepository $userRepository)
$users = $userRepository->findAllEmailAlphabetical();
... lines 19 - 22

Cool! Copy that URL, open a new tab paste and.... boo! A circular reference has been detected. This is a common problem with the serializer and Doctrine objects. Check it out: open the User class. By default, the serializer will serialize every property... or more accurately, every property that has a getter method.

Serialization Groups to the Rescue

But that means that it's serializing the apiTokens property. And, well, when it tries to serialize that, it notices its user property and so, tries to serialize the User object. You can see the problem. Eventually, before our CPU causes our computer fan to quit & our motherboard to catch on fire, the serializer notices this loop and throws this exception.

What's the fix? Well, the thing is, we don't really want to serialize all of the fields anyway! We really only need the email, but we could also just serialize the same basic fields that we serialized earlier.

Remember: in AccountController, we created an API endpoint that returns one User object. When we did that, we told the serializer to only serialize the groups called main. Look back in the User class. Ah, yes: we used the @Groups() annotation to "categorize" the fields we wanted into a group called main.

In AdminUtilityController, we can serialize that same group. Pass 200 as the second argument - this is the status code - we don't need any custom headers, but we do want to pass a groups option set to main... I know a lot of square brackets to do this.

... lines 1 - 15
public function getUsersApi(UserRepository $userRepository)
... lines 18 - 19
return $this->json([
'users' => $users
], 200, [], ['groups' => ['main']]);

Now go back and refresh. Got it! We could add a new serialization group to return even less - like maybe just the email. It's up to you.

Adding Security

But no matter what we do, we probably need to make sure this endpoint is secure: we don't want anyone to be able to search our user database. But... hmm.. this is tricky. In ArticleAdminController, the new() endpoint requires ROLE_ADMIN_ARTICLE.

Copy that role, go back to AdminUtilityController and, above the method, add @IsGranted() and paste to use the same role.

... lines 1 - 12
... line 14
public function getUsersApi(UserRepository $userRepository)
... lines 18 - 25

This is a little weird because, in ArticleAdminController, the edit endpoint is protected by a custom voter that allows access if you have that same ROLE_ADMIN_ARTICLE role or if you are the author of this article. In other words, it's possible that an author could be editing their article, but the AJAX call to our new endpoint would fail because they don't have that role!

I wanted to point this out, but we won't need to fix it because, later, we're going to disable this field on the edit form anyways. In other words: we will eventually force the author to be set at the moment an article is created.

Next: let's finish this! Let's hook up our JavaScript to talk to the new API endpoint and then make it able to filter the user list based on the user's input.

Leave a comment!

  • 2019-01-10 weaverryan

    Hey cybernet2u!

    I absolutely can. This is actually a missing feature in Symfony's serializer (easily handling circular reference stuff) - hopefully we'll add it sometime soon. It's a 2 step process. If something doesn't work - let me know - I'm writing this directly into the comment - so it's not tested yet. Also, the way this is done changed in 4.2 slightly. Basically, suppose you're serializing in a controller:

    $response = $this->json(
    // the context
    'circular_reference_handler' => function ($object, string $format = null, array $context = array()) {
    return $object->getId();

    This is a bit naive, but basically, when you set this option, instead of an error, this callback is executed. Then, you just return whatever you want to display on that property (instead of it trying to serialize the object again, and getting into a loop). You can't (in Symfony 4.2) configure this option globally, but you can effectively do it by creating some new service that you call, and where *that* service executes the serializer for your and always passes this option. In ApiPlatform, they implement this automatically and they return the API URL to the given resource - e.g. /api/products/10.

    Let me know if it works - or doesn't! If you're on 4.1 or earlier, the solution is slightly different.


  • 2019-01-09 cybernet2u

    if possible, maybe you can provide a solution, when i really need to handle a circular reference, who knows what one might want to serialize with json

  • 2019-01-02 weaverryan

    Hey cybernet2u!

    Haha, sorry! Mostly the fix is to think about what is being serialized, and limit it to only the things you want via groups. Basically, find out *why* there is a circular reference, then avoid serializing the property that causes it.

    There is another solution - where you can "handle" the circular reference and take some action - let me know if you need info about that.


  • 2019-01-02 cybernet2u

    " A circular reference has been detected. This is a common problem with the serializer and Doctrine objects."

    Just when i thought that you are gonna show us a fix ... well ... i lost my hope.
    do you think you can provide a fix in the future ? because it's a common problem :)