П
Всем привет!
А покидайте пж подходы к построению архитектуры для больших приложений.
А покидайте пж подходы к построению архитектуры для больших приложений.
Разделяй по фичам и заворачивай в модуль
Size: a a a
2019 December 25
AV
Разделяй по фичам и заворачивай в модуль
так и делаю
П
так и делаю
Тогда всё норм
AV
может есть что-то еще лучше
П
Ну ещё обычно есть core модуль и шаред
П
В коре то без чего аппа не аппа, типа меню или 404 страница
В шаред компоненты, который в разных модулях используются, типа адрес или ввод телефона
В шаред компоненты, который в разных модулях используются, типа адрес или ввод телефона
П
А так я хз что ответить. Вопрос слишком общий
E
В коре то без чего аппа не аппа, типа меню или 404 страница
В шаред компоненты, который в разных модулях используются, типа адрес или ввод телефона
В шаред компоненты, который в разных модулях используются, типа адрес или ввод телефона
А как же Сервисы?
П
А как же Сервисы?
Что сервисы?
E
Куда их помещать?
П
Аналогично. Есть общие сервисы, есть сервисы, которые нужны тока в конкретном модуле
П
Иногда я делаю тока в компоненте провайдера, но то довольно редкий случай
С
Народ, насколько хорошая практика наследования допустим классов компонентов? Допустим есть один главный компонент в приложении, без темплейта, но в нем определенны такие сервисы как вывод ошибок на экран, роутинг, методы парсинга дат, строк и тому подобное. После чего, каждый новый компонент в приложении начинает его наследовать.
S
Народ, насколько хорошая практика наследования допустим классов компонентов? Допустим есть один главный компонент в приложении, без темплейта, но в нем определенны такие сервисы как вывод ошибок на экран, роутинг, методы парсинга дат, строк и тому подобное. После чего, каждый новый компонент в приложении начинает его наследовать.
плохо
S
очень плохо
С
плохо
А можно подробнее, почему?
С
Вроде ж меньше кода пишешь в каждом компоненте
Вキ
И пару слов про наследование не абстрактых классов. Так делать никогда не стоит. И есть простая методика, как можно без наследования реализации расширять реализацию. Такой способ называется делегирование, тут можно почитать подробнее:
https://refactoring.guru/ru/design-patterns/proxy
Вот тут есть небольшой пример:
https://github.com/angular/angular/blob/master/packages/platform-browser/animations/src/animation_renderer.ts#L131
BaseAnimationRenderer реализует Renderer2, и приэтом в конструкторе он тоже принимает Renderer2.
Вот тут он делегирует вызов метода в Renderer2, и в engine:
https://github.com/angular/angular/blob/master/packages/platform-browser/animations/src/animation_renderer.ts#L154-L157
https://refactoring.guru/ru/design-patterns/proxy
Вот тут есть небольшой пример:
https://github.com/angular/angular/blob/master/packages/platform-browser/animations/src/animation_renderer.ts#L131
BaseAnimationRenderer реализует Renderer2, и приэтом в конструкторе он тоже принимает Renderer2.
Вот тут он делегирует вызов метода в Renderer2, и в engine:
https://github.com/angular/angular/blob/master/packages/platform-browser/animations/src/animation_renderer.ts#L154-L157
@stepan_ua вот тут и чуть выше я писал об этом недавно
С
@stepan_ua вот тут и чуть выше я писал об этом недавно
Почитав на рефакторинге, из минусов увеличение время отклика сервисов
С
Насколько это значительно в js?