ng-template, ng-content, ng-container, *ngTemplateOutlet, context лайфхаки. Angular 

Хай, с радостью посмотрю. Отличный материал!

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

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

да это про меня из разряда, ничего не понятно но очень интересно;))) но я не сдамся, раз сюда дошел)

Спасибо за отзыв) С ангуларщиками Жизненно)

Полностю поддерживаю. Тоже для познания этого, в частности работы с контекстом, я долго сидел тыкал интуитивно... Это видео тогда бы мне сэкономило минимум несколько часов))

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

Такая же мысль посетила. Очень крутая информация , но ни разу не применял ничего подобного кроме обычной передачи данных от parent -> child. А вот чего не знал так это то что есть директива select ) видимо документацию читал между строк )

Лень :)

Смотрите код готового урока в описании, там есть изменения 😊

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

Вопрос не простой 1) Обязательно нужно делать консистентно - т.е. везде одинаково, все остальное опционально 2) shared модуль допустим если мы делаем маленькое приложение, например микросервисы, но и даже тут я бы не стал делать эту папку - Вместо shared лучше использовать common и туда скидывать общие модули, именно модули, один модуль одна общая фича - А при микросервисах лучше иметь проект libs где будут также общие модули, но тут они уже будут не обязательны к подключению во всех модулях проекта 3) Папки в модулях помогают легча понимать что и для чего используется, но много папок могут затруднить навигацию... Тут нужен баланс. То что нравится мне, но то что сложно реализуется без понимания модульной архитектуры - разбиение на папки по ответственности, guards в своей папке, страицы в своей, юи в своей... Глупые и умные компоненты имеют слишком широкое разделение. Тут глупые я считаю UI елементы, и умные могут быть страницами, могут быть layout (шаблонами страницы), модалки, виджеты (если у нас сложное отображение, не 1 страница = 1 фича)...но суть в том, что нужно четко понимать в какой папке какая логика должна быть, и можно ли чтобы верхний слой перескакивал и подключал другой слой к себе...например страница подключила UI без использования виджета... По разбиению компонентов - всего лишь вершина айсберга. Еще есть специальные компоненты или специальные сервисы и диррективы которые наследуются от ядра какой ни будь фичи...например платежные методы на странице оплаты... Я бы вынес их в отдельную папку payments по какой либо логике...но это уже сложный подход, я его применял в последних видео джедая веб разработки в nestjs проекте P.S. Разбивать на микро модули это правильно и удобно, но требует много конфигураций код становится сложнее на порядок... P.S.S Нужно освоить "не прекращающийся рефакторинг" - это когда часть функционала скрывается за приватными методами и контрактами, а по мере роста приложения переписываются на правильную архитектуру и публичные контракты расширяются... Т.е. можно сделать очень грязную архитектуру, но к которой можно будет получить доступ через один компонент и один сервис...а по мере работы декомпозировать, раскидывать по папкам и тратить деньги клиента на красоту...а пока ничего не понятно, сделать чтобы работало и никому не показывать то что еще сырое

@@grommaks спасибо!

@@diatm1506 P.S. Если модульная архитектура, и есть компонент который не понятно куда положить, но он приватный для модуля, то можно его положить куда угодно, и не экспортить...перед экспортом подумать где он должен быть на самом деле) Если он должен быть публичный, но опять не понятно куда его положить, то можно в модуле добавить index.ts файл который будет импортить компонент и его же экспортить...цель чтобы никто не знал где он лежит в модуле, и потом его можно было перенести куда угодно... (Но index.ts файл я не люблю, он импортит слишком много без явного запроса, но решает описанную мною проблему) Думаю мне нужно раскрыть тему на канале по "непрерывному рефакторингу"

@@grommaks Тоже думал например к auth относятся и login и register подумал не проще сделать rest и к login и register и к каждому сделать отдельные сервисы и dto вместо методов login register в auth servise, а разделить например login findOne когда пользователь вводит пароль и емаил destroy, когда делает logout и тд разделить на CRUD и собрать login, register реэкспортить в auth модуле. Думаю вк досихпор рефакорят и поддерживают и будут до безконечности. Material ui. интересно реализованно хотелось бы тоже попробовать что-то подобное написать для учебных целях их удобно использовать они не привязанны к друг к другу и переиспользуются хорошо. Index.ts barel file я использую но в nest сталкнулся с ошибками что когда использовал 2 сервиса в 1 модуле с index не правильно реэкспортился сервис. Думаю лучше дождусь других видео тк проект растёт, а оперировать сервисами и тд становится сложно и архитектура заходит в тупик( Я даже отказался от typeorm которая предоставляла репозитории в пользу prisma orm там без них можно) Думаю узнаю как правильно использовать сервисы в скором будущем

@@diatm1506 Серебряных пуль не завезли в очередной раз. Имхо, всё упирается в понятность и простоту поддержки кода. В 2 разных случаях один и тот же код может быть и допустимым, и вообще "его дробить давно нужно". Принцип SRP зависит сильно от задачи, которую код вынужден делать. Если известно, что он усложняется, добавляются вариации, то тогда мб есть смысл его дробить. Я лично против сильного дробления кода

Года два наверно, я с бекенда перешёл на ангулар, а на ангулар не все проекты были…так что в если усреднить то можно считать 2 года

@@grommaks круто 🤙, я просто случайно наткнулся на данный ролик по Angular JS решил посмотреть , пишу на Angular Dart :0

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

Этот выпуск около 15-20 минут) содержательный, но будет ещё один выпуск вместе с жизненным циклом компонента на 20 минут по той же теме, но ещё интереснее 🤠

@@grommaks Супер, з нетерпінням очікую!!

На данный момент нет, и ближайшим временем не предвидится

Прикольное решение) мне нравится) Достаточно гибкое, когда буду директивы показывать, там чуть чище можно сделать... И в видео о AfterContentInit Я покажу как можно было массивом шаблоны передавать...чтобы надежнее было :)

Коммент это самое вдохновляющее, ещё нравится обратная связь, я готовлю офлайн курс исходя из полученного опыта в этих плейлистах, так что любая критика и рекомендации помогут)

@@grommaks хочу навчатись у вас офлайн теж!

@@KvN-UA якби не війна, був би курс, а так поки планую повертатися у ютуб