Annotations to Attributes

I did not find any tutorial that is really clear about it, to use rector:
Install it using tutorial
Create a reactor.php file at the root of your project

<?php

declare(strict_types=1);

use Rector\Config\RectorConfig;
use Rector\Doctrine\Set\DoctrineSetList;
use Rector\Symfony\Set\SensiolabsSetList;
use Rector\Symfony\Set\SymfonySetList;

return function (RectorConfig $rectorConfig): void {
	$rectorConfig->paths([
		__DIR__ . '/src',
	]);
	$rectorConfig->sets([
		DoctrineSetList::ANNOTATIONS_TO_ATTRIBUTES,
		SymfonySetList::ANNOTATIONS_TO_ATTRIBUTES,
		SensiolabsSetList::FRAMEWORK_EXTRA_61
	]);
};

Then run vendor/bin/rector
Remove rector

Hey Loenix,

Do you mean the instructions in this video about how to use Rector are not clear for you? Because it's basically as you said, you need to install Rector in your system in your preferred way (or follow the way we use in this course), then create a configuration for it, and run the Rector to actually do the changes according to the configuration you created. Yeah, you can remove Rector and its config completely after it, or keep the config for the future when you will upgrade your Symfony version, PHPUnit version, or PHP version later - you would just need to tweak the config file... and probably upgrade Rector to the latest, it would be a good idea :)

Cheers!

Yes, It was I meant, I have read this tutorial and the doctrine documentation about it, there was some differences and I was unable to understand what the rector.php file is and where to put it. So I mixed your documentation and try something and it worked, so I though a comment was useful for futur readers.

Hey Loenix,

Thanks for sharing some tips with others. That rector.php file is a config file that will be read by Rector tool telling it what exactly it should do, i.e. it specifies some rules for Rector. And usually, you put such config files in the project root dir, like the PHPUnit config file, etc.

I hope that help!

Cheers!

A brief comment on why php introduced attributes (and where to find more info) would be useful or what could be done with them. Then the training would be a bit more holistic instead of just the mechanics of upgrading. It's mine and likely a few other people's first time seeing this php change and we don't understand it

Hey Cameron!

Very fair suggestion! It's sometimes hard to back up as an instructor and remember all the little details. I can at least give some explanation here. In short, annotations were created around 10 years ago by Doctrine, mostly so that we could add the @ORM\Column annotations inside entities. Other languages have similar syntaxes. Over the years, these got more and more popular, with things like @Route, assertions for validation constraints, etc.

But, annotations were still not part of PHP's language. They're just comments, and Doctrine maintained a library that could read and parse those comments. It worked great, but it's still a bit odd for us to "invent" this new way of adding configuration into the comments system and not have it be part of PHP. And so, someone finally proposed putting into PHP itself. It has a slightly different syntax by necessity: we needed to introduce some new syntax that nobody could possibly be using already in their app (so that the introduction of PHP attributes wouldn't suddenly start making your code do something). Of course, there was a lot of debate on the syntax, and this was finally chosen as a balance between attractive/logical/simple.

I hope that helps - thanks for commenting about this :).

Cheers!

Hey! Attributes are great! But I have a question. I heard that you can use functions inside attributes uses for repetitive things.

I am thinking of a specific use case on API Platform for example (but this applies almost everywhere in reality).

Imagine, a Post entity. We want to create a custom action with API Platform that targets "/api/posts/count" to return the number of posts.

Now imagine that we would like to write the OpenAPI documentation for this action from our Post entity.

It could look like this:

#[ApiResource(
    collectionOperations:
        'get',
        'post',
        'count' => [
            'method' => 'GET',
            'path' => '/posts/count',
            'controller' => PostCountController::class,
            'openapi_context' => [
                'summary' => 'Get posts count',
                'parameters' => [
                    [
                        'in' => 'query',
                        'name' => 'online',
                        'schema' => [
                            'type' => 'integer',
                            'maximum' => 1,
                            'minimum' => 0
                        ],
                        'description' => 'Filter posts by online'
                    ],
                ],
                'response' => [
                    '200' => [
                        'description' => 'OK',
                        'content' => [
                            'application/json' => [
                                'schema' => [
                                    'type' => 'integer',
                                    'example' => 3
                                ]
                            ]
                        ]
                    ]
                ]
            ]
        ]
)]

Which is huge (I voluntarily took this kind of case but you can imagine that it applies to other things).

Therefore, the API Platform configuration of the Post entity is less readable and it would be necessary to move for example the entire value of the "count" key somewhere, in a private function, or even in an "api_doc" class which would contain functions with the configuration of each of our custom actions, and thus be able to simply call them from the entity.

Let's say we create a function getCountActionConfig() which would return all the content currently present in the 'count' key, allowing us to do:

#[ApiResource(
    collectionOperations:
        'get',
        'post',
        'count' => $this->getCountActionConfig()
)]

Only, it doesn't seem possible, since the call to the method will be underlined in red by PhpStorm with the following error: Constant expression contains invalid operations.

Moving the contents of the function directly into a constant would work I guess, but the goal would still be to do it through a function. And we could even go further by having the possibility of automatically generating the configuration by passing the name of the method, the description...

But a priori it does not seem possible. Do you have a solution for this?

Hi,

Have you tried static function?

#[ApiResource(
    collectionOperations:
        'get',
        'post',
        'count' => YourClassName::getCountActionConfig()
)]

Cheers!

Hello, sorry for delay, yes I tried and no, same problem, I'll have the same error Constant expression contains invalid operations

woh yeah, looks like the only way is to define a constant with the configuration you need and then it will work

I hope so )

Cheers!

Yes, this is so bad. I have to create a separate file that will contain a multitude of constants representing the configurations of my API Platform custom actions. It works, but...

It would be interesting if in a future PHP update we could use functions.

Thanks for your answers anyway!

Agree that's not very useful now, maybe something will change in future, so lets wait =)

Cheers and happy coding!