Можно добавить этот промис в секцию стэйта resolve. Тогда контроллер не будет выполнен до тех пор, пока все зависимости в resolve не будут разрешены. Значение, в которое разрешился промис, будет также доступно для внедрения в дочерних стэйтах и их контроллерах.
Встроенных средств нет.
Правильнее написать директиву, которая будет слушать изменения в модели. При сохранении вы к примеру генерите событие, при котором эта директива сохраняет текущее значение модели. При несовпадении модели и ее последнего сохраненного значения директива выставляет на элементе определенный класс.
Вы уверены, что дело именно в клиентской части?
Может у вас на сервере работает всего один процесс, который не может обработать более одного запроса одновременно?
Если во время этой долгого запроса руками подергать запрос прогресса - он будет отрабатывать сразу?
Вы неправы, dom обновляется один раз.
Если ваша таблица изменяется настолько часто, то предполагаю, что ваш вопрос происходит из-за того, что вы столкнулись с некими тормозами?
Если речь идет про запросы к api, то их можно вынести в resolve стэйта, который сделать родительским для всех стэйтов - тогда resolve не будет выполняться каждый раз при переходах между дочерними стэйтами.
Но как уже сказали выше, вы, вероятно, что-то хотите сделать неправильно.
Если вы используете ui-router, то можно выполнять код по событию $stateChangeSuccess
Вы зря полагаетесь на то, что выдает браузер в качестве mime-типа. Они (браузеры) не знают большое количество типов и не могут гарантировать корректное распознавание, т.к. производят его на основе расширения (под windows). Самый верный на мой взгляд способ — это найти или реализовать самому аналог mime-magic на Javascript.
Лично у меня напрашивается вариант с разделением ролика на несколько контрольных точек и отстукиванием на сервер факта просмотра каждой точки. Затем на сервере инкрементировать счетчик просмотров например при просмотре 60% точек.
Хотя знаю случаи, когда просмотром считается нажатие на кнопку Play.
Возможно, такая частота как-то связана с частотами, присутствующими (а точнее наоборот, не присутствующими) в речи какого бы то ни было человека.
По крайней мере, это верно для DTMF-сигналов, у которых в спектре две частоты подобраны таким образом, что в речи любого человека эти две частоты никогда одновременно не присутствуют, что позволяет с высокой достоверностью выделять эти сигналы из речи.
А в чем проблема? При использовании комментариев на основе materialized path все комментарии можно выбрать одним запросом по индексам, а потом преобразовать в дерево при выводе.
Мне кажется, что комментарии как раз и не кешируются здесь.