Никита Петров: Если таймаут вынести из сервиса в контроллер, тогда обновлять данные будет всегда только контроллер и он всегда будет знать, изменились данные или нет. И не придётся с ивентами заморачиваться.
Artem0071: как я уже написал вы пытаетесь работать с массивом и с объектом одними и теми же средствами, а это неправильно. Blog.Blog.Release будет ломаться если Blog.Blog - массив. Blog.Blog[0].Release будет ломаться, если Blog.Blog - объект.
Лучше всего всё приводить к массиву и с массивом уже работать. Тогда никаких проблем не будет.
Если у вас есть доступ к серверной части - поменяйте структуру данных, чтобы в случае единственного объекта возвращался не объект, а массив с единственным элементом. Т.е. чтобы сервер всегда возвращал массив, даже если объектов вообще нет - пусть возвращает пустой массив. Тогда всё в первоначальном коде будет работать.
Если доступа к серверной части нет - сделайте парсинг на стороне клиента, чтобы он преобразовывал возвращаемую структуру к описанной выше.
Т.е. ваша задача в данной ситуации - сделать так, чтобы Blog.Blog всегда было массивом независимо от того, сколько элементов в нём.
Bogopodoben: Если объём данных слишком велик и не хочется его каждый раз заново тянуть с сервера, то лучше тогда реализовать кэширование данных в массив.
Т.е. вот у вас в сервисе есть массив accountsList - пусть это будут закэшированные данные. Когда вы делаете запрос на данные вы сразу прицепляете к промису один then, который сохраняет копию данных в этом массиве, а сами данные передаёт дальше по цепочке тому, кто их запросил. Если в сервис приходит запрос на данные, которые закэшированы и не менялись (тут ещё неплохо реализовать инвалидацию кэша по времени), вы заворачиваете свой массив в промис при помощи сервиса $q и возвращаете его тому, кто запросил. Так, с точки зрения конечного потребителя данных, он всегда будет получать промис. А у вас в сервисе будет закешированная копия, которую вы можете изменять при необходимости.
docodc: Как я написал, bourbon+neat - это основа, очень удобные миксины, чтобы следовать парадигме DRY. А компоненты лучше писать по необходимости самому, взяв за основу исходники bootstrap или tachyons тот же. Кроме того для бурбона тоже есть небольшой набор базовых компонентов вот тут: refills.bourbon.io
Роман Скобцов: Если вы не используете сетку бутстрапа, что остаётся? Вы посчитайте, сколько килобайт занимает в css бутстрапа сетка и сколько все остальные классы? Может стоит посовещаться с дизайнером и вебмастером и разработать на базе бутстрапа свой базовый набор стилей, css, на который бы все опирались в работе?
Date.parse не работает с произвольно заданным форматом (который задан в переменной format, описание возможных паттернов в документации Angular). Остальное не удовлетворяет условию.
В данном конкретном случае я решил пока исключить из возможных строк формата т.н. predefined localizable formats, кроме того мне нужна только дата без времени. Если получится достаточно универсальное решение, его нетрудно будет расширить до полной даты/времени и всех строк форматирования.
Это я понимаю и активно использую для перезаписи, например, параметров по умолчанию теми, что переданы в директиву.
А если это не просто объекты, а сервисы Angular? Как Angular к этому отнесётся? Не будет ли конфликтов каких-то?
Как говаривала моя школьная учительница (кажется она цитировала кого-то): математика ум в порядок приводит. Так что я не соглашусь с теми, кто говорит, что математика не нужна. Математика даёт тот базис, ту же логику, о которой уже говорилось, которая позволяет легко программировать, а уж способность абстрактного мышления в программировании нужна как воздух. Если речь конечно именно о программировании, а не о банальном кодинге.
