Pull to refresh

Comments 24

AngularJS весит где-то мегабайт

Версия 1.2.0 RC2 весит ~89кб, это совсем не так много. Да и гугловский CDN намного улучшает ситуацию.
Ясное дело, что в ангуляре синтаксис сумасшедший (касательно директив), но это только вопрос привычки. Да и в проекте, где потребовались директивы, скорее всего, потребуется и остальной функционал AngularJS.
Да, случайно ошибся когда вспоминал про ангуляр. Уже исправил, ответил ниже.
Симпатично. Скролл, правда, не айс — не для перетягивания мышкой, надо поправить. Но функционал приятный.
Спасибо. Не заметил, случайно взял старую версию директивы. Обновил ссылку на фидл, теперь все должно работать аккуратно
UFO just landed and posted this here
Да, с размером — наврал, извиняюсь, возможно, перепутал с какой-то другой библиотекой по памяти. Уже убрал.
Но я ни в коем случае не хочу конкурировать с ангуляром, corner — это маленькая библиотека для вынесения всего того, что не связано с основным потоком работы приложения из него.

Касательно синтаксиса — я ни в коем случае не критикую angularJS, я сам сделал на нем не один проект, вопрос в другом: он работает на durtyChecking-е. Да, он обещает перейти на Object.observe, но директив это не коснется, так как они в любом случае пересчитываются только при каждом ре-рендере шаблона.
Более близкую аналогию с технологической точки зрения на самом деле можно привести с Polymer и принципом web Components, где с кастомными элементами можно ассоциировать определенный код, отсылку к директивам ангуляра я сделал скорее потому что это куда понятнее для объяснения. Ну и, конечно, потому что разработка началась благодаря ангуляру — после трех проектов на нем было очень сложно строить статику, а подключать такую-архитектуру на сайт, который не оперирует никакими данными, ощущалось немного глупо.
Ну в ключе не single-page приложений, смысл конечно имеется.
1) angularjs весит меньше jQuery (ввели в заблуждение… давненько не смотрел на вес jQuery)
2) так как в angularjs есть jqLite подключение jQuery остается на ваш выбор
3) data-binding?
4) Dependency Injection?

последние 2 пункта так же экономят массу времени, и без них это как-то скучно… По сути все что есть в ангуларе сейчас — это как раз таки директивы и все что нужно для того что бы они работали (даже контроллеры подключаются через директивы).
Все дополнительные фичи аля ngRoute и т.п. вынесено в отдельные модули.
нужно будет залезть в панель веб-разработки и вручную поменять значение repeat у любого из клонированных элементов

Поменял у одного из элементов с «repeat=5» на «repeat=7», в итоге остался один элемент. Так и задумано?
Аналогично. Что-то я тоже не понял этот момент
Ого. Да, это мой баг — добавлял красивые эффекты к директиве для публикации, самое интересное — что у меня работало во всех браузерах.
Сейчас обновил фиддл, можно поиграться.
Да, более того — в Corner используется полифилл для mutationObserver от полимера, и я сам пытаюсь отслеживать изменения обеих проектов.
brick указан зря — это комплект элементов на базе x-tags, в действительности существует всего 2 реализации web Components.
Я периодически использую в качестве эксперимента(например, там, где однозначно не будет поддерживаться ie) Polymer, однако он сам по себе несколько монструозен и тяжеловесен. В любом случае даже x-tags более тяжеловесное решение, в которое входят полифиллы для HTML imports, Custom Elements, входит достаточно больше количество кода, которое позволяет обсчитывать жизненный цикл компонента.

Если лезть глубже — то директивы Corner-а это что-то среднее между директивами ангуляра и компонентами.
С одной стороны — они навешиваются на элемент (не создают новый элемент, а базируются на старых), их может быть несколько, они могут появляться в любой момент жизненного цикла элемента и так же исчезать. С другой — их события действительно похожи на те, которые используются в web Components — решениях: создание, исчезновение, изменение атрибута.

В пользу директив говорит простота при почти том же функционале, в пользу веб-компонентов — переносимость(вы ведь в курсе, что и полимер, и x-tags способны использовать компоненты друг друга?). Однако далеко не в пользу компонентов говорит то, что они опираются на:
-WeakMap полифилл, при этом они используют решение, которое в в пользу скорости(прирост в сравнении с «правильной» реализацией огромный, в некоторых случаях — в сотни и тысячи раз в силу того что сложность официального решения O(n), сложность их — O(1)) несколько не соответствует стандарту и способно в некоторых случаях банально падать.
-MutationObserver полифилл, не способный отлавливать удаление атрибута(все остальное на самом деле полностью соответствует стандарту)
-HTML imports полифилл, который в силу своей природы выполняет синхронный XHR-запрос, что крайне негативно сказывается на времени загрузки страницы, и поэтому я бы рекомендовал использовать его только в разработке
-Shadow DOM полифилл. Его я не использовал, поэтому не могу по своему опыту ничего сказать, но то, что я видел в исходниках, наводит меня на мысль на то, что опять же быстродействие ощутимо проседает.

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

В любом случае, компоненты не позволяют расширять текущие элементы. А в случае же с Сorner-ом можно спокойно написать что-нибудь вроде

directive('input', function(node){
    $(node).keyup(function(){
        $(node).attr('value', $(node).val());
    })
});

и потом спокойно делать в SCSS примерно такой запрос
input {
    &:active, &:focus, &:not([value=""]) {
      & + .label {
        display: none;
      }
}
if ($(‘.element-carousel').length>0) {$('.element-carousel').initCarousel()}
if ($('.element-scrollbox').length>0) {$('.element-scrollbox').initScrollbox()}

Очень странный подход. Мне кажется надо было начинать с разбора этого кода, а потом уже про директивы.
Вполне стандартная ситуация, ничего странного.
Как по мне, в jQuery плагинах обязательно должна быть такого рода проверка внутри тех самых initCarousel и initScrollbox. Но мы с вами ведь знаем, что так бывает не всегда. Поэтому такой код можно часто встретить в проектах.
обычно внутри плагинов код примерно такой:
$.fn.foo = function () {
    return this.each(function () {
        // bootstrap stuff...
    });
};

а это значит что проверка на количество элементов не нужна. Если не найдено ничего — то и пофигу.

Опять же можно сделать еще такое:
$('[data-plug]').plug();
как это сделано в том же twitter bootstrap.
try {value = eval( '{' + value + '}' )}

OMG! JSON.parse забыли?
Статья базируется на пастулате, что
function pageChange(){
    if ($(‘.element-carousel').length>0) {$('.element-carousel').initCarousel()}
    if ($('.element-scrollbox').length>0) {$('.element-scrollbox').initScrollbox()}
это плохо.

Но нет решения этого плохого кода, с использованием Corner.js
Звучит как «Курение это плохо, а вот как мы решаем вопрос с алкоголем и наркоманией.»

Не понятно, почему вот это
directive('input', function(node){
    $(node).keyup(function(){
        $(node).attr('value', $(node).val());
    })
});
лучше чем

$('input').keyup(function(){
        $(this).attr('value', $(this).val());
});


Я не понял, чем хорош Corner.js. Чем решение на jQuery хуже или лучше.
Общий this — вообще нарушение основ языка, когда в jQuery это решается через .proxy, а в coffiscript через '=>'. Можно сказать что true = false, выдать за фишку библиотеки и ждать счастливого дебага.
Видимо, я плохой автор, раз не смог объяснить.
Это работает не как jQuery. Это не альтернатива jQuery. Этот код работает через MutationObserver, который вызывает колбэки на каждое изменение DOM-дерева. И каждый раз, когда целевой элемент добавляется, отрабатывает целевой колбэк.
Я не представляю, как на jQuery можно красиво и быстро реализовать что-то подобное:

directive('include', {alter: function (node, path) {
    $.get(path, function(responseText){
        node.innerHTML = responseText
    })
}});


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

А вообще статья базируется на постулате о том, что ПРЕДПОЛАГАТЬ появление новых элементов и вызывать инициализацию элементов по смене вьюхи или чего угодно еще это плохо.
Как угодно еще — это, например(реальный код, который я видел):

$(document).on('hashchange', function(){
setTimeout(function(){
    $('.scroller').each(function(){
        initScroller($(this))
    })
}, 500)
})


При этом человек не первый день в вебе, далеко не первый, много запущенных и работающих сайтов.
То есть человек реально делает предположение, что через .5 секунды после смены текущего анкора вызовется смена вьюхи(которая делается тоже асинхронно в силу того что слушает то же самое событие), которая успеет обновить дом-дерево.
Что страшнее всего — сами вьюхи подгружаются через $.get.
В действительности же все скроллбоксы — сущности автономные, и держать их внутри основного кода — смысла нет. Соответственно — Corner это возможность вынести абсолютно весь код, который не относится к mainflow, в отдельные изолированные блоки.

А вот это
$('input').keyup


будет работать только с теми элементами, которые в данный момент есть на странице. Если вы добавите еще один />, то он уже не будет обрабатываться.
Хотя да, без Corner заработал бы такой код. Не стану спорить.

$('body').on('keyup', 'input', function(){
        $(this).attr('value', $(this).val());
});


Относительно общего this.
Если бы я предложил синтаксис
directive('test')
.onload(function(node){this.name = node.innerHTML})
.onunload(function(){alert(this.name)})

вам было бы комфрортнее принять общий this? Потому что jQuery предлагает именно такой синтаксис. Я просто пришел к тому, что цепочка вызовов, в каждом из которых this ссылается на ноду — не так удобна для декларирования, чем общая конфигурация сразу же.
общий this — у всех колбэков, это node.directive%имя директивы с заглавной буквы%. т.е. для директивы test это node.directiveTest.

с jquery — без проблем, только нужно оборачивать в $(node), передается родная нода, не жкверишная.
Only those users with full accounts are able to leave comments. Log in, please.