И хотелось бы спросить про paths, когда работаем с nx. Меня вот очень раздражает увеличенное количество '../../' в каждом проекте (импорты внутри самого проекта), т.к. абсолютные пути настраиваются только для импорта из других проектов. И настройка удалась только при указании абсолютного импорта в tsconfig.base, но eslint от nx не рекоммендует использовать абсолютные пути вот таким образом. в видео тоже упомянуто (прим 9 минута), что не оч круто между фичами использовать абсолютные пути. но у меня кейс с nx, что думаете об этом? Можно ли настроить абсолютные пути, глушить eslint от nx или смириться с паровозом ../../ во внутренном импорте каждого проекта?
Влияет ли импорт из index.ts, когда мы работаем с lazy loading modules? может ли в lazy module импортироваться так же ненужные нам файлы, тем самым увеличивая размер бандла?
Я раньше относился к импортам тоже как к такому месту, где совсем неважно как оно там всё подрубается, главное как я по итогу - всё делаю ПОД СЕКЦИЕЙ импортов. Но, конечно же - импорты, тоже часть нашего приложения и нужно и за ними "ухаживать" и держать в порядке =)
Так проектируйте нормально структуру, что бы не надо было три уровня вверх херачить, что это за такой компонент так глубоко зарыт в который надо сервис и интерфейс пробросить. Разве на таком уровне не должен лежать какой то абсолютно тупой компонент? Я если открою проект и пойму что мне сразу не видно откуда сервис приходит а там будут вот такие ебаные алиасы я его закрою и попрошу сделать нормально. Програмисты те еще лицемеры. Как можно в одном видео базарить за архитектуры проектирования, конвенции, коментирование кода, что бы сделать поддержку и разработку проекта не вами а кем то другим удобнее, и тут же, а давайте ебанем алиасы на пути к компонентам приложения. И еще знаете как можно все короче сделать, скормить какому то минифаеру аглификатору сырцы, вообще все будет коротким, и места занимать не будет.
Не очень понимаю, о каком лицемерии идет речь. В случае с видеороликом, есть глобальная папка features, которая содержит разные бизнес сущности. Каждая из сущностей содержит набор: глупых компонентов, сервисов, интерфейсов и т.д. Всё это как бы "шаренное". Ну а в абсолютно ином месте, описываются страницы. Например. имеем такую структуру: app/features/user/... app/pages/users/list/table/table.component.ts Где второй путь - путь ко странице со списком пользователей на умный компонент таблицы, который является оберткой над глупым компонентом таблицы и точно знает что ему делать в ответ на Outputs от глупого компонента, какие сервисы инжектить и т.д. Как можно заметить, компонент "table" находится довольно глубоко, а иерархия выглядит, на мой взгляд, логично. Чтобы не выходить на множество уровней наверх, мы делаем Path Alias на нашу глобальную папку "features" и теперь можем удобно, будто "из npm пакета" импортировать набор необходимых нам зависимостей из конкретных сущностей. Уточни, что не так тебе видится в этом подходе. Спасибо)
Может быть можешь подсказать как решить проблему когда добавила алиасы, такую как core.mjs:6531 ERROR TypeError: Cannot read properties of undefined (reading 'ɵcmp') at getComponentDef (core.mjs:2529:12) at extractDirectiveDef (core.mjs:2418:12) at core.mjs:2592:21 at Array.map () at core.mjs:2592:10 at createTView (core.mjs:11394:63) at getOrCreateComponentTView (core.mjs:11343:28) at createRootComponentView (core.mjs:15966:49) at ComponentFactory.create (core.mjs:15845:39) at ViewContainerRef2.createComponent (core.mjs:16265:47)
![СТЕЙТ МЕНЕДЖМЕНТ [ANGULAR]](http://i.ytimg.com/vi/1jq2oH-st3U/mqdefault.jpg)
![СТЕЙТ МЕНЕДЖМЕНТ [ANGULAR]](/img/tr.png)
![ControlValueAccessor - КАК РАБОТАЕТ [ANGULAR] - GUIDE](http://i.ytimg.com/vi/5xxMBOE3LNs/mqdefault.jpg)
![ATEEZ(에이티즈) - [GOLDEN HOUR : Part.2] Preview](http://i.ytimg.com/vi/X4PfgRPBUVo/mqdefault.jpg)
Дзякуй вялікі! Вельмі карысны фільмік!
Хорошая информация. Делись пожалуйста побольше хорошими практиками и подходами)
дякую розробникам, які одразу дають зрозуміти, що вони з України :D
Супер, очень полезная инфа, буду узать так)).
Оч полезное видео! Буду использовать
И хотелось бы спросить про paths, когда работаем с nx. Меня вот очень раздражает увеличенное количество '../../' в каждом проекте (импорты внутри самого проекта), т.к. абсолютные пути настраиваются только для импорта из других проектов. И настройка удалась только при указании абсолютного импорта в tsconfig.base, но eslint от nx не рекоммендует использовать абсолютные пути вот таким образом.
в видео тоже упомянуто (прим 9 минута), что не оч круто между фичами использовать абсолютные пути. но у меня кейс с nx, что думаете об этом? Можно ли настроить абсолютные пути, глушить eslint от nx или смириться с паровозом ../../ во внутренном импорте каждого проекта?
Влияет ли импорт из index.ts, когда мы работаем с lazy loading modules? может ли в lazy module импортироваться так же ненужные нам файлы, тем самым увеличивая размер бандла?
фу фу фу ;) правила, сущности, избегание. @ совсем не ок ../../../../../ = вот классика. Ну в целом мне webStorm всегда тянет я туда не лезу :)
Я раньше относился к импортам тоже как к такому месту, где совсем неважно как оно там всё подрубается, главное как я по итогу - всё делаю ПОД СЕКЦИЕЙ импортов.
Но, конечно же - импорты, тоже часть нашего приложения и нужно и за ними "ухаживать" и держать в порядке =)
Так проектируйте нормально структуру, что бы не надо было три уровня вверх херачить, что это за такой компонент так глубоко зарыт в который надо сервис и интерфейс пробросить. Разве на таком уровне не должен лежать какой то абсолютно тупой компонент? Я если открою проект и пойму что мне сразу не видно откуда сервис приходит а там будут вот такие ебаные алиасы я его закрою и попрошу сделать нормально.
Програмисты те еще лицемеры.
Как можно в одном видео базарить за архитектуры проектирования, конвенции, коментирование кода, что бы сделать поддержку и разработку проекта не вами а кем то другим удобнее, и тут же, а давайте ебанем алиасы на пути к компонентам приложения.
И еще знаете как можно все короче сделать, скормить какому то минифаеру аглификатору сырцы, вообще все будет коротким, и места занимать не будет.
Не очень понимаю, о каком лицемерии идет речь.
В случае с видеороликом, есть глобальная папка features, которая содержит разные бизнес сущности. Каждая из сущностей содержит набор: глупых компонентов, сервисов, интерфейсов и т.д. Всё это как бы "шаренное".
Ну а в абсолютно ином месте, описываются страницы. Например. имеем такую структуру:
app/features/user/...
app/pages/users/list/table/table.component.ts
Где второй путь - путь ко странице со списком пользователей на умный компонент таблицы, который является оберткой над глупым компонентом таблицы и точно знает что ему делать в ответ на Outputs от глупого компонента, какие сервисы инжектить и т.д.
Как можно заметить, компонент "table" находится довольно глубоко, а иерархия выглядит, на мой взгляд, логично.
Чтобы не выходить на множество уровней наверх, мы делаем Path Alias на нашу глобальную папку "features" и теперь можем удобно, будто "из npm пакета" импортировать набор необходимых нам зависимостей из конкретных сущностей.
Уточни, что не так тебе видится в этом подходе. Спасибо)
Pedor, попробуйте почитать про уровни абстракции в приложении, возможно постарайтесь понять книгу чистая архитектура
Может быть можешь подсказать как решить проблему когда добавила алиасы, такую как core.mjs:6531 ERROR TypeError: Cannot read properties of undefined (reading 'ɵcmp')
at getComponentDef (core.mjs:2529:12)
at extractDirectiveDef (core.mjs:2418:12)
at core.mjs:2592:21
at Array.map ()
at core.mjs:2592:10
at createTView (core.mjs:11394:63)
at getOrCreateComponentTView (core.mjs:11343:28)
at createRootComponentView (core.mjs:15966:49)
at ComponentFactory.create (core.mjs:15845:39)
at ViewContainerRef2.createComponent (core.mjs:16265:47)
Если у тебя тот компонент который = undefined становиться,то скорее всего ты находишься в состоянии циклической зависимости компонентов
@@kostik706 можно проверить по команде, циклических зависимостей нет