KurtsKhalia: я сам less по привычке использую, sass на проектах с ionic, stylus пока вот только думаю пробовать. Вы сами посмотрите что вам больше понравится.
Влад Developer: если делать как я описал и подумать о потенциальных проблемах даунтайма может вообще не быть. Я же говорю, все крайне сильно упирается в реализацию.
OnYourLips: есть разница между жестким ТЗ и спецификациями составляемые в общении разработчиков с BA/Product Owner-ом (в идеале еще QA если они есть, в противном случае его функции должны выполнять разработчики).
Testtest132: давайте сначала разберемся с терминологией. Любое изменение DOM вызывает перерисовку (перерендривание).
Что до ngRepeat - оно не создает новых элементов если они у него есть. То есть если вы добавили в коллекцию элемент - то будет создан новый. Если вы убрали элемент из коллекции - то удалит DOM элемент. Если вы перемешаете элементы в коллекции, то тут все интереснее.
У Angular для ngRepeat есть довольно клевая оптимизация - track by. ngRepeat умеет определять какой DOM элемент для какого элемента коллекции принадлежит. По умолчанию $id элемента генерируется силами angular (если вы просто напишите item in list например это будет равносильно item in list track by $id(item)). Когда ngRepeat обходит коллекцию, вместо того что бы создавать и вставлять в DOM новые элементы, он сначала смотрит есть ли у него уже они. Если есть - приступаем к следующему элементу. Если нет - тогда будет создавать.
Это дело очень хорошо работает с сортировкой коллекции, с фильтрами чуть худе так как удаляя данные из коллекции мы удаляем DOM элемент и при последующей вставке оного ангуляр будет его создавать заного.
Алексей Романенко: ну вариантов как пробросить в репозиторий на самом деле не так уж много. Это либо много много аргументов для метода либо Configuration Object. Я делаю и так и так, конфигурационный объект для пагинации и сортировки можно применить один на весь проект по сути и обрабатывать его во фронт контроллере (по onRequest) что бы уменьшить количество кода в контроллерах.
Илья: я понимаю, просто говорю что Docker для этих целей использовать разумнее. А затем уже без разницы на одной машине докер контейнеры развернуты или на нескольких. Зато меньше оверхэд при сохранении изоляции. Так же можно вооружиться skydns и подобными штуками и динамически разруливать хосты на разные сервера, например в случае отказа или при деплое проекта.
Запросы для api где есть сортировка пагинация и прочее:
/users/?skip=20&limit=10&sort=id~desc,name~asc
что-то в этом духе.
Всю логику выношу в сервисы.
Репозитории - стараюсь в сервисах не использовать методы доктрины, только методы моих репозиториев. В этом случае для конкретной сущности сменить хранилище не составляет проблем - меняется только реализация репозитория, но зато весь остальной код не нужно трогать. Но все же реальность такова что не на всех проектах разумно делать для каждой сущности свой репозиторий.