Как стать автором
Обновить

Комментарии 13

У Joomla.request есть одно преимущество перед fetch: для POST-запросов автоматически добавляется CSRF-токен (если он, конечно, на странице задан вызовом HTMLHelper::_('form.csrf')).

Joomla 3 и Joomla 4 предоставляют небольшую обёртку для конструирования XMLHttpRequest

В чём смысл использовать XMLHttpRequest, когда более современный fetch не поддерживается только в IE?

Я про fetch не знал, хотя возможно, что он давно уже существует. В своей работе сталкиваюсь в основном с бэком. Насколько велика разница между XMLHttpRequest и fetch кроме синтаксиса?

Существует давно, года с 2015-го. Принципиальной разницы нет. Насколько я знаю, основная фишка fetch - он возвращает промисы, которые, соответственно, можно чейнить. За счёт этого определённые штуки получаются компактнее.

Фронтовые нюансы, в общем и целом) Это писалось больше для тех, кто подключает jquery, а порой и не один экземпляр ради того, что уже реализовано в ядре CMS.

Поддерживаются ли промисы? Например, тот же jQuery.ajax() умеет в промисы, достаточно добавить await, чтобы убедиться, а здесь с этим как?

Почитал про промисы - такого, чтоб цепочки делать нет. В тройке точно, в четвёрке надо посмотреть, но вроде тоже нет. Только описанные колбэки.

Промисы это не про цепочки, промисы это про удобство. Нет смысла использовать Joomla .request() когда из под корокби в Joomla 3 идет библиотка jQuery, при этом она уже подключена, делать ничего не надо. И самое главное ее достоинство, что с ней можно использовать await! Просто оцените насколько удобнее делать запросы:

response = await jQuery.ajax({
    url: '/',
    method: 'POST',
    headers: {
        'x-csrf-token': Joomla.getOptions('csrf.token')
    },
    data: {
        key1: 'value1',
        key2: 'value2'
    }
});

console.log("Ответ сервера:\n" + response);

Не нужно никаких колбеков для ожидания ответа, нет лишних вложенностей, можно просто дальше работать с ответом, словно пишешь синхронный код. Токен конечно сам не добавляется, но ни что не мешает указать его в заголовках самому.

В Joomla 4 добавили флаг promise, чтобы вызывать Promise:

Joomla.request = (options) => {
    // Prepare the options
    const newOptions = Joomla.extend({
      url: '',
      method: 'GET',
      data: null,
      perform: true,
      promise: false,
    }, options);

// Return a Promise
    if (newOptions.promise) {
      return new Promise((resolve, reject) => {
        newOptions.perform = true;
        createRequest(resolve, reject);
      });
    }

Ещё добавили очередь (FIFO queue of requests to execute serially) в виде Joomla.enqueueRequest.

Поизучать исходник можно https://github.com/joomla/joomla-cms/blob/4.2-dev/build/media_source/system/js/core.es6.js

Нативно — нет (скорее всего из-за обратной совместимости). Но если очень хочется, то никто не запрещает обернуть самостоятельно, скорее всего должно получиться как-то так:


const jRequest = url => new Promise((resolve, reject) => {
    Joomla.request({
        url: url,
        onSuccess: (_, response) => resolve(response),
        onError: reject,
    });
});

Это бессмысленный велосипед, так как Joomla поставляется с уже подключенными jQuery, выше я привел пример.

Я пытаюсь представить задачи, в рамках которых может потребоваться await на сайте. В joomla ajax-запросы делаются для получения данных из модуля, плагина или (реже) компонента на том же сайте. Физически запрос идёт на тот же сервер и если он отдал вёрстку, то и ответ на запрос вряд заставит себя долго ждать. В Joomla 4 есть rest API из коробки, но вряд ли фронт будут писать на joomla.request. Запросы к удалённому серверу, от ответа которого зависят данные на странице - согласен. Но мне кажется, что joomla.request больше для внутреннего пользования. Представить сайт, где внешних запросов нет, анимации в дизайне сделаны на css. Тогда jquery не слишком нужен. И сеошник будет спокойнее, зная, что не грузится ещё одна неиспользуемая библиотека от 60 до 200кб весом.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации