Если коротко, то так:

const fetchitInstance = new FetchIt(form: HTMLFormElement, config: {
  action: string,
  assetsUrl: string,
  actionUrl: string,
  inputInvalidClass: string,
  customInvalidClass: string,
  clearFieldsOnSuccess: boolean,
  pageId: number,
});

// или

FetchIt.create(config: {
  action: string,
  assetsUrl: string,
  actionUrl: string,
  inputInvalidClass: string,
  customInvalidClass: string,
  clearFieldsOnSuccess: boolean,
  pageId: number,
});

Но проблема в том, что конфиг генерируется во время рендера страницы. Так уж задумано. Я подумаю как можно облегчить такие задачи в будущем

Всё просто. В документации к API написано куда и какие запросы слать и какой ответы ты получишь. Тебе нужно с помощью curl отправлять запросы, а потом обрабатывать полученный результат с помощью php и API Modx. Как ты оформишь код дело твое. Запускать можно или кроном или в плагинах, зависит от задачи.

Подскажите пожалуйста, если форма подгружается после инициализации FetchIt, например модалку(с вызовом сниппета FetchIt) подгружаю по надобности, как на форму в модалке «инициализировать» FetchIt?

В серверной части FetchIt практически является форком AjaxForm.

А в источнике файлов смотрел?

Не знаю, как кому, а мне это не помогло.
Установил 3.0.3 поверх 2.8.5, админка перестала работать сразу. Просто ни одна кнопка не работает и всё. В консоли — куча ошибок.
После выполнения трюка с заменой Om часть русских букв появилась, остальное — так же нечитаемо. Админка осталась мёртвой.

У меня работает так

<div class="cookie-message js-cookie-message">
    <div class="container">
        <div class="cookie-message-inner">
            <div class="cookie-message-text">
                We use cookies to enhance your experience. 
            </div>
            <button class="button js-cookie-message-confirm">OK</button>
        </div>
    </div>
</div>
<script>
const el = document.querySelector('.js-cookie-message');
    if (!localStorage.getItem('cookieAccept') || localStorage.getItem('cookieAccept') == 0) {
        el.style.display = 'block';
        el.querySelector('.js-cookie-message-confirm').addEventListener('click', (e) => {
            localStorage.setItem('cookieAccept', 1);
            el.style.display = 'none';
        }, true);
    } else {
        el.style.display = 'none';
          
    }
</script>

БЛАГОДАРЮ!

Отправка писем прописана в классе minishop2, расширение которого не предусмотрено. Либо пиши свою отправку, либо правь исходники, либо отправляй ссылку на файл загруженный на сервер.

Лучше написать свой снипет (что то типо такого):

<?php
$tvId = "TV id";
$tvr = $modx->getCollection('modTemplateVarResource', array(
  'tmplvarid' => $tvId,
  'contentid:IN' => [1,2,3]//список ИД ресурсов
));
foreach($tvr as $tv){
    $value = json_decode($tv->get('value'), 1);
    foreach($value as $item){
        echo $item['title'];
    }
}

Вопрос. Компонент использует сессии для хранения параметров так же как AjaxForm или этот момент решен как то иначе?

Добавлять авторизацию и регистрацию — это не «такое себе»

Не такое себе, я этим пользуюсь, мне удобно когда это есть.

Т.е. для простой задачи добавить и/или изменить значение в форму перед её отправкой, нужно манипулировать с DOM или расширить класс?

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

Именно с этим лозунгом ты сменил jquery-form на XMLHttpRequest

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

Ты проигнорировал вопрос про асинхронность в XMLHttpRequest

Потому что счёл его риторическим, логично же что никаких работ по усовершенствованию не ведётся, разработан новый API и его развивают.

А когда в XMLHttpRequest появится (спойлер — не появится, но есть библиотеки-обёртки над ним в которых реализована асинхронность) ты обратно перепишешь с Fetch API на XMLHttpRequest?

Ты меня за идиота принимаешь? Я решаю возникающие у меня задачи, удобным для меня способом. Мне нужно показывать процесс загрузки, Fetch API этого не умеет, я использовал XMLHttpRequest. По-моему всё логично.

Мне кажется ты упускаешь суть: ты писал компонент с целью внедрения Fetch API, я писал компонент с целью повысить удобство собственной работы и отказаться от использования jQuery. Не вижу причин по которым я обязан был использовать Fetch вместо XMLHttpRequest. Для пользователя компонента это вообще не важно, что там под капотом, главное это стабильное выполнение необходимых ему функций.

И наконец, всё что ты перечислил в качестве проблем AjaxFormitLogin, всего лишь твоё скромное мнение, о чем ты забыл упомянуть, отчего кому-то может показаться, что перечисленные тобой «проблемы» действительно серьезно могу усложнить жизнь пользователю моего компонента. Я думаю тот, кому понадобится больше событий и API, легко поймёт, что всё это есть в FetchIt, и выберет именно его.

Кстати, тут меня в комментариях @Лёша спросил про возможность показа сообщения в самой форме и я показал как это можно реализовать, но дело в том, что такая возможность была в альфа версии компонента, но я потом убрал такой функционал из коробки. Если проявите интерес, то я могу вернуть его.

просто потому что я не могу придумать для чего это может понадобиться лично мне. А добавлять что-то, чтобы было такое себе.

Ну Артур, ну какой ты молодец. Добавлять авторизацию и регистрацию — это не «такое себе», просто я не понял и это вообще другое.

Хорошо, ты не смог придумать, а я представь — смог. Тык, тык и тык.

Грубо говоря да, но при желании всегда можно расширить класс.

Прости, но мне придётся поязвить — ты же обязательно покажешь как расширить класс? Т.е. для простой задачи добавить и/или изменить значение в форму перед её отправкой, нужно манипулировать с DOM или расширить класс? Прикольно.

Нет смысла обновлять то, что и так работает.

Я уже понял. Именно с этим лозунгом ты сменил jquery-form на XMLHttpRequest

Когда такая возможность появится — перепишу.

Ты проигнорировал вопрос про асинхронность в XMLHttpRequest, но это приводит к более веселой ситуации: А когда в XMLHttpRequest появится (спойлер — не появится, но есть библиотеки-обёртки над ним в которых реализована асинхронность) ты обратно перепишешь с Fetch API на XMLHttpRequest?

Банально — такой, такой и такой

Думаю это ни к чему в данном компоненте, просто потому что я не могу придумать для чего это может понадобиться лично мне. А добавлять что-то, чтобы было такое себе. Если кто-то предложит PR, волью без проблем.

Добавление и/или изменение значений отправляемых на сервер

Грубо говоря да, но при желании всегда можно расширить класс.

Каждый раз когда зависимость обновиться, нужно будет обновить компонент?

Нет смысла обновлять то, что и так работает.

когда разработчик sweetalert2 захочет выразить свой личный протест в OpenSource проекте, то как быть с этим?

Понятное дело не использовать подключение зависимостей через cdn.

Работа над введением этой возможности ведётся и оно точно появится

Когда такая возможность появится — перепишу.

Какой API нужен компоненту для отправки форм ajax'ом?

Банально — такой, такой и такой

Какие задачи связанные с отправкой формы нельзя решить используя AjaxFormitLogin?

Добавление и/или изменение значений отправляемых на сервер, например. Или ты хочешь предложить манипулировать DOM для этого?

AjaxForm тянул jQuery и jGrowl, AjaxFormitLogin тянет IziToast только для того, чтобы из коробки были уведомления. В документации написано как отключить их и заменить.

Ну мне то объяснять уж не стоило. Ответ на вопрос «Почему?» я знаю, тут другой несколько вопрос «Зачем?». Каждый раз когда зависимость обновиться, нужно будет обновить компонент? Ну прикольно. А еще бывают «прикольные приколы», когда разработчик sweetalert2 захочет выразить свой личный протест в OpenSource проекте, то как быть с этим?

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

Fetch API не позволяет отслеживать процесс загрузки файлов, а мне это нужно.

Позиция ясна. А это единственная причина? Fetch API пока не позволяет. Но знаешь в чём загвоздка? Работа над введением этой возможности ведётся и оно точно появится, а ведётся ли работа над асинхронностью в XMLHttpRequest?

а в чём смысл AjaxFormitLogin сейчас

В том, что этот компонент упрощает мне разработку сайтов, там много всякой функциональности, которая нужна почти на каждом сайте. А вообще, читайте документацию, чтобы решить надо оно вам или нет.

Отсутствие API

Какой API нужен компоненту для отправки форм ajax'ом?

Нехватка событий (есть одно afl_complete) что не позволяет решать разные задачи

Какие задачи связанные с отправкой формы нельзя решить используя AjaxFormitLogin?

Повторение недостатка AjaxForm (AjaxForm тянул зависимость ввиде jgrowl, а AjaxFormitLogin теперь тянет iziToast)

AjaxForm тянул jQuery и jGrowl, AjaxFormitLogin тянет IziToast только для того, чтобы из коробки были уведомления. В документации написано как отключить их и заменить.

Самое главное, AjaxFormitLogin заменил громоздкий jquery-form на XMLHttpRequest — это нонсенс

Fetch API не позволяет отслеживать процесс загрузки файлов, а мне это нужно.

В AjaxFormitLogin нет jGrowl, там IziToast. Можно заглянуть к нему в документацию и настроить как хочется, или расширить класс уведомлений и написать свои.

Я так понял эти компоненты идентичны

Проблем у AjaxFormitLogin множество.

• Отсутствие API
• Нехватка событий (есть одно afl_complete) что не позволяет решать разные задачи
• Повторение недостатка AjaxForm (AjaxForm тянул зависимость ввиде jgrowl, а AjaxFormitLogin теперь тянет iziToast)
• Самое главное, AjaxFormitLogin заменил громоздкий jquery-form на XMLHttpRequest — это нонсенс