Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 26
Перевод ужасен, форматирование убивает глаза, но как человек юзающий Ангулар — советую всем прочитать вдумчиво, ибо материал хороший.
Кстати текущая английская дока по директивам была недавно сущственно переписана: docs.angularjs.org/guide/directive и отличается от русского варианта.
Как получить содержимое HTML
В разделе показано как передать html в шаблон директивы.
А как получить содержимое HTML в директиву (для обработки)?
Функции link и compile вызываются с дом элементом в качестве второго и первого параметра.
Кстати, буквально вчера разбирался, как сделать парсинг (аля трансформировать введенное значение в значение для модели) значения инпута с директивой ng-model, оказалось что все довольно просто, у контролера ng-model есть поля $paresers — трансформатор из инпута в модель и $formatters — из модели в инпут (фактически тот же фильтр) это обычные массивы. И, соответственно, все что нужно для того что бы достигнуть цели — создать директиву, указать require: 'ngModel', в линкер передастся ngModelCtrl (последним аргументом) и все что остается запушить функцию парсинга в переменную $parsers контролера ngModel. Может кому пригодится)
Кстати, буквально вчера разбирался, как сделать парсинг (аля трансформировать введенное значение в значение для модели) значения инпута с директивой ng-model, оказалось что все довольно просто, у контролера ng-model есть поля $paresers — трансформатор из инпута в модель и $formatters — из модели в инпут (фактически тот же фильтр) это обычные массивы. И, соответственно, все что нужно для того что бы достигнуть цели — создать директиву, указать require: 'ngModel', в линкер передастся ngModelCtrl (последним аргументом) и все что остается запушить функцию парсинга в переменную $parsers контролера ngModel. Может кому пригодится)
Это же костыли, я уверен что можно как-то сделать без ngModel.
ngModel не кастыль, просто он используется только для форм. Для обработки содержимого используйте compile/prelink. Хотя опять же не так часто это нужно. Если вам просто нужно обернуть содержимое чем-то, есть ngTransclude, если вам нужно провести какие-то манипуляции с разметкой (заэскейпить HTML, скажем для директивы подсветки синтаксиса) то используйте compile/link.
Почему костыль? Это вполне задокументированное решение. Все инпуты именно так и работают.
ваша заметка про ngModel не относится к обработке содержимого, не вводите людей в заблуждение. ngModel только для ввода данных, не для обработки содержимого.
А можно оригинал статьи на английском?
Мне кажется аngular и слово просто — вещи несовместимые. Не зря первый комментарий по директивам, собравший 400+ лайков, говорит, что этот док не «дружелюбен» к пользователю, а второй, что это худший док, который был написан ever )) Да angular в целом дает много возможностей, но какой ценой. Приходит в голову такое сравнение, если jquery это школьная математика, то angular это высшая математика за второй или третий курс.
Это вы еще доки к three.js не читали.
Там самые сложные вещи в полстроки расписано, и тебе повезло если там не стоит todo вместо текста.
При этом такие прелестные детали WebGL, как то, что свойство repeat текстуры отрабатывает корректно только если длина текстуры степень двойки там опущены напрочь, и это ищешь почти день каждый раз.
Там самые сложные вещи в полстроки расписано, и тебе повезло если там не стоит todo вместо текста.
При этом такие прелестные детали WebGL, как то, что свойство repeat текстуры отрабатывает корректно только если длина текстуры степень двойки там опущены напрочь, и это ищешь почти день каждый раз.
Мне кажется аngular и слово просто — вещи несовместимые.
Поэтому и появились такие фреймворки как CornerJS, Angular light и др.
А я думал эти библиотеки появлялись только потому, что идея директив всем нравится, но не все хотят таскать за собой весь ангулар.
Как человек, который запилил cornerJS — подтверждаю, думаете все правильно.
С другой стороны — lega запилил Angular light, так что его точка зрения тоже верна :)
С другой стороны — lega запилил Angular light, так что его точка зрения тоже верна :)
Только вот маленькое но: я предпочитаю использовать надежные в плане поддержки решения. Проще использовать angular со всей его избыточностью в маленьком проекте, нежели взять библиотеку, на поддержку которой разработчик может внезапно забить (всякое может случиться). Скажем Angular Light в bower нету, готовых к использованию билдов я не нашел, а это значит что после каждого обновления придется ее пересобирать. Ну в общем, проблемы небольших библиотек вполне известны. Так что я бы не стал экономить на килобайтах в просто взял решение с которым будем меньше всего проблем.
Дело вкуса, я лично все собираюсь добавить cornerJS в bower — некогда.
Да и в моем случае билды всегда есть в репозитории, собранные через grunt, да и вся сборка — собрать вместе библиотеку и полифилл.
Хотя это все субьективно, потому что разработка cornerJS завершена. Забивать тут не на что, он работает, ничего с ним не произойдет. Все тесты зеленые, тесты учитывают все сценарии. Он уже не будет изменяться, максимум — будут изменяться подключенные полифиллы (я сейчас хочу сменить простой WeakMap на сложный и хорошо работающий с памятью), может, пара дополнительных валидаций для имени директивы, но api и поведение библиотеки не будут изменяться.
Последние две версии он полностью переписывался с сохранением формата для поддержки особенно сложных и необычных сценариев, и сейчас вроде бы они все учтены, вплоть до того что колбэки отрабатывают даже когда ты добавляешь класс к элементу — например замена class=«button directive-one» на class=«button directive-two» вызовет:
1.unload для directive-one
2.load для directive-two
Да и в моем случае билды всегда есть в репозитории, собранные через grunt, да и вся сборка — собрать вместе библиотеку и полифилл.
Хотя это все субьективно, потому что разработка cornerJS завершена. Забивать тут не на что, он работает, ничего с ним не произойдет. Все тесты зеленые, тесты учитывают все сценарии. Он уже не будет изменяться, максимум — будут изменяться подключенные полифиллы (я сейчас хочу сменить простой WeakMap на сложный и хорошо работающий с памятью), может, пара дополнительных валидаций для имени директивы, но api и поведение библиотеки не будут изменяться.
Последние две версии он полностью переписывался с сохранением формата для поддержки особенно сложных и необычных сценариев, и сейчас вроде бы они все учтены, вплоть до того что колбэки отрабатывают даже когда ты добавляешь класс к элементу — например замена class=«button directive-one» на class=«button directive-two» вызовет:
1.unload для directive-one
2.load для directive-two
Я не заявил, что забросил, я заявил, что разработка завершена. Библиотека будет в дальнейшем оставаться в поддержке, но у нее не будет развития, я не вижу что в нее еще можно добавить, не покидая из концепцию микроархитектуры.
Возможно, на базе ее будет сделано что-либо еще, но сама она не будет расширяться, для нее не будут переименовываться опции, добавляться новые, удаляться устаревшие и так далее.
В любом случае, движок прямо базируется на MutationObserver(хотите — почитайте исходники, там все прозрачно до невозможности), который был утвержден в DOM4 working draft еще в 2012 году, и который полностью реализован — уже без префиксов — во всех браузерах: IE11, FF14+(боже, как давно это было) и chrome18 с префиксом, chrome27 без префикса(сами считайте, какой это webkit/blink). Для альтернативных реализаций вебкита(в сафари, опере, мобильных устройствах) — все тоже очень хорошо, его сейчас нет из последних версий браузеров только в родном браузере андроида.
О всех существующих смешных багах mutationObserver вроде работы с чекбоксами или не отрабатывающих колбэках в случае многократного изменения html прямо в его же колбэках я в курсе, успел наудивляться, пока разрабатывал.
Когда API находится в таком статусе — оно уже не может измениться, это вам не flexbox.
Конечно, я отслеживаю изменения, но это уже вопрос очистки совести.
Возможно, на базе ее будет сделано что-либо еще, но сама она не будет расширяться, для нее не будут переименовываться опции, добавляться новые, удаляться устаревшие и так далее.
В любом случае, движок прямо базируется на MutationObserver(хотите — почитайте исходники, там все прозрачно до невозможности), который был утвержден в DOM4 working draft еще в 2012 году, и который полностью реализован — уже без префиксов — во всех браузерах: IE11, FF14+(боже, как давно это было) и chrome18 с префиксом, chrome27 без префикса(сами считайте, какой это webkit/blink). Для альтернативных реализаций вебкита(в сафари, опере, мобильных устройствах) — все тоже очень хорошо, его сейчас нет из последних версий браузеров только в родном браузере андроида.
О всех существующих смешных багах mutationObserver вроде работы с чекбоксами или не отрабатывающих колбэках в случае многократного изменения html прямо в его же колбэках я в курсе, успел наудивляться, пока разрабатывал.
Когда API находится в таком статусе — оно уже не может измениться, это вам не flexbox.
Конечно, я отслеживаю изменения, но это уже вопрос очистки совести.
Для тех, кто читает мануалы также невнимательно как и я, есть маленькая хитрость при объявлении шаблона.
Кроме вышеупомянутых строки
и файла-шаблона
есть возможность использовать функцию, в которую будут переданы сам элемент и его аттрибуты
т.е. весьма удобно делать динамические шаблоны в зависимости от параметров, не прибегая к стандартным преобразованиям на этапе $compile, $link.
Кроме вышеупомянутых строки
template: '<div><i>Something</i></div>'
и файла-шаблона
template: 'partial.html'
есть возможность использовать функцию, в которую будут переданы сам элемент и его аттрибуты
<my-directive param1=value1 param2=value2 />
...
template: function(element, attrs) {
if (attrs.param1 == value1) {
return '<div><one-element></div>';
} else {
return '<div><other-element></div>';
}
}
т.е. весьма удобно делать динамические шаблоны в зависимости от параметров, не прибегая к стандартным преобразованиям на этапе $compile, $link.
Только-только начал изучать angularjs, еще не привязал jquery, не смог повторить примеры у себя на локали, но чуть изучив материал, хочу немного дополнить для новичков:
1. сначала что б привязывать директивы, необходимо инициализировать модуль:
var app = angular.module('app', []);
2. вместо «element.click(function() {» нужно использовать element.on(«click», function() {
После этого все заработало. welcome!
1. сначала что б привязывать директивы, необходимо инициализировать модуль:
var app = angular.module('app', []);
2. вместо «element.click(function() {» нужно использовать element.on(«click», function() {
После этого все заработало. welcome!
вот тут есть все методы работы с элементом docs.angularjs.org/api/angular.element
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Разработка директив angularjs — это просто