мы не можем ничего форкджоинить и вообще комбинировать как то

их вызов

это делается под капотом роутера

и там судя по исходникам resolve: {} собирается в массив и выполнятеся через Observable.concatAll()

concatAll выполняет все последовательно

если observable холодные

ты в имплементации resolve не можеш сделать forkjoin?

ну или я не понимаю проблемы)

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

да и тупо это

именно

все верно

должно паралельно быть как с промисами

мне кстати вообще ресолверы не нравится. Пока они ресолвятся юзер видит текущий компонент, а урл уже поменялся. И создается ощущение что интефейс тупит. Мне больше понравилось в onInit данные запрашивать, а темплейт в ngIF обарачивать, тогда отклик мгновенный, а в компоненте можно лоадером покрутить

думал об этом варианте

но мне нужно резолвер после canActive запустить

там еще guard стоит перед ними

Блин, не понимаю. Объясните, пожалуйста, русским по белому... Angular 2 вообще всегда работает с серверной частью?

что, простите?

Нельзя его тупо как Angular 1 подключить в виде одной библиотечки и сделать интерфейс себе?

конечно можно

А причем тут серверная часть?:)

небось смущает ng serve :)

А чего он в примерах везде с компиляцией идет всякой? Открываю https://angular.io, а там говорят - посмотрите классный QuickStart seed. Запускаю, а там встроенный сервак.... шта?! Нельзя было просто index.html сделать?

это ж для простоты и удобства

посмотри примеры с планкера

Может насоветуете какой-то совсем нуб-гайд классный?

Всем привет, а в ng2 есть что-то вроде props.children, как в реакте?

хочу обернуть все в компонент, который будет рендерить вообще все что ему передадут, и просто добавлять свои теги

ng-content

спасибо, ушел гуглить ?

Может насоветуете какой-то совсем нуб-гайд классный?

https://angular.io/docs/ts/latest/tutorial/

Пакет становится меньше, но полностью не исчезает, конечно

Не становится существенно меньше, иногда даже больше

спасибо, я там уже :)

return { passwordRepeatCompare: { valid: control.value === this.form.get('passwordNew').value } }

а обязательно использовать FromGroup ?

import {FormGroup} from '@angular/forms'; export class ConfirmPasswordValidator { static matchingPasswords(passwordKey: string, confirmPasswordKey: string) { return (group: FormGroup): {[key: string]: any} => { let password = group.controls[passwordKey]; let confirmPassword = group.controls[confirmPasswordKey]; if (password.value !== confirmPassword.value) { return { mismatchedPasswords: true }; } } } }

это не на подсократить правда

инлайн валидаторы это сильно

зачем let? там явно const

login(mail: string, pass: number) { mail = mail.trim(); if (!mail || !pass) { return; } this.dat = { mail: mail, pass: pass }; this.aservice.login(this.dat) .then(user => { this.loading = false; if (user) { this.router.navigate(['/main']); } }); }

а этот способ на много хуже ?

Валидаторов в приложении бывает не так много.. вынесите из в отдельный файл или пакет и не мучайтесь

Конечно, плюс это исопльзовать удобно в extra валидаторах

return { passwordRepeatCompare: { valid: control.value === this.form.get('passwordNew').value } }

Спасибо.

а обязательно использовать FromGroup ?

Если пользуешь Реактивные формы, то да. Но они реально удобные. Попробуй ;)

что значит реактивные формы

Каждое поле - observable

Ну и observer

Subject, грубо говоря

В доках пишут оснонвой плюс таких форм в тестировнии, а как тестировать не показали

DD

???

Лично мне нравится, что вся логика работы формы в коде, валидаторы и т.п. хлам. А в представлении только разметка и верстка

А вот тестируем мы при таком подходе не хтмл? то есть можем прям инстансы филдов дергать из формы менять и expect ?

а не искать на странице хтмл инпут итд

А вот тестируем мы при таком подходе не хтмл? то есть можем прям инстансы филдов дергать из формы менять и expect ?

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

что будет гарантировать этот тест?

Ну это вопрос и предположение одновременно было =) https://semaphoreci.com/community/tutorials/testing-components-in-angular-2-with-jasmine Не так много статей просто по тестированию форм, вот если тут смотреть то ведь так и получается? или перепутал что то

https://github.com/gonzofish/semaphore-ng2-webpack Вот гит из статьи

прихоится по статьям/блогам лазить , т.к в офф доке именно про тестирование форм, реактивных не реактивных не слова

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

А зачем проверять инпуты?

Их нужно проверять, если они выставляются в зависимости от другого параметра

да надо не инпуты скорей проверять а форму целиком, я формы выношу в компоненты, например <user-form [user]="newUser" (onSubmit)="submit($event)" (onCancel)="cancel($event)">

это глупый компонент, он отрисовывает форму, валидирует ввод и если форма валидно заполнена при сабмите прокинет JSON наверх

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

проверяем валидный/невалидный ввод

1) когда не валидно заполнили и нажали submit то onSubmit евент не приходит

ну да, но заполнить можно форму реактивную без хтмл ведь

ну вот весь этот кейс без хтмл можно

типа как юнит

2) когда валидно заполнили и засабмитили то проверяем что onSubmit выполнился и что в нем пришло

если я сам правильно понял

да неважно что у тебя под капотом внутри user-form, template-driven или model-driven form

я бы тестировал все равно как пользователь

отрендерил и прокликал

и это не e2e тест

это unit test

изолированно

в TestBed

как пользователю который заполняет в итоге форму так и разработчику который потом вставляет где-то <user-form> компонент им обоим без разницы какая реализия внутри

главное чтобы API формы работало

для юзера API это форма в браузере с инпутами, для разработчика API это @Input и @Output этого компонента

Подскажите, почему не применяются стили компонента, когда использую ng-content. Пример: style: ul.red li{ background: red; } Компонент <ul class="red"> <ng-content select=[links]></ng-content> </ul> Родитель: <my-nav> <li links *ngFor="let nav of navs">{{nav.title}}</li> </my-nav>

посмотри на скомпилированный код css

Testing Considerations We can write isolated unit tests of validation and control logic in Reactive Forms. Isolated unit tests probe the component class directly, independent of its interactions with its template, the DOM, other dependencies, or Angular itself. Such tests have minimal setup, are quick to write, and easy to maintain. They do not require the Angular TestBed or asynchronous testing practices. That's not possible with Template-driven forms. The template-driven approach relies on Angular to produce the control model and to derive validation rules from the HTML validation attributes. You must use the Angular TestBed to create component test instances, write asynchronous tests, and interact with the DOM.

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

посмотри на скомпилированный код css

если я внутри компонента создам li - она будет красной, а когда Projection li не перекрашиваются

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

все верно, я просто еще раз спрошу, что будет гарантировать твой тест тогда?

если тестишь без дома то ты проверяешь логику формы

и только

это хорошо конечно

хыы

я понял

ну да наверное ))

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