Блин, я думал там всё просто, видимо @angular/router как-то с компилятором сам взаимодействует, что только через его loadChildren: () => .... это работает.

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

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

Ась?

мимо проходил, ответил что знаю

Почему вдруг забыть про него (AOT)?

А как вам такое? Так оно заработало.

Если переиминовать loadChildren то тоже работает.

мы в js мире тут живем, и сравнивать тип обьекта который с рандомного места прилетел - это история не про жэс ниразу, instanceof - это когда в рамках своего софта (один билд), если тянешь чет со стороны то там уже kind обычно юзает, но если у тебя получилось проверить, я за тебя рад)

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

и почему локальный класс с таким же именем это не тот же бинарь

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

В смысле прокатит или не прокатит? Ты же angular lazy loading пользуешся? Это кусок кода оттуда
https://github.com/angular/angular/blob/master/packages/router/src/router_config_loader.ts#L52

не пользуюсь, я еще лайзи не грузил левый жэс

Ого

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

Скажите: какой вариант или варианты сброса не годятся или годятся ВСЕ или ВСЕ не годятся ??

*С фронта мы передаём в эндпоинт бэка чистый пароль вместе с токеном подтверждения на сброс в эндпоинт бэка, а бэк его обрабатывает. Если токен плохой, то бэк отклоняет запись нового пароля в таблицу БД с соответствующим пользователем.

*С фронта мы передаём хешированный пароль вместе с токеном подтверждения на сброс, а бэк его обрабатывает. Если токен плохой и хэш битый( имеет не верный формат), то бэк отклоняет запись нового пароля в таблицу БД с соответствующим пользователем.


*Хранить хеш пароля в jwt и передавать в эндпоинт только jwt. Если токен плохой, то ничего не делать, если норм: проверять: есть в нём айди и хеш, если нет, ошибка. Если всё ок, то только тогда сохранить пароль из jwt в БД пользователей
какой вариант для вас будет более безопасным и приемлемым из этих вариантов ?? Если никакой, то тогда можете предложить свой ??

*Хранить хеш пароля отдельно от jwt и в jwt хранить от него только соль и передавать ещё пароль как второй параметр. Если в jwt не та соль или он не валидный или пользователя такого нет по айди субъекта и пароль по соли не совпадает с входным хешем пароля, то отклонить сброс, иначе принять этот хеш как новый пароль.

А цель какая?

ну хэшировать на клиенте точно не надо

сбросить пароль

Ну ничего из этого не обеспечивает безопасность, просто пытаюсь понять от чего ты пытаешься защититься?