vasIvas: плохо когда в html много выражений, много логики. Если тернарные операторы появляются то все очень плохо.... Словом темплейты в angular должны в идеале только отражать состояние системы, но не влиять на него. Фильтры его по сути меняют, а не реагируют на состояние, это эдакие препроцессоры состояний, полностью отказаться от них не выйдет - они все ж удобны иногда, но коллекции ими обрабатывать - это только для простеньких прототипов которые никогда не увидят продакшен.
Что до много HTML кода из-за директив - это дело можно потом обернуть в фасад и тогда все становится чуть радужнее.
По поводу "писать свое или нативное" - ну тут все упирается в то что вы хотите сделать. Скажем использование фильтров для коллекций это для простых задач быстро, но это добавляет технического долга. Если вы на 100% уверены что все будет просто, если уверены что коллекции будут маленькие, то можно забить и юзать фильтры, но потом может возникнуть ситуация при которой эту штуку придется переделывать.
Мне нравится явные штуки, надо отфильтровать коллекцию - смотришь в контроллере как это делается и не думаешь "где это оно фильтрует". Так и живу... стараюсь избегать магии.
Арсен Беспалов: да, только 99% что это нифига не RESTfull а что-то типа restfull, рестафариан мало (чуваки которые исповедуют веру в то что только чистый REST спасет мир) и не безосновательно. Обычно все ж выходит JSON RPC или HTTP API просто.
Александр Марченко: можно в темплейтах поискать по названию, если массив используется только в ngrepeat то это чуть более чем странно. В целом да, лучше бряки расставить и посмотреть.
три директивы это нормально, НО... давайте разделим обязанности:
1) у нас есть наш tbc - давайте его переименуем в toggle-container хотя бы
2) нам надо прятать и показывать наш контейнер по наведению мыши, это отдельное поведение, для него сделаем отдельну директиву (по сути у вас для этих целей используется комбинация из вашей логики + ng-class), тогда можно будет реюзать ее например... хоть и маловероятный сценарий. Или быть может мы захотим дополнительное поведение потом - по наведению на плеер показывать наш элемент - тогда это будет уже две директивы которые будут общаться между собой...
3) ng-mouseenter и ng-mouseleave вызывают $apply и по сути запускают дайгест. В нашем случае это нужно только потому что мы используем ng-class и биндинг, в то же время мы можем просто в link вешать классы или дергать ngAnimate (кому как больше нравится, в большинстве случаев ngAnimate избыточен, хоть и дает дополнительную гибкость).
4) кнопки о контейнере поидее знать не должны... как же их прятать и как вообще реагировать на клики? Обычно люди не парятся и юзают ngHide/ngShow. В этом случае контейнер не нужен (нужно только состояние плеера...
Вообще разделять все в плодь до кнопок - это слишком избыточно. Я бы сделал директиву вида player-controls возможно с атрибутом указывающим на конкретный инстанс плеера... со своим темплейтом и радовался бы. Тогда можно было бы подменять реализацию на другую и мы бы сохранили гибкость и упростили бы реализацию...
p.s. если и соберусь то это будет не скоро, вопервых мативации мало (ну мне эта статья интересна только с точки зрения истории, я перевожу статьи что бы другим кидать))
copal: ну там по поводу будущего этих подходов, мол все становится сложнее и изначальная идея уже плохо справляется, хотя идею все еще передает. И это 2003-й год еще, до всяких там RoR.
ГЛЕБ ГЛЕБОВ: ввожу, правда не всегда, иногда мне лень так как интерфейс только один. А еще я использую агрегаты и делаю все взаимодействие объектов через корень агрегата, но это уже отдельная тема (если хотите почитайте Эрика Эванса).
Что до адаптера - да, приблизительно по такому принципу. Ну и да, контроллер это не один класс, это целый слой, это все от точки входа до экшена контроллера. Там маршрутизация идет и все такое.
