Autocomplete Endpoint & Serialization Group

Keep on Learning!

If you liked what you've learned so far, dive in!
Subscribe to get access to this tutorial plus
video, code and script downloads.

Start your All-Access Pass
Buy just this tutorial for $12.00

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
* @IsGranted("ROLE_ADMIN_ARTICLE")
*/
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!

  • 2020-05-18 Vladimir Sadicov

    Hey mcc2

    Yes you can, you should just pass array of needed values and that's all. But you will need manually iterate your entities and create this array.

    Cheers!

  • 2020-05-16 mcc2

    Hi,

    Is it possible to serialize without using groups? Just to take several fields.

  • 2020-05-05 Diego Aguiar

    Hey Uriel

    Yeah, that part was made in another tutorial (but part of this track). Here you have the link to it: https://symfonycasts.com/sc...

    Cheers!

  • 2020-05-04 Uriel

    Hi! Can I have the link where this "groups" think was first made? I came here just to the forms tutorial and it seems is part of a tutorial that I haven't done yet.

  • 2019-07-25 weaverryan

    Hey Mike!

    I don't know if I totally understand the setup, but I two suggestion, hopefully one will work.

    1) Instead of a "placeholder" property, it's legal to have a getPlaceholder() method, which the serializer WILL use, as long as you put it in the right group:


    /**
    * @Groups("main")
    */
    public function getPlaceholder()
    {
    return '...'; // return the placeholder value based on the other properties
    }

    But this only works if you can calculate the "placeholder" value based on the other properties in your class. I have a feeling that you can't do that... because you probably need to know some outside information (like what's been typed in so far).

    2) So... if the above doesn't work, try this, which I actually think is cleaner. I would stop thinking about this API endpoint as returning "Users" and instead imagine that it returns an array of "UserSearchResult"s. Specifically, I would:

    A) Create a new model class called UserSearchResult - maybe in src/Model/UserSearchResult.php:


    class UserSearchResult
    {
    // using public properties to be lazy, but you could make these private and add getters/setters
    public $user;

    public $placeholder;
    }
    </code<>



    B) In your controller, create an array of *these* objects - something like this:


    $users = // some query for the User objects;
    $userSearchResults = [];
    foreach ($users as $user) {
    $result = new UserSearchResult();
    $result->user = $user;
    $result->placeholder = 'the placeholder'; // do whatever work you need to determine this value

    $userSearchResults[] = $users;
    }

    return $this->json($userSearchResults, ['groups' => ['main']])


    So, you are not returning a JSON representation of "UserSearchResult" which will contain the property you need + the normal data for a User.

    I hope this helps!

    Cheers!

  • 2019-07-21 Mike

    I have a textHighlight() function in a controller, to highlight the typed letters inside of the suggested username(s).

    But I have a problem:
    I can't simply pass the $highlightedUsername variable/property to algolia.
    If I simply "extend" every User Object inside a foreach() via $users[$key]->autocompleteDisplayName, $this->json(... Groups=>main) filters the newly created autocompleteDisplayName property out.

    Thats why I created a new "general placeholder" property inside the User Entity with Groups("main"):


    /**
    * Custom placeholder (Used for example by algolia autocomplete suggestions (otherwise $this->json(..., ['groups' => ['main']]) deletes/filters $suggestionName property of User objects)
    * @Groups("main")
    */
    private $placeholder;


    which is then set inside the foreach to store the "highlighted display name".
    This feels like a big "workaround".

    Is there any other method to add custom "temporary propertys" to objects, which aren't filtered out by $this->json(.. groups="main"), without adding "placeholder propertys" to the User entity itself?

  • 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(
    $someData,
    200,
    [],
    // 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.

    Cheers!

  • 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.

    Cheers!

  • 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 :)