Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 53
Если делать в twig шаблонах такой код, будут неприятности.
Есть какой либо решение такой задачи?
Есть какой либо решение такой задачи?
я не профи twing. Но у себя я использую такую конструкцию мета код:
все темплейты рактива лежат в отдельных файлах что хорошо. twig тоже судя по всему так умеет.
<script id="template name">
include ./template_name.ractive
</script>
все темплейты рактива лежат в отдельных файлах что хорошо. twig тоже судя по всему так умеет.
Конечно решение есть! Внимательнее читаем документацию Twig
twig.sensiolabs.org/doc/tags/verbatim.html
twig.sensiolabs.org/doc/tags/verbatim.html
В TWIG'e можно переопределить синтаксис шаблонизатора, если это конечно сильно необходимо и отказаться от стандартных {{ variable }} / {% condition %}
Я так и не понял, можно ли использовать делегирование событий?
В документации есть совершенно непонятная фраза:
А так, в целом, похоже на ангуляр двухсторонним связыванием.
В документации есть совершенно непонятная фраза:
Because of the way proxy events work, they more or less eliminate the need for event delegation.
А так, в целом, похоже на ангуляр двухсторонним связыванием.
Там идея в том что ractive сам занимаеться делегированием. Поэтому фактически не нужно самим это делать. Там есть крайние случае, но это не очень инетерсная тема.
Это это совсем не Ангуляр. т.е. в чем то конечно похоже, а в чем то даже писался с него. Но есть очень ключевые различия.
Почитать можно здесь blog.ractivejs.org/posts/whats-the-difference-between-angular-and-ractive/
Это это совсем не Ангуляр. т.е. в чем то конечно похоже, а в чем то даже писался с него. Но есть очень ключевые различия.
Почитать можно здесь blog.ractivejs.org/posts/whats-the-difference-between-angular-and-ractive/
Я так понял зверь этот без роутера?
Да, туториал радует
Matreshka.js, статьи о ней на хабре
Есть еще такой интересный проект ripplejs.github.io и vuejs.org
В целом понятно, выглядит нормально, но не увидел какой-то новизны или киллер-фичи… пойду пока почитаю "What's the difference between Angular and Ractive?", от вас жду статью Ractive vs. React!
Как говорится, всё познаётся в сравнении.
Как говорится, всё познаётся в сравнении.
Так там же есть и сравнение Reacive vs React blog.ractivejs.org/posts/whats-the-difference-between-react-and-ractive
Сравнение есть но его на самом деле можно и нужно расширить (в том числе примерами). Особенно про React.
И всетаки стоит глянуть еще сюда vuejs.org/perf. Я пишу на Angular довольно давно, но вот vuejs показался мне очень интересным, тем более подход почти как у Angular.
Интересные ребяра, правда я пока не могу понять в чем их фишка точнее отличее от Ractive. Они говорят что они вдохновлялись Angular и Ractive. Но из обзора ме могу понять что они делают по другому. Строят паралельный DOM? Перерисовывают весь UI?
Я так понял, тоже самое что Ractive (паралельный DOM + api инстанса) но все цепляется через дерективы как у Angular но все равно с пимисью mustache?
Кстати не подходит если нужно поддерижвать IE8
Я так понял, тоже самое что Ractive (паралельный DOM + api инстанса) но все цепляется через дерективы как у Angular но все равно с пимисью mustache?
Кстати не подходит если нужно поддерижвать IE8
Последнее время появилось много библиотек с реализацией двухстороннего связывания, но по мне, эта не тянет на ту, которая приведет нас к «бриллиантовому веку веб-разработки».
Сам я использую Angular и не совсем понимаю для чего нужны библиотеки вроде этой. Почему бы не подключить Angular (или подобные полноценные фреймворки) и не использовать все его преимущества, как роутеры, директивы, ресурсы и многое другое.
С одной стороны аргументом в пользу таких решений как Ractive.js может быть то, что не стоит стрелять из пушки по воробьям, и если мне лишь нужно вывести комментарии, то незачем подключать для этого такой инструмент как Angular. Но во-первых никогда не знаешь что может понадобиться завтра, а во-вторых при всей его мощи минифицированная версия Angular «весит» в полтора! раза меньше чем минифицированный Ractive.js
Поправьте меня, если я не прав.
Сам я использую Angular и не совсем понимаю для чего нужны библиотеки вроде этой. Почему бы не подключить Angular (или подобные полноценные фреймворки) и не использовать все его преимущества, как роутеры, директивы, ресурсы и многое другое.
С одной стороны аргументом в пользу таких решений как Ractive.js может быть то, что не стоит стрелять из пушки по воробьям, и если мне лишь нужно вывести комментарии, то незачем подключать для этого такой инструмент как Angular. Но во-первых никогда не знаешь что может понадобиться завтра, а во-вторых при всей его мощи минифицированная версия Angular «весит» в полтора! раза меньше чем минифицированный Ractive.js
Поправьте меня, если я не прав.
107KB vs 137BK действительно Angular легче в размере.
Но они используют 2 разных подхода к решению одной и той же задачи. Это не просто 2х сторонний биндинг.
Опять же хочу как нить написать отедльный пост и попытаться сравнить.
Если кратко: если вы пишете большое приложение… на самом деле большое, или пишите UI под мобилы — вы сталкнетесь с проблемами производительности в Angular. Он проверяет на любое изменение все дерево зависимостей что приводит к плохим результатам в больших приложухах, и самое главное не понятно что с этим всем делать. C паралельным DOM таких проблем нет (точнее они меньше) потому что меняеться только то что должно поменяться + вполне понятно как оптимизировать, отследив что ререндариться.
Если у вас маленькое приложение то учить и использовать Ангулар — как вы сказали из пушки по воробьям. А изучение Ангулара та еще радость.
+ субъективное мое мнение. Мне больше нравиться работать с маленькими (всмысле зоны ответственности) библеотеками сконцентрированными на какой то функции и группировать с другими библеотеками и смотреть что в данный момент под данное ТЗ, наилучшим образом решает задачу. Поэтому мне не нравиться (субъектвино) ангуляр который имеет мнение обо всем.
Но они используют 2 разных подхода к решению одной и той же задачи. Это не просто 2х сторонний биндинг.
Опять же хочу как нить написать отедльный пост и попытаться сравнить.
Если кратко: если вы пишете большое приложение… на самом деле большое, или пишите UI под мобилы — вы сталкнетесь с проблемами производительности в Angular. Он проверяет на любое изменение все дерево зависимостей что приводит к плохим результатам в больших приложухах, и самое главное не понятно что с этим всем делать. C паралельным DOM таких проблем нет (точнее они меньше) потому что меняеться только то что должно поменяться + вполне понятно как оптимизировать, отследив что ререндариться.
Если у вас маленькое приложение то учить и использовать Ангулар — как вы сказали из пушки по воробьям. А изучение Ангулара та еще радость.
+ субъективное мое мнение. Мне больше нравиться работать с маленькими (всмысле зоны ответственности) библеотеками сконцентрированными на какой то функции и группировать с другими библеотеками и смотреть что в данный момент под данное ТЗ, наилучшим образом решает задачу. Поэтому мне не нравиться (субъектвино) ангуляр который имеет мнение обо всем.
Он проверяет на любое изменение все дерево зависимостей что приводит к плохим результатам в больших приложухах
Angular не перестраивает весь список. Он точно так же делает точечные изменения в DOM, т.е. если изменился только один объект из списка, то обновится только соответствующий ему элемент в DOM не затрагивая остальные.
Для примера:
jsbin.com/nivitituqane/2/edit
Попробуйте удалить один из элементов в инспекторе и нажать на кнопку «Change me» на каком либо элементе. Если бы перестраивался весь список, то удаленный элемент снова появился бы, но этого не происходит.
Конечно у Angular есть проблемы с производительностью при большом количестве данных в том же ng-repeat, но честно говоря в своих приложениях не сталкивался с ними. Да и еще стоит проверить не лишен ли таких проблем Ractive.js
Интересный експеремент. Реально спасибо.
Но суть в том что если вы удалили руками ноду то она собственно умрет. Ангулал не перисовывает список а пытаеться искать в доме атирбуты (все) и поменять его. Не находя атрибут он его не меняет. Вобщем ничего страшного.
Что бы понять что он перерисовывет весь дом попробуйте в вашем методе добавить елемент в array.
О магия если вы удалите елемент из дом он вернеться. Чего не произойдет в Рактив.
Авторы англар утверждают что «вообще это не важно» — stackoverflow.com/questions/9682092/databinding-in-angularjs/9693933#9693933
Я думаю что если вы работаете над небольшим проетктом вам не нужен ангулар. Если вы работаете над действительно большим вы не сможете его применять.
Хотя на самом деле я думаю что если вы уже выучили Ангулар — и не работаете в компании которая делает денамический интерфейс для миллионов пользователей — забейте на все и пользуйтесь Ангуляр — реально хорошая штука если ее постигнуть.И авторы правы (ссылка вверху) врядли вы сталкнетесь с проблемой производительности. Если вы еще не потратили моного времени на изучение Ангулара — попробуйте полностью понять за 30 минут Ractive и улыбка непременно окажеться у вас на лице. ИМХО.
Но суть в том что если вы удалили руками ноду то она собственно умрет. Ангулал не перисовывает список а пытаеться искать в доме атирбуты (все) и поменять его. Не находя атрибут он его не меняет. Вобщем ничего страшного.
Что бы понять что он перерисовывет весь дом попробуйте в вашем методе добавить елемент в array.
$scope.changeItem = function(item){
item.title = "Changed "+item.title;
$scope.items.push({title:'fun2',content:'Fun2'});
}
О магия если вы удалите елемент из дом он вернеться. Чего не произойдет в Рактив.
Авторы англар утверждают что «вообще это не важно» — stackoverflow.com/questions/9682092/databinding-in-angularjs/9693933#9693933
Я думаю что если вы работаете над небольшим проетктом вам не нужен ангулар. Если вы работаете над действительно большим вы не сможете его применять.
Хотя на самом деле я думаю что если вы уже выучили Ангулар — и не работаете в компании которая делает денамический интерфейс для миллионов пользователей — забейте на все и пользуйтесь Ангуляр — реально хорошая штука если ее постигнуть.И авторы правы (ссылка вверху) врядли вы сталкнетесь с проблемой производительности. Если вы еще не потратили моного времени на изучение Ангулара — попробуйте полностью понять за 30 минут Ractive и улыбка непременно окажеться у вас на лице. ИМХО.
В этом случае нужно использовать
jsbin.com/qavekiwayebu/1/edit
Если не удалять целиком элемент из DOM, а удалить (или изменить) например заголовок внутри элемента, то вы увидите что даже при добавлении нового элемента в коллекцию заголовок не появится снова. При удалении всего элемента он появится заново потому что теперь DOM не соответствует коллекции (на мой взгляд все логично), но опять же не будет перестраивания всего списка, а только добавление удаленного элемента в нужное место.
Подробнее здесь:
www.bennadel.com/blog/2556-using-track-by-with-ngrepeat-in-angularjs-1-2.htm
track by, чтобы Angular мог ассоциировать элемент коллекции с DOM элементом.jsbin.com/qavekiwayebu/1/edit
Если не удалять целиком элемент из DOM, а удалить (или изменить) например заголовок внутри элемента, то вы увидите что даже при добавлении нового элемента в коллекцию заголовок не появится снова. При удалении всего элемента он появится заново потому что теперь DOM не соответствует коллекции (на мой взгляд все логично), но опять же не будет перестраивания всего списка, а только добавление удаленного элемента в нужное место.
Подробнее здесь:
www.bennadel.com/blog/2556-using-track-by-with-ngrepeat-in-angularjs-1-2.htm
Интресный разговор.
Покопавшись еще чуть чуть я понял что не правильно понимал что такое «dirty-checking».
Я думал что он имеет ввиду что «кода что то изменилось мы пересоздаем весь дом». На самом деле это значит (я так думаю) «Мы отслеживаем все изменения я в данном scope и по всем дерективам проверяем поменялось ли значение по отношению к преведущему или нет и если поменялось то нужно обновлять данный кусок DOM».
и тут java.dzone.com/articles/improving-angular-dirty
docs.angularjs.org/guide/scope ( Sope Life Cycle);
After evaluating the expression, the $apply method performs a $digest. In the $digest phase the scope examines all of the $watch expressions and compares them with the previous value. This dirty checking is done asynchronously. This means that assignment such as $scope.username=«angular» will not immediately cause a $watch to be notified, instead the $watch notification is delayed until the $digest phase. This delay is desirable, since it coalesces multiple model updates into one $watch notification as well as it guarantees that during the $watch notification no other $watches are running. If a $watch changes the value of the model, it will force additional $digest cycle.
Ractive — делает дерево зависимостей и обновляет только тот DOM который зависит, т.е. он трекает кто от чего зависит и меняет это только в том случае если что то поменялось в его дереве. О изменениях в дереве он узнает через ractive.set(). ( кстати именно поэтому ангулар может работать без set);
Я был не прав в том что думал что ангулар всегда пересоздает весь DOM. Но он полностью просчитывает (dirty checking) состояние отображение на каждое изменение что дорого. Как директх.
Покопавшись еще чуть чуть я понял что не правильно понимал что такое «dirty-checking».
Я думал что он имеет ввиду что «кода что то изменилось мы пересоздаем весь дом». На самом деле это значит (я так думаю) «Мы отслеживаем все изменения я в данном scope и по всем дерективам проверяем поменялось ли значение по отношению к преведущему или нет и если поменялось то нужно обновлять данный кусок DOM».
и тут java.dzone.com/articles/improving-angular-dirty
docs.angularjs.org/guide/scope ( Sope Life Cycle);
After evaluating the expression, the $apply method performs a $digest. In the $digest phase the scope examines all of the $watch expressions and compares them with the previous value. This dirty checking is done asynchronously. This means that assignment such as $scope.username=«angular» will not immediately cause a $watch to be notified, instead the $watch notification is delayed until the $digest phase. This delay is desirable, since it coalesces multiple model updates into one $watch notification as well as it guarantees that during the $watch notification no other $watches are running. If a $watch changes the value of the model, it will force additional $digest cycle.
Ractive — делает дерево зависимостей и обновляет только тот DOM который зависит, т.е. он трекает кто от чего зависит и меняет это только в том случае если что то поменялось в его дереве. О изменениях в дереве он узнает через ractive.set(). ( кстати именно поэтому ангулар может работать без set);
Я был не прав в том что думал что ангулар всегда пересоздает весь DOM. Но он полностью просчитывает (dirty checking) состояние отображение на каждое изменение что дорого. Как директх.
Но для меня опять повторюсь ключевым отличием или преимуществом являеться простота Ractive.
т.е. нет никаких внедрение зависимости, котроллеров, $scopes, атрибутов который работают не прозрачно и т.д.
Документацию сложно (может быть это только с моим маленьким мозгом) читать и понимать так как воводиться огромное количество новых концепций которые не интуитивные.
Для того что бы начать писать сложные UI на Ractive нужно 40-50 мин времени и понимать как UI бить на компоненты. Причем не компоненты как это видит Ractive… а на обычные web components.
т.е. нет никаких внедрение зависимости, котроллеров, $scopes, атрибутов который работают не прозрачно и т.д.
Документацию сложно (может быть это только с моим маленьким мозгом) читать и понимать так как воводиться огромное количество новых концепций которые не интуитивные.
Для того что бы начать писать сложные UI на Ractive нужно 40-50 мин времени и понимать как UI бить на компоненты. Причем не компоненты как это видит Ractive… а на обычные web components.
Но для меня опять повторюсь ключевым отличием или преимуществом являеться простота Ractive.Можете ещё попробовать Angular Light, он проще чем Angular.js, имхо, и там тоже нет фабрик, модулей, DI, и т.п.
т.е. нет никаких внедрение зависимости, котроллеров, $scopes, атрибутов который работают не прозрачно и т.д.
$scopesВсе же Ractive имеет аналоги базовых вещей — для $scope, это частично раздел data.
Напишите чем это отличается от, например, knockout и backbone, и какие плюсы и минусы.
Про knockout не напишу — на нем ничего не писал.
Backbone — если коротко то это модель\коллекции моделей где стандартизированно апи по взимодействию с сервером. на кажое изменение модели они кидают ивенты. Так же есть вьюшки которые просто группируют куски DOM и метод render который вставляет его в DOM.
Дальше вы связываете render метод (биндите) разных вьешек с разными моделями. И наступет радость — вы обновили модель — поменялась вьюшка.
Минусы такого подхода в том что описание вьюшек не декларативное и приходиться проверять состояние приложения, и второе либо приходиться делать ооочень маленькие вьшечки пипушечки чуть ли не накжое проперти модели либо приходиться перерисовывать много дома, который не изменился.
Ну и самое главное в бекбоне надо порядок больше кода для того что бы это связать воедино.
Ractive же говорит опишите темплейт и я там буду менять только то что меняеться в модели. Очень точечно и за один цикл. Никаких ивентов… биндингов и прочего.
Из возможных минусов — Ractive занимаеться только UI. Больше он ничего не умеет… ни моделью управлять… ни роутера нет… ни валидаторов… вам прийдеться искать что то для этих задачь. Для некотрых это + для некоторых это -.
Backbone — если коротко то это модель\коллекции моделей где стандартизированно апи по взимодействию с сервером. на кажое изменение модели они кидают ивенты. Так же есть вьюшки которые просто группируют куски DOM и метод render который вставляет его в DOM.
Дальше вы связываете render метод (биндите) разных вьешек с разными моделями. И наступет радость — вы обновили модель — поменялась вьюшка.
Минусы такого подхода в том что описание вьюшек не декларативное и приходиться проверять состояние приложения, и второе либо приходиться делать ооочень маленькие вьшечки пипушечки чуть ли не накжое проперти модели либо приходиться перерисовывать много дома, который не изменился.
Ну и самое главное в бекбоне надо порядок больше кода для того что бы это связать воедино.
Ractive же говорит опишите темплейт и я там буду менять только то что меняеться в модели. Очень точечно и за один цикл. Никаких ивентов… биндингов и прочего.
Из возможных минусов — Ractive занимаеться только UI. Больше он ничего не умеет… ни моделью управлять… ни роутера нет… ни валидаторов… вам прийдеться искать что то для этих задачь. Для некотрых это + для некоторых это -.
От knockout отличается, похоже, тем, что как-то здесь всё запутанней))
ну backbone это совсем мимо корзины, т.к. там совсем ни слова про реактивность, а вот от нокаута я вижу совсем минимальные различия.
Смотрю я на этот неровный забор из колбэков семи уровней вложенности, и мне как-то плохеет. Не столько от того, что такой код существует, сколько от того, что его существование никого не удивляет и не возмущает.
«Бриллиантовый век», ага.
«Бриллиантовый век», ага.
Вложенность максимум что я нашол — 3. init() -> on('save') -> then(); если я чет не вижу поправте. Учитывая что практически весь код сконцентрирован в init (что может быть не есть феншуй но и не преступленее точно, скорее инкапсуляция для компонента) — то можно смело сказать что вложенность максимум 2. on('save',callback) -> then(callback).
ИМХО не так плохо, коллбек на ивент, коллбек на сетевой запрос. Поправте меня пожалуйста если я что то пропускаю.
ИМХО не так плохо, коллбек на ивент, коллбек на сетевой запрос. Поправте меня пожалуйста если я что то пропускаю.
Для прототипов и одноразовых проектов:
— наклепать нужный функционал сможет вчерашний студент за дешево
— поддерживать код не нужно, при необходимости дешевле переписать с нуля
А как только прототип есть и есть положительные отзывы, то можно браться за разработку «с умом», вводить всякие абстракции и т.п.
Но посудите сами, многие веб проекты написанные на коленке вполне себе работают и приносят деньги, так зачем идти против системы и пытаться продать то, что никому не нужно?
— наклепать нужный функционал сможет вчерашний студент за дешево
— поддерживать код не нужно, при необходимости дешевле переписать с нуля
А как только прототип есть и есть положительные отзывы, то можно браться за разработку «с умом», вводить всякие абстракции и т.п.
Но посудите сами, многие веб проекты написанные на коленке вполне себе работают и приносят деньги, так зачем идти против системы и пытаться продать то, что никому не нужно?
Для сравнения сделал аналог вашего примера на Angular Light, HTML'а вышло меньше, js кода вроде как тоже, и вес библиотек 13кб.
Спасибо за пример.
Примеры на самом деле не одинаковые.
Форма была отдельно от коммента. По множественному нажатию на «Добавить комментарий» не додовлялось безконечные формы ответа. Что бы форма ответа была снизу и сверху по условию. Анимация на комент была другая и именно она должна бять. Дата форматировалась в «минут назад» и еще много мелочей. У вас получилось меньше кода и локаничней потому как вы упростили саму задачу.
Если вы не против я утяну к себе ваш пример и доделаю что бы они были действительно одинаковыми что бы использовать в сравнении vs.?
Примеры на самом деле не одинаковые.
Форма была отдельно от коммента. По множественному нажатию на «Добавить комментарий» не додовлялось безконечные формы ответа. Что бы форма ответа была снизу и сверху по условию. Анимация на комент была другая и именно она должна бять. Дата форматировалась в «минут назад» и еще много мелочей. У вас получилось меньше кода и локаничней потому как вы упростили саму задачу.
Если вы не против я утяну к себе ваш пример и доделаю что бы они были действительно одинаковыми что бы использовать в сравнении vs.?
Примеры на самом деле не одинаковые. Анимация на комент была другаяДа, но мой пример покрывает требование «озвученное» в самом посте, а т.к. у меня нет информации о детальном ТЗ, поэтому я сделал самое основное — древовидные комментарии с анимацией.
Если вы не против я утяну к себе ваш пример и доделаю что бы они были действительно одинаковыми что бы использовать в сравнении vs.?Конечно не против, буду благодарен если вы бросите потом мне ссылку на результат.
А вообще, сравнения лучше проводить на каких-то нейтральных примерах вроде todomvc, т.к. некоторые примеры могут быть «заточены» под выдвигаемый фреймворк.
Ну как я и писал это пример из реального проекта «Пятнашки» (ЗОЖ сайт) над которым сейчас работаю — поэтому сделанно так как видит дизайнер а не потому что удобно сделать с библиотечкой. Я специально брал реальные требования и дизайн потому как всегда черт в мелочах — типа можно сделать очень легко, но не так как хочет дизайнер и тогда это никому не нужно.
Ссылку кину как сделаю. Спасибо.
Ссылку кину как сделаю. Спасибо.
До бриллианта в моем понимании не дотягивает. Надо что бы вообще никакого js кода писать не приходилось, а был набор готовых виджетов и REST сервер для вливания в них данных.
А мне понравился Ractive.
Для небольших интерактивных штук он подходит хорошо.
Если не рассматривать большие веб-сервисы, а говорить про традиционные сайты малого и среднего формата, да еще и построенные на какой-либо CMS, то Angular туда иной раз ну просто не ввернуть.
В то же время Ractive позволяет неплохо решать точечные возникающие задачи.
Для небольших интерактивных штук он подходит хорошо.
Если не рассматривать большие веб-сервисы, а говорить про традиционные сайты малого и среднего формата, да еще и построенные на какой-либо CMS, то Angular туда иной раз ну просто не ввернуть.
В то же время Ractive позволяет неплохо решать точечные возникающие задачи.
Соглашусь с oledje. Ractive это подобие Angular, не совсем успешная попытка сделать проще. Местами еще сырая.
Я из лагеря которые попробовали и то и другое. Рактив первым — когда столкнулся с задачей сделать сложное миниприложение. А через полгода пришлось разбираться с проектом на ангуларе. Да, с рактивом (после «pure jQuery» подхода) сначала было счастье, но затем начал ловить кучу мелких, но пакостных и сложновоспроизводимых багов, сообщал автору с примерами на jsfiddle. Некоторые он чинил, некоторые обещал посмотреть но забил. Самому же не было времени разбираться, нужен был рабочий инструмент. С энгуларом проблем не было, все работает четко и документации куча. НЕ всё ясно сразу, но и НЕ всё нужно сразу.
Все различия приводимые автором рактива — не плюсы, а ограничения рактива. Энгулар может работать в режиме рактива, но обратное не верно. В энгуларе таки совсем не обязательно использовать свой роутинг, DI, тесты, директивы, сервисы, фабрики и прочее, используй свое, или юзай только датабиндинг — добро пожаловать. Но когда проект (да и разработчик) начнет расти — этот набор пригодится, хотя бы в качестве best practices. Также не стоит заявлять что контроллеры это что-то что необходимо только в энгулар — в рактиве у вас контроллер внутри var Comments = Ractive.extend({...}). Еще автор рактива пугает некими $scope.$digest и $scope.$apply — но в «простом» режиме (т.е. в режиме имитации рактива) с ними скорее всего даже не придется столкнуться/понимать.
Я тоже сначала купился на простоту рактива. Но в работе обнаружил множество сложновоспроизводимых пакостных ошибок. Плюс библиотека сыровата, много чего не хватает. Например: данные обязательно нужно обновлять через Ractive.set(), иногда это не очень удобно (когда скажем кусок данных передаем в метод, и тот не знает всего пути). Банально не хватало Ractive.remove(whatever), потому что Ractive.set(whatever, null) не удаляет whatever, да и не должен. Еще пришлось сделать костыль вроде getRactivePathByDiv() — это когда надо что-то менять у соответственного объекта при клике на связанный div (в энгуларе это решается из коробки и чуть иначе: с помощью аттрибута ng-click='doWhatever(object)' — несмотря на олдскульность вполне удобно). Впоследствии еще обнаружил что в ractive очень не хватает аналога ngIf (ng-if) — возможности вырезать из дома HTML который не отображается (но влияет на скорость парсинга). А размер дома сильно порой влияет на плавность анимации.
Короче говоря, я бы посоветовал начать сразу с энгулара. Это не так сложно как кажется, точнее работать в режиме рактива точно несложно. Но намного полезнее с точки зрения обучения правильным подходам, включая: переходить на deferred вместо коллбэков, к DI и изоляции/тестируемости, устранить надобность в jQuery и её манипуляциях (по крайней мере в контролерах). И много чего еще, не говоря уже о возможности расширяьт HTML новыми тэгами, что самом деле круче декларативности — ведь это декларативность с инкапсуляцией. Впрочем, консерваторы могут опять же обойтись и без этого — angularjs довольно либеральный во всех отношениях.
Я из лагеря которые попробовали и то и другое. Рактив первым — когда столкнулся с задачей сделать сложное миниприложение. А через полгода пришлось разбираться с проектом на ангуларе. Да, с рактивом (после «pure jQuery» подхода) сначала было счастье, но затем начал ловить кучу мелких, но пакостных и сложновоспроизводимых багов, сообщал автору с примерами на jsfiddle. Некоторые он чинил, некоторые обещал посмотреть но забил. Самому же не было времени разбираться, нужен был рабочий инструмент. С энгуларом проблем не было, все работает четко и документации куча. НЕ всё ясно сразу, но и НЕ всё нужно сразу.
Все различия приводимые автором рактива — не плюсы, а ограничения рактива. Энгулар может работать в режиме рактива, но обратное не верно. В энгуларе таки совсем не обязательно использовать свой роутинг, DI, тесты, директивы, сервисы, фабрики и прочее, используй свое, или юзай только датабиндинг — добро пожаловать. Но когда проект (да и разработчик) начнет расти — этот набор пригодится, хотя бы в качестве best practices. Также не стоит заявлять что контроллеры это что-то что необходимо только в энгулар — в рактиве у вас контроллер внутри var Comments = Ractive.extend({...}). Еще автор рактива пугает некими $scope.$digest и $scope.$apply — но в «простом» режиме (т.е. в режиме имитации рактива) с ними скорее всего даже не придется столкнуться/понимать.
Я тоже сначала купился на простоту рактива. Но в работе обнаружил множество сложновоспроизводимых пакостных ошибок. Плюс библиотека сыровата, много чего не хватает. Например: данные обязательно нужно обновлять через Ractive.set(), иногда это не очень удобно (когда скажем кусок данных передаем в метод, и тот не знает всего пути). Банально не хватало Ractive.remove(whatever), потому что Ractive.set(whatever, null) не удаляет whatever, да и не должен. Еще пришлось сделать костыль вроде getRactivePathByDiv() — это когда надо что-то менять у соответственного объекта при клике на связанный div (в энгуларе это решается из коробки и чуть иначе: с помощью аттрибута ng-click='doWhatever(object)' — несмотря на олдскульность вполне удобно). Впоследствии еще обнаружил что в ractive очень не хватает аналога ngIf (ng-if) — возможности вырезать из дома HTML который не отображается (но влияет на скорость парсинга). А размер дома сильно порой влияет на плавность анимации.
Короче говоря, я бы посоветовал начать сразу с энгулара. Это не так сложно как кажется, точнее работать в режиме рактива точно несложно. Но намного полезнее с точки зрения обучения правильным подходам, включая: переходить на deferred вместо коллбэков, к DI и изоляции/тестируемости, устранить надобность в jQuery и её манипуляциях (по крайней мере в контролерах). И много чего еще, не говоря уже о возможности расширяьт HTML новыми тэгами, что самом деле круче декларативности — ведь это декларативность с инкапсуляцией. Впрочем, консерваторы могут опять же обойтись и без этого — angularjs довольно либеральный во всех отношениях.
Спасибо за опыт.
По поводу нехватки в Ractive фич. Данные нужно обновлять через set — если не нужно поддерживать IE8 и меньше — то можно поставить magic mode и он будет использовать геттеры сеттеры что бы слушать уведомаления о изменении. и можно будет писать var comment.text = 'нет'.
Про «remove» согласен нехватает. Делать racitve.set('prop',null) странно.
getRactivePathByDiv — костыль не нужен, посмотрите как передается текущий объект e.context в моем примере. так же можно делать так
on-click='doWhatever,{{object}}' и вторым параметрав в doWhatever будет object.
По поводу if — и блоков которые не видны, тоже все есть. посмотрите мой пример там есть {{#if}} и {{#replys.comments > 0}}
Возможно вы пользовались старой версией либы. Сейчас все проблемы описанные решены.
И так же согалсен что знаметиные родители с большой командой поддержки — это тоже +.
По поводу нехватки в Ractive фич. Данные нужно обновлять через set — если не нужно поддерживать IE8 и меньше — то можно поставить magic mode и он будет использовать геттеры сеттеры что бы слушать уведомаления о изменении. и можно будет писать var comment.text = 'нет'.
Про «remove» согласен нехватает. Делать racitve.set('prop',null) странно.
getRactivePathByDiv — костыль не нужен, посмотрите как передается текущий объект e.context в моем примере. так же можно делать так
on-click='doWhatever,{{object}}' и вторым параметрав в doWhatever будет object.
По поводу if — и блоков которые не видны, тоже все есть. посмотрите мой пример там есть {{#if}} и {{#replys.comments > 0}}
Возможно вы пользовались старой версией либы. Сейчас все проблемы описанные решены.
И так же согалсен что знаметиные родители с большой командой поддержки — это тоже +.
Вы упомянули в статье, что Ractive работает очень быстро, не могли бы вы добавить Ractive к «местному» бенчмарку.
Если уже есть какие-то готовые бенчмарки, то интересно было бы посмотреть.
Если уже есть какие-то готовые бенчмарки, то интересно было бы посмотреть.
Добавил Ractive (оптимизированный вариант) в бенчмарк, для данного теста он оказался медленнее чем Angular.js, а если использовать штатные push/set то он становиться ещё медленнее раз в 10.
А есть примеры/ссылки на проекты, которые используют Ractive? Историю/стабильность самого Ractive и т.п.
Понятно, что за Angular и React стоят крупные компании, хотелось бы каких-то «гарантий» или уверенности в плане Ractive.
Понятно, что за Angular и React стоят крупные компании, хотелось бы каких-то «гарантий» или уверенности в плане Ractive.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Ractive.js — бриллиантовый век web-разработки