Мы используем такой подход: современные браузеры не тормозим, старые и так медленные.
Первым идёт небольшой скрипт который проверяет фичу и синхронно подключает скрипт полифила.
Shadowsocks Золотой щит кроме прямых блокировок занимается анализом траффика и может блокировать любое соединение. Например, если вы делаете dns запросы к facebook, а траффик не идет, то внешнее щифрованное соединение сначало теряет пакеты, а потом может и упасть.Если вы не делаете запросы, например к taobao, но траффик идет, значит вы перенаправили все dns запросы через туннель — опять срабатывает защита. Shadowsocks всё это делит и внутреннее гоняет внутрь, внешнее — через туннель.
Я перепробовал много вариантов, но только через Shadowsocks получилось Youtube в HD. Есть сборка на openwrt — что очень удобно.
Я думаю это лучше, чем «деньги мошенники сняли, в банк позвонить не можем, потому что денег оплатить нет». А вообще при должном планировании ни разу не возникало проблем. В наличности всегда какая то необходимая сумма. Пару раз телефон садился и я просто открывал окно на 2-3 транзакции на пару сотен долларов на несколько часов.
«нет связи» это по моему мнению не аргумент, сейчас гораздо сложнее найти банкомат, чем бесплатный wifi.
У меня есть две карты двух банков, у которых в мобильном приложении есть функция защиты. По умолчанию карта заблокирована. Если нужно снять или оплатить, я должен в приложении указать максимальную сумму, кол-во транзакций и временное окно. Однако возникают сложности с автоплатежами, но для этого у меня другая карта.
Release V8 5.5 24 октября (два дня до выхода node 7). В этом релизе представлены async\await функции. Баг с утечкой исправлен 16 сентября, v8 5.4 был зарелизен 9 сентября
Да, вы правы. На самом деле я не использую next как промис. Вместо того чтобы формировать массив промисов, я итерирую массив объектов, по которым нужно сделать последовательные ассинхронные вызовы и в then() создаю анонимную функцию возвращающую промис. Т.е. это как раз фабрика о которой шла речь.
Виноват, что бездумно упростил свой вариант без проверки и выдал как верный.
Т.к. я не Java программист, то делаю таким образом:
function executeSequentially(promises) {
var result = Promise.resolve();
promises.forEach(function (promise) {
// result = result.then(promise);
result = result.then(() => promise);
});
return result;
}
Сверху и снизу вы видите абсолютно идентичные по функциональности сниппеты.
Но это не так, в случае с промисами вам достаточно вызвать функцию. В случае с генераторами вам нужно вызвать функцию и построить цепочку промисов самостоятельно, попутно возвращая в next() полученное значение. Поправьте если я ошибаюсь.
// Вызов варианта с промисом
renderUserData();
// Вызов варианта с генератором
let generator = renderUserData();
generator.next().value
.then(user => generator.next(user).value)
.then(paymentDetails => generator.next(paymentDetails ).value)
Очень похоже на то, что мы использовали генератор ради использования генератора. Возможно вы скажете, что внешний вызов генератора можно отдать на откуп сопрограммам типа co.js — соглашусь, что это позволяет получать некий профит.
Смысл в том, что генераторами нельзя заменить промисы (для асинхронных вызовов). Вообще никак. Async\await — да, киллер фича, нас ждет светлое будущее (заглянуть в будущее уже можно с помощью babel и подобных)
function* renderUserData(render) {
let user = yield getUser();
let paymentDetails = yield getUserDetails(user.payment.id);
render(paymentDetails);
}
первый yield вернет user? Нет, он вернет promise, которого где то снаружи функции нужно дождаться, чтобы снова вызвать next(), тоже самое для getUserDetails(). Код не полный, а приводится как довод в пользе генераторов.
И это самое худшее что вы вспомнили? Подобные "отрицательные" отзывы для меня всегда были маркером качественного продукта.
Мы используем такой подход: современные браузеры не тормозим, старые и так медленные.
Первым идёт небольшой скрипт который проверяет фичу и синхронно подключает скрипт полифила.
В итоге новый браузер пробегает десяток if и быстро работает, старые браузеры ждут пачки полифилов.
Правда это не работает с async\await и другим новым синтаксисом, но тут мы планируем собирать два бандла.
Я перепробовал много вариантов, но только через Shadowsocks получилось Youtube в HD. Есть сборка на openwrt — что очень удобно.
«нет связи» это по моему мнению не аргумент, сейчас гораздо сложнее найти банкомат, чем бесплатный wifi.
Для навигации по сущностям я использую ctrl + click, первый клик переносит к определению, второй — загружает список всех мест использования.
Баг с утечкой исправлен 16 сентября, v8 5.4 был зарелизен 9 сентября
Виноват, что бездумно упростил свой вариант без проверки и выдал как верный.
Через reduce еще изящней
Но это не так, в случае с промисами вам достаточно вызвать функцию. В случае с генераторами вам нужно вызвать функцию и построить цепочку промисов самостоятельно, попутно возвращая в next() полученное значение. Поправьте если я ошибаюсь.
Очень похоже на то, что мы использовали генератор ради использования генератора. Возможно вы скажете, что внешний вызов генератора можно отдать на откуп сопрограммам типа co.js — соглашусь, что это позволяет получать некий профит.
Смысл в том, что генераторами нельзя заменить промисы (для асинхронных вызовов). Вообще никак. Async\await — да, киллер фича, нас ждет светлое будущее (заглянуть в будущее уже можно с помощью babel и подобных)
первый yield вернет user? Нет, он вернет promise, которого где то снаружи функции нужно дождаться, чтобы снова вызвать next(), тоже самое для getUserDetails(). Код не полный, а приводится как довод в пользе генераторов.
WeakMap, WeakSet — не содержат и не должны, иначе они бы не были Weak