Спасибо, как раз искал такой инструмент, который локально имитирует публикацию ("публикует" в локальную папку, из которой можно затем "установить" собранный пакет).
"три десятка плееров под это дело" — каких, если не секрет?
"Вы уверены, что нужна статья?" — уверен, что нужна; насчет хабра — не знаю, на ваше усмотрение. Я готов прочитать и на другом ресурсе, и на английском языке.
Дело в том, что вы, с большой вероятностью, смотрите видеоклипы фиксированной длины, заранее подготовленные под вашу платформу, которая, с большой вероятностью, поддерживается как одна из наиболее популярных.
Воспроизведение видео фиксированной длины (видеоклипов, видеофайлов) работает в браузерах нативно достаточно давно, это так. Проблемы начинаются с потоковым видео неограниченной (заранее неизвестной) длины.
Мы долго экспериментировали с префиксами в именах, но в итоге отказались от них.
Насчет префиксов — они необходимы. Бывает так, что блоки (повторно используемые компоненты) требуется встроить в другие приложения и экосистемы. Причем заранее, только начиная разработку и выбирая методологию, вы не можете быть уверены в том, что компоненты не понадобятся в еще одном приложении, которое появится через пару лет. А еще если это приложение само использовало методологию БЭМ, и там также есть «header», «footer» и «btn», только с другой версткой. Не будете же вы переделывать весь UI Kit ради этого приложения.
Хорошие примеры использования префиксов — Material Design Lite, Atlassian UI (это библиотека компонентов от Atlassian, авторов JIRA, Bitbucket и др.). Первые все компоненты именуют с «mdl-», вторые с «aui-» — на трехбуквенном префиксе уже гораздо меньше вероятность пересечься. Разве что ваша компания называется More Digital Licences или Awesome United Inventions.
Плохой пример отказа от префиксов — Bootstrap со своими «row», «col», «form», «btn» и подобными «блоками». Как будто на странице не может быть других кнопок, кроме бутстраповских. Если следовать принципу отказа от префиксов в своем коде, то рано или поздно появится какой-нибудь блок «btn», которые впоследствии законфликтует с бутстрапом будучи вставленным на бутстраповскую страницу.
Посередине — jQuery UI. Они выбрали «ui-», но данный префикс слишком абстрактный. Как будто больше пользовательские интерфейсы никто не разрабатывает.
Плохо смешение синхронного и асинхронного вызовов одного и того же callback'а. Внешний код, передающий коду асинхронной природы функцию для обратного вызова, конечно, может ожидать от такого кода любого документированного поведения, но будет лучше, если это поведение будет (более) предсказуемым (асинхронным).
Например, передавая функцию в Array forEach, sort или map, я точно знаю, что моя функция будет вызвана только синхронно в процессе выполнения этих функций, и не будет больше вызываться после их завершения.
Той же предсказуемости хотелось бы и от функций асинхронной природы (например, реализующих сетевые запросы). В jQuery гарантия асинхронного вызова callback-функций, переданных в функции асинхронной природы или подвешенных на promise, не предоставляется, что приводит к необходимости в вызывающем коде предполагать оба варианта вызова переданных функций. Это требует от разработчика большего опыта и понимания происходящего, следовательно, повышается вероятность допустить ошибку, не обработав синхронный вариант вызова callback'ов.
Особенно подвержен ошибкам код, который меняет состояние объектов, перемежая изменения навешиванием обработчиков promise'ов. В случае синхронного вызова callback'ов из promise'ов, в зависимости от состояния primose'ов эти callback'и будут вызваны либо асинхронно, либо сразу при навешивании, и код внутри callback'ов может при некотором стечении обстоятельств получить управление раньше, чем изменение состояния объекта завершится.
Здесь хорошо описана разница между синхронными и асинхронными callback'ами, и делается упор на то, что, предоставляя интерфейс с callback'ами, необходимо делать их либо всегда синхронными, либо всегда асинхронными, но не смешивать.
С другими реализациями, которые следуют всем требованиям Promises/A+, promise поменяет свое состояние только после завершения всех выполняющихся функций, то есть стек при смене состояния promise и вызове callback'ов всегда будет «пустой» (содержать только вызовы функций «платформы» и не содержать вызовов функций приложения).
Например,
function getSomethingPromised() {
var def = jQuery.Deferred();
def.then(function () {
throw new Error();
});
def.resolve();
//< Выкинет Error отсюда, прерывая выполнение функции getSomethingPromised
// и всех вызвавших её функций -- функция getSomethingPromised предстала как синхронная.
doSomething(); //< Не выполнится!
return def.promise();
}
function getSomethingPromised() {
var def = jQuery.Deferred();
def.then(function () {
throw new Error();
});
setTimeout(function () {
def.resolve(); //< Выкинет Error отсюда, прерывая выполнение только функции, обрабатывающей таймер.
}, 1000);
doSomething(); //< Выполнится!
return def.promise(); //< Вернет promise в вызывающую функцию -- функция getSomethingPromised предстала как асинхронная.
}
Очень круто решается вопрос с детьми и билетами. Напомню, у нас по возрасту. Возраст без сложных движений проверить ну никак не получается. В Китае интерфейс проверки в разы проще (да, точность немного страдает, но это ведь не главное, правда?):
Альтернатив гораздо больше, например: сервер ответил ошибкой; сервер не ответил вовремя (таймаут); сервер ответил некорректной структурой данных, например, HTML вместо JSON (ошибка разбора). И еще интереснее: в поле даты введена не дата; в поле даты введено что-то похожее на дату, но не подходящее по календарю (30-е февраля); в поле поиска введены пробелы; в поле поиска введены символы, которые являются специальными в некоторых контекстах (кавычки, процент, апмерсанд и т.п.).
Судя по оценке в часах, у вас мало личного опыта программирования.
Спасибо, как раз искал такой инструмент, который локально имитирует публикацию ("публикует" в локальную папку, из которой можно затем "установить" собранный пакет).
Уважаемый автор, а есть ли перевод сего великолепного произведения на английский язык? Хотелось бы поделиться.
"три десятка плееров под это дело" — каких, если не секрет?
"Вы уверены, что нужна статья?" — уверен, что нужна; насчет хабра — не знаю, на ваше усмотрение. Я готов прочитать и на другом ресурсе, и на английском языке.
Напишете статью или дадите комментарий, какими средствами оно работает?
Дело в том, что вы, с большой вероятностью, смотрите видеоклипы фиксированной длины, заранее подготовленные под вашу платформу, которая, с большой вероятностью, поддерживается как одна из наиболее популярных.
Воспроизведение видео фиксированной длины (видеоклипов, видеофайлов) работает в браузерах нативно достаточно давно, это так. Проблемы начинаются с потоковым видео неограниченной (заранее неизвестной) длины.
2016 год на дворе. jQuery?! Angular?! Где React? Где Webpack? Где Node.js?
Спасибо, замечательно! В таком случае можете предложить свой модуль здесь: https://github.com/react-native-fellowship/react-native-blur/issues/21 (опишите эти преимущества, там пока сошлись на варианте от 500px).
Чем отличается от https://github.com/500px/500px-android-blur ?
Насчет префиксов — они необходимы. Бывает так, что блоки (повторно используемые компоненты) требуется встроить в другие приложения и экосистемы. Причем заранее, только начиная разработку и выбирая методологию, вы не можете быть уверены в том, что компоненты не понадобятся в еще одном приложении, которое появится через пару лет. А еще если это приложение само использовало методологию БЭМ, и там также есть «header», «footer» и «btn», только с другой версткой. Не будете же вы переделывать весь UI Kit ради этого приложения.
Хорошие примеры использования префиксов — Material Design Lite, Atlassian UI (это библиотека компонентов от Atlassian, авторов JIRA, Bitbucket и др.). Первые все компоненты именуют с «mdl-», вторые с «aui-» — на трехбуквенном префиксе уже гораздо меньше вероятность пересечься. Разве что ваша компания называется More Digital Licences или Awesome United Inventions.
Плохой пример отказа от префиксов — Bootstrap со своими «row», «col», «form», «btn» и подобными «блоками». Как будто на странице не может быть других кнопок, кроме бутстраповских. Если следовать принципу отказа от префиксов в своем коде, то рано или поздно появится какой-нибудь блок «btn», которые впоследствии законфликтует с бутстрапом будучи вставленным на бутстраповскую страницу.
Посередине — jQuery UI. Они выбрали «ui-», но данный префикс слишком абстрактный. Как будто больше пользовательские интерфейсы никто не разрабатывает.
habrahabr.ru/company/microsoft/blog/269871
Например, передавая функцию в Array forEach, sort или map, я точно знаю, что моя функция будет вызвана только синхронно в процессе выполнения этих функций, и не будет больше вызываться после их завершения.
Той же предсказуемости хотелось бы и от функций асинхронной природы (например, реализующих сетевые запросы). В jQuery гарантия асинхронного вызова callback-функций, переданных в функции асинхронной природы или подвешенных на promise, не предоставляется, что приводит к необходимости в вызывающем коде предполагать оба варианта вызова переданных функций. Это требует от разработчика большего опыта и понимания происходящего, следовательно, повышается вероятность допустить ошибку, не обработав синхронный вариант вызова callback'ов.
Особенно подвержен ошибкам код, который меняет состояние объектов, перемежая изменения навешиванием обработчиков promise'ов. В случае синхронного вызова callback'ов из promise'ов, в зависимости от состояния primose'ов эти callback'и будут вызваны либо асинхронно, либо сразу при навешивании, и код внутри callback'ов может при некотором стечении обстоятельств получить управление раньше, чем изменение состояния объекта завершится.
Тем, кто пользуется jQuery.Deferred, необходимо помнить, что он не следует пункту 2.2.4 спецификации Promises/A+: функции выполняются по возможности синхронно, в текущем стеке выполнения, и throw внутри функций, переданных в then, не приводят к reject, а прерывают текущий стек выполнения, то есть в зависимости от последовательности развития событий callback'и могут вызываться как асинхронно, так и синхронно, что очень опасно — асинхронные функции могут внезапно стать синхронными.
Здесь хорошо описана разница между синхронными и асинхронными callback'ами, и делается упор на то, что, предоставляя интерфейс с callback'ами, необходимо делать их либо всегда синхронными, либо всегда асинхронными, но не смешивать.
С другими реализациями, которые следуют всем требованиям Promises/A+, promise поменяет свое состояние только после завершения всех выполняющихся функций, то есть стек при смене состояния promise и вызове callback'ов всегда будет «пустой» (содержать только вызовы функций «платформы» и не содержать вызовов функций приложения).
Например,
Метр с кепкой :)
Судя по оценке в часах, у вас мало личного опыта программирования.
StaticContainer полезен также при анимации, чтобы не перерисовывать внутренности, пока элемент-контейнер анимируется: github.com/petehunt/react-touch-lib/blob/master/src/primitives/AnimatableContainer.js#L124