-
Notifications
You must be signed in to change notification settings - Fork 9.3k
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
x-magento-init initialisation not bound to happen in the right order. #17125
Comments
Hi @kshaa. Thank you for your report.
Please make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, please, add a comment to the issue:
where @kshaa do you confirm that you was able to reproduce the issue on vanilla Magento instance following steps to reproduce?
|
Hey, @magento-engcom-team, ☑Yes, I successfully reproduced this issue also on a vanilla Magento 2.2.5. |
Hello @kshaa, thank you for your report. |
In the project where this issue appeared it seemed like it was caused because of such a flow:
I fixed it by implementing jQuery "promises" in the section-config and then using that promise in the customer-data invalidation functionality. vendor/magento/module-customer/view/frontend/web/js/section-config.js
To:
vendor/magento/module-customer/view/frontend/web/js/customer-data.js
To:
P.S. The promise implementation could be written in a shorter way - certainly. |
Looks like there is a big temporal coupling problem here. In However, the exported API is not actually in a usable state until the A similar bug with the same root cause was recently patched by @davidverholen in #23099. |
Hey @kshaa! |
Preconditions
Steps to reproduce
Example reproduction code
(Or just use this example module - https://github.com/kshaa/m2-section-config-oddity/)
vendor/magento/module-theme/view/base/templates/root.phtml
(Root.phtml is not the proper place for customization, this is just an example for the issue)
app/code/Vendor/Theme/view/frontend/web/js/test.js
Expected result
Actual result
Extra information
How I expect this internal section-config data load works usually
I think the data for section-config usually gets initiated in the following way:
vendor/magento/module-customer/view/frontend/templates/js/section-config.phtml template embeds the section-config with an x-magento-init script and also provides the required internal data
lib/web/mage/apply/scripts.js triggers early on page-load and transforms that x-magento-init into a virtual component (JS variable to-be-processed)
lib/web/mage/apply/main.js loads that section-config virtual component and binds the data from the template by passing it to a function that corresponds to the section-config returned object key "Magento_Customer/js/section-config".
Questions and concerns
Am I missing something critical here? Does the x-magento-init mechanism have drawbacks/limitations that I haven't seen in the documentations?
I just want to understand how this works, maybe this is actually easy and I didn't notice something.
P.S. I found this issue, because somewhere early in my page is a bare-bones JS using require that calls section-config within it's long dependency tree and fails in the aforementioned way and I can't easily fix it by replacing that initial script with x-magento-init or by moving it lower in the page, because I don't know what initial script triggers this faulty dependency tree.
P.P.S. This also seems like a race-condition which depends on the time it takes to load JS libraries over the network. Sometimes there is an error, sometimes not, but that shouldn't happen.
The text was updated successfully, but these errors were encountered: