[Deprecation] Deprecate TemplateAnnotationToThisRenderRector as risky, annotation based and better tailored to the project - #989
Merged
Conversation
The rule guesses the template name from bundle and controller naming conventions, and has to classify every return as either template variables or an already built Response. Both depend on project-specific conventions, which makes the rewrite risky to run blindly. Remove the rule internals and the now unused helper classes it was the only consumer of.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
TemplateAnnotationToThisRenderRectorturns a@Template/#[Template]annotation into an explicit$this->render()call. To do that it has to answer two questions that only the project itself can answer.1) Where does the template live? The rule guesses the path from bundle and controller naming conventions:
final class SomeController { - /** - * @Template() - */ public function indexAction() { + return $this->render('index.html.twig'); } }The
'index.html.twig'is derived from the class name, namespace and an optional bundle lookup. Any project that does not follow the conventions the guesser assumes gets a path to a template that does not exist, and the breakage only shows up at runtime.2) Is this return template variables, or an already built Response? The rule inspects the return type of every return statement and rewrites only those it believes carry template variables:
public function detailAction() { if ($this->isGranted('ROLE_ADMIN')) { - return ['key' => 'value']; + return $this->render('detail.html.twig', ['key' => 'value']); } return new RedirectResponse('/'); }When the inferred type is a union,
mixed, or comes back from a method call the rule cannot resolve, the classification is a guess. Guessing wrong either drops the render call or wraps a Response in another Response.Both questions are answerable inside one codebase and not in general. A local custom rule can hardcode the template path convention and the return shapes that actually occur, which is both simpler and safe.
The rule is registered in no set, so it can only be reached by hand-registering it.
Changes
TemplateAnnotationToThisRenderRectorimplementsDeprecatedInterfaceand throws onrefactor(), matching the existing deprecation patternThisRenderFactory,TemplateGuesser,BundleClassResolver,ArrayUnionResponseTypeAnalyzer,ReturnTypeDeclarationUpdater,EmptyReturnNodeFinder,AnnotationAnalyzer,AnnotationOrAttributeValueResolver,ArrayFromCompactFactorySymfonyAnnotation::TEMPLATE, unused once the rule stops resolving the annotation