Description
Hello,
Part of the discussion about faceted search menu and results page combo (challenge point 1), I would like to report a behavior of LCs that disallow some cool tricks.
Currently, imagine you have an ArticleResults page, populated from your db with various filters, that user brings to you with url parameters. For now, you have your regular Symfony controller, that will process the parameters, send them as filters to your ORM, that will give you back a Pagination or an array of articles (called $articlesPage for example), that you will send to view.
Let's assume that you want to upgrade this with an ArticleResults LC, and for independency and simplicity purposes, you want not to pass the $articlesPage from your controler to the LC, but rather let the LC do its logic when rendering.
For some scenarii, doing an independant LC that will do logic at rendering is OK; but in our case, we currently can't, LC and subsequently Twig and SF will throw an error because $articlesPage doesn't exist yet.
My understanding of the current behavior is that when you reach mount() in LC to do logic and hydrate the public Pagination $articlesPage, your actual url-mapped-properties ($page, $name, $date, ...) aren't yet populated from the Request parameters.
Allowing to control the flow of this url params mapping should allow to do logic based on it during mounting, improving drastically simplicity of the system (no need to handle the filters twice, in controler and LC), and independency/reusability/shareability of a LOT of LCs based on logic at Request.