Magento 2: Синхронізація бекенда та стану фронтенів / кеш


14

Чи є у Magento 2 якісь системи чи абстракції для управління станом між резервним і місцевим сховищем на передньому краї?

Я працюю над перенесенням функції відновлення покинутого кошика користувача через URL-адресу переадресації. У спрощеній формі, як-от URL

http://magento.example.com/restore/the/cart?identifier=sdkfjh48v237g5

завантажить цитату в кошик поточного користувача на основі закодованого quo_id в ідентифікаторі.

У Magento 1 це було відносно просто - вам просто потрібно було оновити інформацію про сеанс користувача Checkout з правильним ідентифікатором котирування. Однак Magento 2 додає у складки місцевих сховищ .

Здається, що програма Magento 2 для фронтальних javascript JavaScript кешує інформацію в локальних базах даних пам’яті браузера. Сюди входить інформація про побудову міні-візка. Це означає, що навіть якщо кінцевому користувачеві-програмісту вдасться змінити ідентифікатор сеансу сеансу в заднім часі, міні-візок все одно відображатиме старі дані кошика.

Це лише один приклад проблеми, яка випливає з того, що не знаєте (або не маєте?) Єдиного API для керування станом програми через бекенд і інтерфейс. Для моєї конкретної проблеми у мене була кінцева точка рендеринга HTML-сторінки, яка включає деякий javascript, вручну очищає локальний сховище, а потім перенаправляє користувача на іншу сторінку - але це відчувається як грубий злом.

Чи існує API в Magento 2 для управління даними між інтерфейсом і бекендом?

Існує стандартний спосіб сигналізації всієї системи про те, що під час обробки бекенду ви зробили щось, що обумовило необхідність її визнання недійсним кеш локального сховища?

Чи існує техніка введення нового модуля RequireJS на сторінку, яка запускається автоматично і може маніпулювати локальним сховищем до того, як інші додатки javascript отримають доступ до нього?


Гей. Шановний магазин Алан, ти отримав відповідь?
Аміт Бера

@AmitBera Ще немає
Алан Шторм

Відповіді:


6

У мене була подібна проблема: я хотів, щоб компонент міні-кошика оновився після того, як я надіслав запит Ajax додати товар у кошик.

Насправді це працює дуже добре, якщо ви просто запам'ятаєте деякі моменти:

  • Заявіть, які розділи сторінок потрібно оновити після виклику Ajax у etc / frontend / section.xml вашого модуля.
  • Використовуйте jQuery.post (), щоб надіслати запит на Ajax. Це може бути POST або PUT-запит, тільки не GET.
  • І це повинно бути через jQuery, а не прототип або ванільну JS, оскільки істотну роль відіграє подія jQuery 'ajaxComplete'.
  • додайте URL-адресу Ajax з базовим URL-адресою (не починати лише з /)

Ось моя секція.xml (xyz - це ім'я нашого замовника):

<?xml version="1.0"?>
<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:noNamespaceSchemaLocation="urn:magento:module:Magento_Customer:etc/sections.xsd">
    <action name="xyz-ajax/cart/add">
        <section name="cart"/>
    </action>
</config>

Тут "xyz-ajax / cart / add" відповідає формату "[frontName] / [ActionPath] / [ActionName]". Xml повідомляє Magento оновити "кошик" після виклику ajax "xyz-ajax / cart / add" завершено.

Це мій шаблон шаблону (.phtml):

<script type="text/javascript">
    require(['jquery', 'BigBridge_XYZ/option_selector'], function($, optionSelect) {
        optionSelect.create(<?= json_encode($componentData) ?>, $);
    })
</script>

і це код JS, який надсилає запит Ajax:

Запит функціїЗаповнення (відповідьДані) {}

$.post(baseUrl + 'xyz-ajax/cart/add/cf/' + configurableProductId + '/simple/' + item.simpleProductId + '/amount/' + item.amount, requestComplete);

Що відбувається в процесі?

Кожен раз, коли ваш сценарій надсилає на сервер запит Ajax POST (або PUT) через jQuery, і він повертається, jQuery надсилає подію "ajaxComplete". Цю подію обробляє обробник у модулі-замовник / view / frontend / web / js / customer-data.js. Цей обробник перевіряє, які розділи сторінок залежать від виклику Ajax (від вашого section.xml), і визнає їх недійсними. Вони будуть оновлені.

Джерела:


14

Magento 2 використовує API клієнтських даних JS для представлення даних сеансу користувача у браузері. Передбачається, що всі віджети JS отримують дані клієнтів із API даних клієнта JS. Дані клієнта розділені на розділи (кошик, список побажань, ...). Кожен сегмент можна спостерігати, тому щоразу, коли він модифікований, віджет, який використовує його, повторно відображається для відображення змін.

Magento Framework відповідає за синхронізацію PHP-сеансу та локального зберігання даних клієнта JS.

Кожен раз, коли відвідувач із файлом cookie ID сесії та порожнім місцевим сховищем відвідує сторінку Magento, запит HTTP до сервера робиться для отримання даних клієнта (усі розділи).

Кожен раз, коли відвідувач робить якусь операцію з модифікації стану (додавання в кошик, додавання в список бажань), відповідний розділ даних клієнтів недійсний у локальній пам’яті та інший запит HTTP робиться для отримання оновлених розділів.

Ви можете використовувати 'section.xml', щоб пов’язати дії POST з локальними розділами зберігання, які будуть визнані недійсними щоразу, коли ці дії будуть викликані. Наприклад, див. Https://github.com/magento/magento2/blob/develop/app/code/Magento/Checkout/etc/frontend/sections.xml .


2

Спираючись на ці інші відповіді, якщо ви оновлюєте кошик через дзвінки API у звичайних require.jsфайлах Magento , але ви не можете покластися на ajaxCompleteметод jQuery для оновлення міні-картки (використовуючи іншу рамку запиту AJAX?), Ви можете вимагати Magento_Customer/js/customer-dataоб’єкт і запитати також оновити міні-карт:

<script>
    require([
        'Magento_Customer/js/customer-data'
    ], function (customerData) {
        var sections = ['cart'];
        customerData.invalidate(sections);
        customerData.reload(sections, true);
    });
</script>

Джерело: https://github.com/magento/magento2/isissue/5621

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.