Description
Summary
The minicart element can't be used twice in the same page due to harcoded bindings.
For example in Magento_Checkout::js/view/minicart.js you can see that it will hook into [data-block="minicart"] without any possibility to override this.
In some other cases when you have a header bar that's displayed on desktop and a different one tht's displayed on mobile you may still experience the issue.
Basically we're only left with trying to move around the minicart using jquery instead of being able to toggle it's visibility per case.
When using two of them, one of them won't be able to display it's dropdown.
Unless I'm missing in which case please correct me, this looks like something that wasn't intended.
Examples
Here's a sample layout that's not really possible without jQuery due to the limitation of the minicart
In this case randomly one of the two minicarts won't display it's dropdown.
Proposed solution
The binding element should be decided by the config of the ui component as in other components.
From minicart.phtml you see that the binding is on element [data-block='minicart']
<script type="text/x-magento-init">
{
"[data-block='minicart']": {
"Magento_Ui/js/core/app": <?= /* @noEscape */ $block->getJsLayout() ?>
},
"*": {
"Magento_Ui/js/block-loader": "<?= $block->escapeJs(
$block->escapeUrl($block->getViewFileUrl('images/loader-1.gif'))
) ?>"
}
}
</script>
In the config of the ui compoment the binding element selector should be possible to configure so that we can use unique identifiers.
An alternative solution would be when there are multiple elements with the same functionality
[data-block='minicart']
It should bind to both of them properly and make sure the dropdown works.
Release note
No response
Triage and priority
- Severity: S0 - Affects critical data or functionality and leaves users without workaround.
- Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
- Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
- Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
- Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.