хм

а при

this.prod = this.products[i].prodId;

он при каждой итерации запишется в this.prod

потом он выведется и на следующей тоже

или должен вывестись только ласт масив ?

i

типо есть 3 i, при первой i 1 запишется в this.prod 2 и 3 так же, но выведутся ли все 3 в шаблоне ?

или мб я не правильно перебираю его

can anyone help with this? http://stackoverflow.com/questions/42231985/ng-click-not-working-when-adding-disabled-class-in-materializecss

guess when button is disabled there's pointer-events:none attribute on button

gotcha

Thanks man.. I didn't knew CSS can do that too :)

I'll close the question

;)

Всем привет

Прочитал про rest,написано что при использовании rest сервер не хранит состояние

Что именно это подразумевает?

Когда я не использовал rest,у меня и так сервер не хранил состояние никакое

всем привет, ребятки, кто когда-нибудь работал с ng-admin?

Всем привет. Ребят ,кто юзает UI Router ,подскажите плиз. Если я в resolve-объект у стейта передаю 2 метода ,возвращающие промис ,они будут выполнены параллельно? то есть первый не будет ждать второго? Где-то в статье вычитал ,что должны последовательно ,и если первый реджектится ,то второй просто не отработает и роут будет отменен. Хотя на деле почему-то оба метода срабатывают

1. Посмотреть какие выполняются аяксы и в какой момент. 2. Если не устраивает как работает - $q.defer(), $q.all() и все работает как надо.

Судя по консоль логам выполянются они параллельно ,на подобии q.all. У меня такая ситуация: при переходе на стейт авторизации мне нужно 1. проверить ,актуальна ли сессия на момент перехода 2. Загрузить данные для странички авторизации ,если первое условие false, Подскажите ,нормально ли это через resolve разруливать? Может есть лучше способ?

Если контент страницы без авторизации не должен быть доступен, то нормально, но помоему лучше это сделать одним resolve, в функции которого использовать промис другого

То есть в резолв будет один метод ,внутри которого я жду эти 2 промиса последовательно?

да, один в другом, но я сейчас подумал, что инфу о пользователе можно взять и параллельно, если на ней не завязаны права на доступ к определенным частям контента страницы

q.all - не означает что обещания выполняются параллельно.

Но суть в одном ,что он пождет выполнения всех промисов ,которые у него в массиве. А мне бы нужно сразу реджектить ,если первое условие не выполнено и пропустить второй в этом случае

Как раз таки q.all реджектит сразу, как только есть хоть один реджект

Почитайте теорию про промисы - это полезная штука

Как раз таки q.all реджектит сразу, как только есть хоть один реджект

плюсую, это тебе как раз и нужно

Если конкретнее описать проблему то будет так: 1) проверяем сессию ,если сессия актуальна ,посылаем запрос на логаут. Возвращаем промис. 2) Если первое успешно ,то посылаем запрос на получение данных для авторизации. Все это должно происходить при переходе на стейт логина

мм

тебе чейн нужен

Спасибо ,сейчас почитаю подробнее про q.all ,видимо не так понимал его работу

А что за чейн?

если у тебя очередность, тогда это не all

в all все независимые друг от друга же

какая разница?

можно и 3 последовательных написать - и все их в all засунуть

суть не поменяется

но смысла такое делать нету правда, вроде)

ну да, главное в promises передать аррей а не обьект

Вот вычтал на хабре щас "$q.all принимает массив функций, которые будут запущены параллельно. Обещание, возвращаемое $q.all, будет вызвано, когда все функции в массиве завершатся. Результат будет доступен в виде массива results, в котором находятся результаты всех функций соответственно."

ну тебе же без разницы, ты не используешь данные одного промиса в другом

если первый не пройщет - уже all().catch выполнится

запущены они будут тогда - когда они запущены реально

а q.all просто их вместе собирает в один промис

который резолвится после того как отрезолвятся все

Ну в общем это норм будет ,если в резолв у стейта заколбасю q.all с двумя промисами?

но если хоть один отреджектится - то этот самый промис - не будет дожидаться остальных

а зачем ему делать запрос инфы о пользователе, если авторизация не валидная?

но я бы делал [Promises].reduce((chain, promise) => chain.then(promise), Promises[0])

я там не спрашиваю инфу о пользователе

Спасибо ,сейчас попробую

а, прочитал неправильно, извиняюсь

но лучше явно написать validate().then(request)

в all они независимые

а вообще то, в юи роутере ты могешь добавлять в зависимости один из resolve

То есть фактически у меня может второй промис раньше первого выполниться?

resolve: { promise1 () { return new Promise(); }, promise2 (promise1) { //after promise1 success } }

Вау ,не знал. Думаю ,это прям то ,что нужно

только не перегибай с вложеностями - не запрашивай в чайлде резолв парента

только на 1 уровне

потом вылезут проблемы

Большое спасибо

Странно ,у меня второй промис ,в зависимости которого я добавляю первый ,вызывается 2 раза

у меня кеш в проэкте, меня не пугает

тогда создай 1 промис с promise2.then( return promise1)

убери из резолва чтобы не путать

вынеси в фабрику

Да ,попробую так. Кстати первый промис тоже стал 2 раза вызываться ,но я полагаю ,это из-за моей криворукости. Надо будет подебажить подробнее

скорее ты его где то вызываешь еще раз

дебажь

А какой способ грамотнее с точки зрения архитектуры? с передачей промиса в качестве зависимости во второй или с одним промисом и логикой в сервисе?

грамотнее в конфигурации юи роутера писать 1 резолв

а бизнес логику сохранять в фабрике