Comments 16
Спасибо! Статья будет очень полезна многим, и не только начинающим. Один момент только не освещен на мой взгляд, а где лучше хранить модели для данных из полученных из api с бэкенда? И где хранить сервисы api? Особенно это бкдет актуально для ленивых модулей. Спасибо!
UFO just landed and posted this here
По моему мнению, интерфейсы лучше хранить отдельно в каждом модуле.
Во-первых, убирается лишняя зависимость.
Во-вторых, в модулях появляется необходимость добавить\изменить интерфейс и делать это лучше не выходя за рамки модуля.
Буду рад, если приведёте примеры интерфейсов, которые не меняются и могут быть вынесены в shared.
По поводу сервисов, по моему мнению, либо класть сервис в отдельный проект, либо в проект модуля. Но не в shared. Иначе со временем shared превратится в помойку.
Во-первых, убирается лишняя зависимость.
Во-вторых, в модулях появляется необходимость добавить\изменить интерфейс и делать это лучше не выходя за рамки модуля.
Буду рад, если приведёте примеры интерфейсов, которые не меняются и могут быть вынесены в shared.
По поводу сервисов, по моему мнению, либо класть сервис в отдельный проект, либо в проект модуля. Но не в shared. Иначе со временем shared превратится в помойку.
UFO just landed and posted this here
А нужен ли тут один интерфейс?
Например, в списке постов может быть что то типа рейтинга, количества просмотров, автора, даты создания, идентификатора и других полей, которых нет при создании.
В списке в админке могут быть какие то внутренние поля, типа флага, что пост скрыт или время отложенной публикации.
При создании может быть например, капча.
Понятно, что к примерам можно придраться, но смысл понятен.
В общем это явно должны быть разные интерфейсы. У них может быть общий родительский, но, как по мне, это тоже лишнее.
Например, в списке постов может быть что то типа рейтинга, количества просмотров, автора, даты создания, идентификатора и других полей, которых нет при создании.
В списке в админке могут быть какие то внутренние поля, типа флага, что пост скрыт или время отложенной публикации.
При создании может быть например, капча.
Понятно, что к примерам можно придраться, но смысл понятен.
В общем это явно должны быть разные интерфейсы. У них может быть общий родительский, но, как по мне, это тоже лишнее.
UFO just landed and posted this here
Помимо комплита (по мне, так этого уже достаточно) ещё навскидку:
Теперь подскажите, в чём преимущества одного интерфейса?
- Уверенность, что я не пытаюсь получить свойство, которое в данном конкретном случае не используется \ не нужно \ отсутствует (компилятор во многих случаях поругается, в том числе в шаблонах)
- Поддержка кода, когда я вижу, что реально есть в интерфейсе в данном конкретном случае
- При создании объекта нет необходимости заполнять лишние поля. Если конечно вы не делаете все их опциональными
- Буква I из SOLID, в конце концов
Теперь подскажите, в чём преимущества одного интерфейса?
UFO just landed and posted this here
тем, что если я добавлю или поменяю поле на бекенде — мне надо будет обновить один инерфейс, а не 10
Где нужно будет — там и поменяете, а не везде. Ваш один аргумент перевешивает мои 5 или нет?
У меня есть интерфейс для post и я во всем приложении могу быть уверен, что использую нужный мне post и мне не надо думать какой интерфейс использовать
Если на бэке добавится поле, то оно всё равно автоматически не выведется в шаблон нигде. Так или иначе менять придётся фронт. А вдруг новое поле нужно только в одном модуле?
Сколько полей будет в этом интерфейсе? Все возможные? И на фронте нужно их постоянно заполнять будет, даже если для списка мне нужен, например, только заголовок?
UFO just landed and posted this here
если для списка нужен только заголовок — то и бек будет возвращать только заголовок и для этого будет отдельный интерфейс
Ну я уж утрировал пример. Для списка нужны ещё поля, конечно.
Вы очень выборочно на вопросы отвечаете.
Повторюсь и дополню
1. Что если новое поле нужно только в одном модуле, а не везде?
2. Фронт автоматически не обновится сам при добавлении поля, всё равно фронт менять надо, что по этому поводу думаете?
3. Сколько полей будет в этом интерфейсе? Все возможные? Наступит ли момент, когда придётся бить интерфейс на несколько?
4. Что по поводу SOLID, про interface segregation?
5. Являются ли поля объекта опциональными или их все ининциализировать каждый раз нужно?
Понятно, что на создание поста у меня будет другой интерфейс
Но в любом случае будет общий интерфейс, потому-что есть страницы редактирования, просмотра и создания
Противоречие
UFO just landed and posted this here
Ок, спасибо за ответы, но я как раз против того, чтоб гонять данные лишние, и иметь моноинтерфейс.
Один интерфейс приводит к тому, что либо часть данных в некоторых случаях отсутствует и непонятно из сигнатуры метода когда и какая.
Либо данные всегда есть, даже ненужные, и, даже если их не выводить, они приводят к увеличению объёма передаваемых данных и к потенциальным утечкам данных
Вашу точку зрения по поводу думать головой разделяю, на этом можно и закончить
Все сервисы работы с api делаются providedIn: 'root', ангуляр сам распределяет их по модулям в зависимости от того, как они будут использоваться.
Если любите модели в отдельном файле, то делать на каждый апи-сервис отдельную папку, где лежит сам сервис и его модели. Я предпочитаю описывать модель в самом сервисе. Ну и один ендпойнт — один сервис.
Если любите модели в отдельном файле, то делать на каждый апи-сервис отдельную папку, где лежит сам сервис и его модели. Я предпочитаю описывать модель в самом сервисе. Ну и один ендпойнт — один сервис.
К содержанию статьи вопросов не имею, но словил себя на мысли, что Angular повернул куда-то не туда.
Слишком много абстракций над тем, что нам даёт браузер
Слишком много абстракций над тем, что нам даёт браузер
Sign up to leave a comment.
Подходы к управлению модулями в Angular (и не только)