Вы вешаете обработчик на документ, и в коде регуляркой проверяете соответствие классу — каждый клик на любом элементе документа запускает ваш обработчик.
У нас таким образом реализовано кеширование некоторых «тяжелых» тимплейтов на клиенте. При сериализации в LS пишем ключ, что-то типа «сериализация прошла успешно, от такой-то даты».
При попытке десериализации сперва смотрим в этот ключ — если вдруг его нет, запрашиваем кеш с сервера, и пишем в LS.
Во-первых, .each принимает готовый массив, дальнейшие операции с ним в рамках цикла невозможны (если только не переписать реализацию).
Во-вторых, как вы заметили — у меня никак не обрабатываются .reject()-ы. Я предполагаю, что код итерации сам должен/умеет справляться со своими фейлами. В моем случае мне нужен только .resolve(), чтобы цикл мог перейти к следующей итерации.
Хотя, возможно это чревато — если итерация вернет .reject(), мой цикл никогда не закончится.
Именно, в этом и вся проблема. Аргументы $.when выполняются без соблюдения очереди. Единственная очередь в этом случае — результаты каждого Deferred-а будут переданы в общий .done() строго в порядке их добавления в $.when.
С недавних пор, кстати, в Deferred-ах появился .pipe, который, фактически, реализует синхронность, но в коде выглядит довольно сумбурно — читать очень непросто.
Мне это известно, но это не решает проблемы асинхронного выполнения набора Deferred объектов, переданных в $.when — он станет .done() как только все Deferred-ы будут .done.
В моей реализации следующий Deferred в цепочке выполнится только после .done() текущего — соблюдается порядок очереди. Такой себе waterfall, но натянутый на интерфейс each, вместо набора аргументов.
Вы вешаете обработчик на документ, и в коде регуляркой проверяете соответствие классу — каждый клик на любом элементе документа запускает ваш обработчик.
При попытке десериализации сперва смотрим в этот ключ — если вдруг его нет, запрашиваем кеш с сервера, и пишем в LS.
Во-первых, .each принимает готовый массив, дальнейшие операции с ним в рамках цикла невозможны (если только не переписать реализацию).
Во-вторых, как вы заметили — у меня никак не обрабатываются .reject()-ы. Я предполагаю, что код итерации сам должен/умеет справляться со своими фейлами. В моем случае мне нужен только .resolve(), чтобы цикл мог перейти к следующей итерации.
Хотя, возможно это чревато — если итерация вернет .reject(), мой цикл никогда не закончится.
Пруфлинк
В моей реализации следующий Deferred в цепочке выполнится только после .done() текущего — соблюдается порядок очереди. Такой себе waterfall, но натянутый на интерфейс each, вместо набора аргументов.