Проблема HTML в том, что он — текстоориентированый. Это значит, что всё в документе является текстом, а тэги (структуру) мы выделяем особым способом. А реалии современных приложений таковы, что первичную роль играет, как раз, структура. А если учтем, что это мультиязычное приложение, то в документе и вовсе нету текста — он локализированный лежит в отдельных ресурсах. Поэтому хочется иметь разметку, где принцип противоположный html — всё структура, а текст выделяем особым способом. Вот и имеем десятки подобных решений.
Ах, и забыл уточнить про закольцованость — проблема в первом и последнем фрайме — между ними нету интервала, поэтому происходит как бы «ускорение» в этом месте. Используя step-start надо оставлять «0%» пустым и стартовать с 100/ frameCount.
Я также часто использую keyframes для спрайтовой анимации. Однажды мне нужна была «скриптовая» динамика, и вот скрипт для динамичного создания keyframes-правил и старта анимации: github. Там правда используется timing-function: step-start для «прыжков» по кадрам.
PS: работа с cssRules относительно дорогая процедура, поэтому нужно создавать подобные правила по-минимуму и кешировать их.
И ещё что забыл добавить — у данных бывают разные проценты риска. Поэтому не каждая функция проверяет данные. Здесь подробнее уже было на хабре — Концепция Баррикады
Собственно try..catch — это неконтролируемое поведение приложения — а это уже, что-то не так. Посмотрим на С# — там исключения использую часто, но желательно «контролируемые» исключения:
В принципе, мы и generic исключения ловим, но желательно, что бы в последний catch не заходили.
Так и с javascript, там где мы думаем, что может быть ошибка — проверяем данные на валидность, а если код с валидными данными не справляется — это бага. А что бы быть уверенным, что все хорошо на клиенте работает, есть небольшой ExcpetionHandler класс, который слушает window.onerror и «говорит» пользователю, что «что то пошло не так». И по желанию отсылает на сервер stack trace, script url и lineNumber.
Как и во многих других «error based(exception-less)» системах — проверки. Использование try..catch в javascript становится особенно тяжелым из-за множества асинхронных callback функций.
Хорошая вещь. Но не стоило называть это произвольным именем — «steelToe». Ведь на самом деле это у вас только 2е функции. И сходу взглянув на код не понятно, что происходит — не было бы органичней статично расширить объект Object?!
копипаст с проекта
Object.getProperty = function(o, chain) {
if (typeof o !== 'object' || chain == null) return o;
if (typeof chain === 'string') chain = chain.split('.');
if (chain.length === 1) return o[chain[0]];
return Object.getProperty(o[chain.shift()], chain);
}
Object.setProperty = function(o, xpath, value) {
var arr = xpath.split('.'),
obj = o,
key = arr[arr.length - 1];
while (arr.length > 1) {
var prop = arr.shift();
obj = obj[prop] || (obj[prop] = {});
}
obj[key] = value;
}
И тогда думаю всем понятно, что конкретно происходит — Object.getProperty(obj,'car.model.year'); Object.setProperty(obj,'car.model.year',2012);
Да, я об этом подумал как только увидел. Обязательно попробую с этим вариантом, тут просто больше будет семантических проблем с произвольными компонентами. Ведь намного удобнее работать, когда создав обработчик компоненты, вы получите атрибуты в .attr, a детей в .nodes — чем [1], [2]. Но над этом я ещё подумаю. Спасибо вам.
Хм, мне кажется вы сочли, что мой ответ с сарказмом — вовсе нет. Действительно — array nested tree в javascript хороший паттерн.
А вот то, в какую структуру это все превращается довольно важно — ведь с ней потом работать «дом-билдеру» и компонентам, поэтому уменьшать строки, тем самым изменяя структуру на выходе, не вариант.
О, так это вы создали 2-ой тест — очень грамотный подход, особенно array nested tree object. А вот тест как раз ваш не честный, так как на выходе мы получаем разные json. Я же взял тот json, который на выходе по данному шаблону выдает mask.compile, и сравнил с парсингом оного через JSON.parse — кажется довольно честно. Согласен, что от «40%» лишнего надо бы избавится, правда потом мы будем размножать проверки на подобии node.attr != null?. В любом случае, этот тест просто показывает, что компиляция происходит довольно быстро, и много мы не выиграем, если будем компилировать шаблоны перед дэплоем. А это, по крайней мере, мне очень важно — иметь чистые шаблоны в релизе.
Вы наверное ссылкой ошиблись, так как .renderDom там совсем не используется, а .compile, и на первый взгляд без ошибок там. А в синтаксисе, конечно же можно допустить ошибку, но не менее легче чем в обычном html, или javascript-e. В редакторе выбрав подсветку как в javascript, сразу видно литералы/блоки. И должен признать, что парсер преднамеренно сделан без кучи проверок на валидность синтаксиса, хотя сделать это не сложно. Но мне это не надо — абстракции компонент и синтаксис позволяют держать шаблоны маленькими и наглядными, где ошибку пропустить уже довольно сложно становится.
В первую очередь шаблоны нужны, что бы «оживить» html связав его с данными. А в данном случае, я предлагаю дополнительно компонентно-ориентированный макет.
> js без шаблонов — что бы построить более менее сложное приложение(а не просто страницу), одной функцией(продемонстрированной вами выше) не обойтись — в результате получаем далеко не более быстрое решение.
> Неужели Dart будет быстрее, можете провести тест?
Handlebars comparison — а теперь сравните на фоне вами рекомендованного handlebars.js. Повторюсь, что конечно, маленькая функция с одной конкатацией стрингов будет быстрее шаблонного движка. И если такой маленькой функции вам хватает для проектов, ну тогда я рад за вас.
100/ frameCount.timing-function: step-startдля «прыжков» по кадрам.PS: работа с cssRules относительно дорогая процедура, поэтому нужно создавать подобные правила по-минимуму и кешировать их.
Будет —
В принципе, мы и generic исключения ловим, но желательно, что бы в последний catch не заходили.
Так и с javascript, там где мы думаем, что может быть ошибка — проверяем данные на валидность, а если код с валидными данными не справляется — это бага. А что бы быть уверенным, что все хорошо на клиенте работает, есть небольшой ExcpetionHandler класс, который слушает window.onerror и «говорит» пользователю, что «что то пошло не так». И по желанию отсылает на сервер stack trace, script url и lineNumber.
Object?!И тогда думаю всем понятно, что конкретно происходит —
Object.getProperty(obj,'car.model.year'); Object.setProperty(obj,'car.model.year',2012);А вот то, в какую структуру это все превращается довольно важно — ведь с ней потом работать «дом-билдеру» и компонентам, поэтому уменьшать строки, тем самым изменяя структуру на выходе, не вариант.
В первую очередь шаблоны нужны, что бы «оживить» html связав его с данными. А в данном случае, я предлагаю дополнительно компонентно-ориентированный макет.
> js без шаблонов — что бы построить более менее сложное приложение(а не просто страницу), одной функцией(продемонстрированной вами выше) не обойтись — в результате получаем далеко не более быстрое решение.
> Неужели Dart будет быстрее, можете провести тест?