Баха Волков

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

так что вопрос — а можно показывать сообщение об успешной отправке в самой форме?

Да, легче легкого. Например, в чанке формы указываете какой-то элемент:

<form id="form-1">
    <!-- какая-то разметка -->
    <div class="successMessage"></div>
    <!-- какая-то разметка -->
<form>

document.addEventListener('fetchit:success', (e) => {
  const { form } = e.detail;

  if (form.getAttribute('id') === 'form-1') {
    const successMessage = form.querySelector('.successMessage');
    successMessage.innerHTML = 'Форма отправлена';

    // И вообще, делаете что хотите
  }
});

Именно поэтому я реализовал JS API (документация) таким образом, чтобы можно было реализовать разные сценарии.

Кстати, в версии альфа такая возможность была в коробке, но я выпилил в пользу API, но если люди захотят, то могу вернуть эту возможность.

На данный момент есть баг связанный с вызовом сниппета на fenom, завтра выпущу патч с исправлением.

На данный момент есть баг связанный с вызовом сниппета на fenom, завтра выпущу патч с исправлением.

День добрый!

1. У компонента нет и не может быть никаких конфликтов с jquery. Даже по stacktrace в вашем скрине видно, что ошибка не связана с fetchit. В вашем конкретном случае надо разбираться, уверен, выясниться что ошибка где-то в вашем коде.

2. Поведение ожидаемое, в данной заметке показан пример дополнительной валидации на стороне клиента, это значит, что и за поведение также разработчик отвечает. В вашем случае, если вы хотите показывать всплывающее уведомление, то нужно добавить:

fetchit.setError('phone', 'Введите пожалуйста корректный номер телефона');
FetchIt.Message.error('Введите пожалуйста корректный номер телефона');  // <-- ЭТУ СТРОКУ
e.preventDefault();

3. Не соглашусь, библиотека intl-tel-input как раз даёт возможность вводить номера телефонов в любом формате, а маска прямо противоречит этому. Вы можете использовать любое готовое решение или своё, а FetchIt без разницы что вы там сделаете, он просто собирает все данные с полей ввода формы и вскармливает их указанному сниппету.

На сколько я понимаю для данного компонента не нужен jquery, но все же с ним у него конфликт.

У FetchIt нет и не может быть конфликтов с jquery.

В вообще было бы здорово, если бы компонент прятал саму форму из html так-как роботы зачастую уже надоели и все защиты обходят. (Наверное это больше вопрос к fiormit)

Я подумаю как-нибудь о защите от спама, может что-то интересное и надумаю.

Еще раз спасибо за ваш труд!

Пожалуйста!

За модуль спасибо!

Пожалуйста!

Но не понятно в чем преимущество удаления зависимости от jquery?

Я (очень) далеко не первый кто прыгает в поезд тенденции отказа от jQuery, которая возникла по объективным причинам. Главная из которых: сам JavaScript её почти/уже догнал по функционалу и удобству.

Использовать jQuery только чтобы навесить один обработчик на событие и добавить/удалить css класс с нескольких элементов — это одеть медведя в меховую шубу! Вот если вы сфинкс в Сибири, то надевать шубу (использовать jQuery) имеет смысл.

99% сайтов на modx используют эту либу.

Ну и прекрасно, но это к чему? Это же аргумент в пользу FetchIt. Следите за руками:

— Если (как вы утверждаете) 99% сайтов на MODX используют jQuery, то AjaxForm будет работать на 99% сайтах, остальным сайтам (1%) которые без jQuery, придется тянуть зависимость только чтобы работал AjaxForm.

— Если (как вы утверждаете) 99% сайтов на MODX используют jQuery, то FetchIt будет работать на 100% сайтах, даже у тех где используется jQuery.

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

На это уже @Артур Шевченко ответил, но я дополню, больше не для вас, а для всех кто так думает. FetchIt делает больше и лучше за 300 строчек кода чем AjaxForm за более чем 12 000.

Проверил и не смог подтвердить, причем параметр clearFieldsOnSuccess по умолчанию включен и поля должны очищаться. Полагаю, что были ошибки в кастомных js и из-за них ломалось поведение.

Нужны уточнения:

1. Всё остальное работает? Отправляется ли форма, работает ли валидация?

2. Сколько вызовов FetchIt есть на странице? Если больше одного, то покажи их тоже.

3. Есть ли в консоли js какие-то ошибки?

Спасибо за отклик!

Исправил.

Версия 1.0.0 доступна на modstore.pro
Она же будет доступна после модерации на modx.com

Значит скоро будет

На данный момент — да, третья версия MODX так долго добиралась, что я и забыл про её существование

Вопрос: есть ли какая то реализация антиспама?

Ситуация ровно такая же как и с AjaxForm. Например компонент reCaptchaV3 отработает точно также.

Документацию писал в три раза дольше чем сам компонент ?

Автору лайк, стелит ровно ?

Пользуйтесь поиском, запрос буквально такой: «MIGX в MIGX fenom» и получаете миллион таких же вопросов где в каждом есть один и тот же ответ

Пусть будет)

Помогите пользователям понять вас.

Нашел в документации такой снипет

В какой документации? Документация чего?