Григорий Васильков

Простейшая реализация

<form type="multipart/form-data">
<input type="file" multiple="multiple" />
<button type="submit" />
</form>

А потом начинаются годы опыта, чтобы сначала скрыть инпут и подменить его красивым, показывающим саму фоточку вместо имени. Потом проверить файлы на типы и размер, причем на фронте. Сверху на это можно подключить нарезалку на фронте типа "выделите мышью часть фотки". Потом загружать их по одному ещё до того, как ты нажал отправить, потом показывать статус бар (сколько загружено) и ошибки (где упало), потом думать как это сохранять на бекенде, потом понять, что картинки надо пережимать, потом, что место на сервере кончается и нужно подключать облако, потом что у нас есть "бросить этот сервер и переехать на другой" и как слить картинки чтобы ничего не потерять...

Задача лютой сложности для тех, кто все это не знает, хотя кажется "загрузить картинки".

Без знаний простейшая реализация - "дайте доступ на сервер, я вам картинки закачаю и на сайте выведу, разово". В менее запущенных случаях "делаем скрипт, в который можно отправить зип архив с картинками", это проще, но если им самим разрешить это делать - они запорют.

Есть мааааленькая вероятность, что ваш старый код уже работает и нужно только какую-то строку исправить. Проверяйте удачу!

Я обычно отдельно вебпаки не настраиваю, больно это сложно для меня. Я беру компонент "symfony/encore", пишу класс, который работает с манифестом, и там в энкоре уже есть как watch, так и listen.

Не то чтобы это правильно, но это просто чуть быстрее, чем вдуплять чего там яваскриптеры (у которых стандарты программирования (читай: последовательность мыслей) или возводятся в абсолют до тайпскрипта или вообще отсутствуют) позволили конфигурировать и как это в компоновке с вебпаком и npm варится.

Последний год использую symfony/encore и пишу обертку для php, которая читает файлы manifest.json, получая ссылку на них, вместо генераторов и билдеров, написанных разработчиками фреймворка.

Позволяет require и import любых библиотек, любые пресеты и препроцессоры, и все бонусы с этим связанные. И вообще сам Vue при этом необязателен, можно хоть из своих js файлов проект собрать.

Опишите ваш сервер. Что там, nginx? Конфиги дайте.

Скорее всего у вас либо билд косячит и файлов нету (надо npm run dev или типа того запустить), либо билд создает их не там где сервер хочет их видеть.

В конфиге сервера может стоять даже перенаправление что-то вроде "если начинается на /js" искать вообще в другом месте. По дефолту конечно такого не бывает, но в процессе работы такое могут вкостылить.

А шо не так, все прально напЫсано. Только интервалы почему-то нулевые, отрабатывают либо никогда либо каждый кадр...

AUser0, верно

v_eropov,

Вы пытаетесь выдать с сервера сразу HTML, и поэтому у вас проблемы получаются.
Если уж решили делать через асинхронный (ajax) запрос - то да, выдавайте в json, кладите его в переменную, сортируйте, и рисуйте верстку уже на javascript.

И да, вам придется строить все дивы из яваскрипта и это не короткий код. Кто-то предпочитает это делать, используя js фреймворки, типа vue/react, я предпочитаю изначально из php выдать (так было еще когда не было vue/react, а был только handlebars)

<template id="mytemplate">
  <div>
    <div>{{var1}}</div>
    <div>{{var2}}</div>
  </div>
</template>

Потом селектором этот элемент найти, и копировать его столько-то раз, делая

html.replace('{{var1}}', data.var1);

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

так она должна быть с бэка отдана при строительстве таблицы и вшита в кнопку Удалить

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

В смысле как? Это не кнопочкой делается, это берешь media запросы и пишешь.
Или хотя бы сетку bootstrap, и верстаешь 5 блоков
Есть флексы ещё но я их не очень люблю, вот эти все ихние "флексить йоу кулл"

Может ты скрипт свой вешаешь на onSubmit еще до того как загрузилась jquery у которого async?

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

Используя фронтфреймворк мы конечно наносим удар по SEO нашего сайта, но зато мы можем делать только API, а разработку внешней части поручить например другому человеку.

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

С фронт приложением ты отдал их 1 раз, а потом работаешь с данными, фронт строит по данным дальше верстку из кусков на стороне клиента, не затрачивая память и процессор сервера. Работает внешне намного быстрее, создается ощущение что сайт мгновенно обменивается данными и весь такой быстрый быстрый.

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

Это не "лучше", это "иначе".

Для начала
jQuery = $.noConflict(); // удалить глобалку jQ, делать сразу после запроса к файлу jquery.min.js
Некоторые древние деды нашей профессии любили свою главную библиотеку в доллар совать. Не важно - jquery это или нет. Бывает что две библиотеки одна заменяет другую и не работают потом обе.

потом вот так:

(function ($, App) {
  // ваш код
  $(function () {
    // ваш код после DOM-ready
  });
})(jQuery, App = window.App || {});

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

* важно помнить что высота некоторых элементов с overflow: hidden появится только через несколько секунд после загрузки страницы, когда все элементы будут отрисованы. То есть не спасает даже ondomready - нужно делать задержку на пару секунд или плакать в форум разрабам jQuery, давно пора это сделать уже

* иногда полезно работать с onload для <script src=""> чтобы поймать событие когда скрипт будет подключен к сайту, но еще до того как будет закончен ondomready

* и я вижу у вас в коде $(document).change() - не знаю что у вас там конкретно происходит, смотреть надо, но я бы на $(document) вешал только две вещи (вообще только две) - mousemove, mouseup - если они требуются. Mousemove - всевозможные ползунки, mouseup - отпускание зажатой ранее клавиши мыши для торопливого пользователя, который любит мышкой двигать с зажатой кнопкой.

Вешать onchange на документ... интересно, сколько сотен раз выполняется ваше действие?

Сделай на Promise();
Тогда тебе наружу надо просто выкинуть Промис и в другом потоке вызывать Promise.resolve(); и не нужно будет ждать пока первый поток вызовет.

Придется немного пересмотреть логику но выйдет примерно так:
1. Ты ждешь от промиза некоего результата или ошибки
2. В другом потоке произошло нечто, что требует закончить действие. Возвращаешь из другого потока реджект с массивом, в первом параметре код ошибки, во втором сообщение.

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

Пока заработало вот так:
вместо того чтобы запускать таймер для каждого запроса в пачке написал вот такую примерно конструкцию:

co(function* () {
  var limit_burst = default_limit_burst;
  var limit_minute = default_limit_minute;
  var limit_day = default_limit_day;

  // getting records from somewhere
  var records = get_the_records();

  records = yield co(function* () {
    var records_done = [];
    while (records.length) {
      let limit = Math.min(limit_burst, limit_minute, limit_day);
      let batch = records.splice(0, limit);
      
      // update limits
      limit_burst -= batch.length;
      limit_minute -= batch.length;
      limit_day -= batch.length;

      for (let i in batch) {
        // ... request
      }

      // refresh limits from response headers if available
      yield Promise.all(ps).then(results => {
        var current_limit_burst = default_limit_burst;
        var current_limit_minute = default_limit_minute;
        var current_limit_day = default_limit_day;

        // save results
        records_done = results.map(r => {
          if (r[0] !== null) return console.error(r[1]) || null;
          current_limit_burst = Math.min(current_limit_burst, r[2][0]);
          current_limit_minute = Math.min(current_limit_minute, r[2][1]);
          current_limit_day = Math.min(current_limit_day, r[2][2]);
          return r[1];
        }).filter(r => r!==null);

        limit_burst = current_limit_burst;
        limit_minute = current_limit_minute;
        limit_day = current_limit_day;
      });

      if (limit_burst <= 0) yield new Promise(r => setTimeout(r, 5000));
      if (limit_minute <= 0) yield new Promise(r => setTimeout(r, 60000));
      if (limit_day <= 0) yield new Promise(r => setTimeout(r, 86400000));
    }

    return records_done;
  });
});

Ну так событие "клик" на элементе.
А элемент предварительно впихни в массив потомков.
Потом пройдись проверкой с тройным равно (this === $i) - вот ответ

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

Если проводить грань с пхп - то вы пытаесь замапить ресурс подключения (потоком можно назвать, если хотите) - но ресурс лишь содержит данные в параметре, но он помимо коробки с данными еще и объект, стреляющий событиями.

Я бы от этого плясал в попытке понять

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

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

Да, у тебя расчет выполняет модель в PHP, а из яваскрипта ты делаешь запрос к этому расчету аяксом.

Главное чтобы твой аякс не вызывал загрузку всего сайта, а просто делал расчет, тогда все будет ну оччень быстро. Как можно это понять - сделай запрос на несуществующий URL - если сайт не подрубается - ты получишь ответ "сервер не отвечает" или стандартный .htaccess-ный Forbidden, а если подрубается - то это будет генерация страницы типа "такой страницы нету".

К примеру сравнить и рассчитать 2000 товаров, запросив сохранив результаты в гугл докс по ходу, и получив справочники из того же гугл докс, и все это выдав в виде json массива, сохранив кеши - занимает чуть больше 10 сек, и это без использования быстрых функций - просто чем было написано.

Если не подгружать весь фреймворк, чтобы вызвать действие "рассчитать", а работать с существующей базой из кеша товаров по ценам - расчет будет мгновенно делаться и не будет так набившего оскомину "лоадера" на 10 секунд расчета трех товаров из корзины. Впрочем точный запрос по id товаров в базу отработает так же быстро, если его написать с нужными join-ами, а не "запрос-запрос-запрос-объединить на PHP-рассчитать-объединить-запрос-проверить".

Впрочем, можно и действительно на ноде какой-нибудь. Главное помнить, что когда расчет делает сервер - он в работе, то есть нагрузка, когда расчет делает клиент - он может прислать тебе хрень разную (хакеры, да да), которую ты никак не проверишь, не произведя расчет на сервере.