-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Twig component: Make navigation bar management independent #33702
Conversation
M0rgan01
commented
Aug 23, 2023
Questions | Answers |
---|---|
Branch? | develop |
Description? | Make navigation bar management independent |
Type? | improvement |
Category? | BO |
BC breaks? | no |
Deprecations? | no |
How to test? | CI 🟢 and auto tests 🟢 |
Fixed issue or discussion? | Fixes #33701 |
Related PRs | - |
Sponsor company | - |
f8e566d
to
fd922eb
Compare
fd922eb
to
b7baf33
Compare
b7baf33
to
9a1b256
Compare
9a1b256
to
bc4509c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @M0rgan01
Only a few suggestions, but nothing mandatory as we'll have to refacto some of the classes at some point anyway
public int $currentTabLevel; | ||
public array $tabs; | ||
public int $currentTabLevel = 0; | ||
public array $navigationTabs = []; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's ok for this one but I noticed you and maybe @boherm as well kept a lot of public fields in the component classes in previous PRs
We shouldn't have public properties on these components except for variables that we absolutely have to inject/override in the component So mostly only variables that will come from twig and that the controller injected I guess
All the other public properties should be transformed in getter functions, and ideally they should only be populated Just In Time in the getter itself Except for "advanced" variables that depend on each other in which case the mount approach may be more adapted
/** | ||
* @return array<int, MenuLink> | ||
*/ | ||
public function buildNavigationTabs(Tab $tab): array |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
public function buildNavigationTabs(Tab $tab): array | |
public function getNavigationTabs(Tab $tab): array |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Another suggestion/refacto we'll have to handle in this service I think We don't cache the result so we'll have to think about how we can optimize this service to avoid doing the same DB queries multiple times for multiple components (not in this PR 😉)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
BTW I love this idea of getting the siblings this way instead of the previous quadruple loop 😅 This is much smarter this way
/* @var $currentLevelTab Tab */ | ||
foreach ($currentLevelTabs as $currentLevelTab) { | ||
$tabLang = $currentLevelTab->getTabLangByLanguageId($this->getContextLanguageId()); | ||
$menuLink = new MenuLink( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This MenuLink
DTO was created as a very simple one, maybe we'll have to improve it (add fields that are used everywhere) Or create alternative ones like a dedicated TabLink
DTO or something similar (not in this PR as well)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, might as well create a new TabLink