ng-click="$ctrl.closeTestResult()" WTF?)

Метод из контроллера компонента. Исправь плз код как считаешь правильно и я гляну)

https://jsfiddle.net/73q20wdg/1/

div(class="test-result-bar" ng-if="$ctrl.isVisible") ng-if я бы перенес на parent-component

ну и все еще о байндингах) в чем таки разница между "<" и "=" потому что даже при "<" когда меняю в компоненте забинденную переменную, то родительская тоже меняется

< - one way binding - данные записанные в компонент будут единожды инициализированны = - two way binding - данные можно передавать в оба направления и компонент имеет постоянно обновленное значение переинициализация "<"-байндинга возможна при ререндеринге парент-компонента в случае использования "<"-байндинга желательно использовать хук onChange(chObj) и проверять изменения из вне... такое делают уже когда появляется необхожимость в жесткой оптимизации приложения.... на ранних этапах мы вообще не смотрим на это и везде используется "="... после окончания релиза и по мере необходимости рефакторинга/оптимизаций / можно уже задумываться о том. что было бы лучше сделать для быстроты... а если еще глубже идти. то посмотри на "::"-опцию) и как я уже писал... 1) работу в компоненте нужно делать в onInit() а не в контроллере... 2) controllerAs: "$ctrl" - уже сам по себе default-value, и является избыточным

Имхо, “<“ следует использовать не для оптимизации, а для более явного потока данных Если компонент изменяет пришедшие к нему данные так, что они меняются и у родителя — дело плохо. Завтра добавится ещё два компонента и потом ищи-свищи, где, как и когда данные меняются Если же использовать функции типа on-value-changed, то это даёт офигенный контроль над данными - всегда можно понять откуда пришли изменения и решать — обновить оригинальный объект или нет

< - one way binding - данные записанные в компонент будут единожды инициализированны = - two way binding - данные можно передавать в оба направления и компонент имеет постоянно обновленное значение переинициализация "<"-байндинга возможна при ререндеринге парент-компонента в случае использования "<"-байндинга желательно использовать хук onChange(chObj) и проверять изменения из вне... такое делают уже когда появляется необхожимость в жесткой оптимизации приложения.... на ранних этапах мы вообще не смотрим на это и везде используется "="... после окончания релиза и по мере необходимости рефакторинга/оптимизаций / можно уже задумываться о том. что было бы лучше сделать для быстроты... а если еще глубже идти. то посмотри на "::"-опцию) и как я уже писал... 1) работу в компоненте нужно делать в onInit() а не в контроллере... 2) controllerAs: "$ctrl" - уже сам по себе default-value, и является избыточным

а по 1 пункту имелось ввиду не в контроллере, а конструкторе?

Я так понял, что не один я такой. Передача данных в область видимости component поставит в тупик, если пользоваться официальной докой. Для меня стало ясно это после http://www.devcode4.com/article/angularjs-component-bindings И этого https://medium.com/front-end-weekly/angularjs-component-binding-types-my-experiences-10f354d4660

как лучше всего организовать межкомпонентное взаимодействие? у меня допустим есть родительский компонент и внутри него дочерний с выводом некоторого списка. допустим, что в родительском нажимают на кнопку и из дочернего должен удалиться один из элементов списка. через emit делать?

как лучше всего организовать межкомпонентное взаимодействие? у меня допустим есть родительский компонент и внутри него дочерний с выводом некоторого списка. допустим, что в родительском нажимают на кнопку и из дочернего должен удалиться один из элементов списка. через emit делать?

Привет всем. Кто работал с Aws?

Не относится

И что

подскажите как более правильно из 2 вариантов. Есть 2 сервиса В каждом из них делать $rootScope.$on('$stateChangeStart', (event, toState) =>{ ТУТ ДЕЛАЕМ что-то что касается именно этого сервиса. }) Или делать 1 прослушку и внутри делать действия для 2 сервисов?

зависит что именно ты там будешь делать как бы, если в будущем требования к БЛ будут расходится то лучше делать отдельно иначе будут всякие кондишины что бы разруливать какой сервис вызвать а если вместе, то я даже причину не придумаю почему так может быть моежт БЛ в сервисах одинаковая тогда ?

а что такое БЛ?) Ну да по сути будут кондишены. Типа если стейт такой-то то делай тото

привет! есть ли возмоэность докапаться где дигест ломается? Error: [$rootScope:infdig] 10 $digest() iterations reached. Aborting!

+ есть ли какой-нибудб пакет для анализа dependency injection в проекте? вроде https://github.com/compodoc/ngd?

в документации пишется что это промис, но откуда этот промис берет?

в документации пишется что это промис, но откуда этот промис берет?

Привет! можно ли как-то залочить загрузку компонент и приложения до тех пор пока не закончится appRun'ер ?

Не отображать? Disabled?

если в angular.run() есть асинхронные запросы, то приложение запускается дальше... т/о грузится "/" а за ним уже и "/login"...

Удалил-продлема пофиксилась-готово вы великолепны

forgotPassword(model: Models.IForgotPasswordModel): ng.IPromise<void> { var deferred = this.$q.defer<void>(); this.$http.post(HttpService.serviceBase + 'api/account/forgotpassword', JSON.stringify(model)) .success((data) => { deferred.resolve(); }) .error((data, status) => { deferred.reject(this.onError(data, status)); }); return deferred.promise; } почему во многих примерах/проектах используют $q для httpService'a????

forgotPassword(model: Models.IForgotPasswordModel): ng.IPromise<void> { var deferred = this.$q.defer<void>(); this.$http.post(HttpService.serviceBase + 'api/account/forgotpassword', JSON.stringify(model)) .success((data) => { deferred.resolve(); }) .error((data, status) => { deferred.reject(this.onError(data, status)); }); return deferred.promise; } почему во многих примерах/проектах используют $q для httpService'a????

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

$http это и есть ангуляровская штука

forgotPassword(model: Models.IForgotPasswordModel): ng.IPromise<void> { var deferred = this.$q.defer<void>(); this.$http.post(HttpService.serviceBase + 'api/account/forgotpassword', JSON.stringify(model)) .success((data) => { deferred.resolve(); }) .error((data, status) => { deferred.reject(this.onError(data, status)); }); return deferred.promise; } почему во многих примерах/проектах используют $q для httpService'a????

можно это все сделать и без $q

"кастомно обрабатывать запросы, например если имеем дело с цепочкой промисов"

да, похоже, что ты прав