Комментарии 31
Вычитывайте статью перед публикацией.
Расширяйте код при помощи прототипизирвоания
Использовать monent.js для обработки дат внутри сервисов.
устарел же. https://momentjs.com/docs/#/-project-status/
Тем более, что есть: https://www.npmjs.com/package/mol_time_all
1.9 Пользуйтесь покомпонентами Angular Material.
После того, что они учудили при переходе с v14 на v15, начинаешь сомневаться.
0.1.1 Ограничение на длину метода: 150 строк.
Многовато как-то. На ангуляре не писал, но обычно свыше 10-20 строк уже стоит задуматься.
Я бы предпочел 50 строк метод нежели измученые 10 вызовов методов ради "качества" кода. Если код требует объёма и нет явных моментов выноса логики, то не надо плодить методы.
50 еще норм, я не топлю за дробление на однострочные методы.
Смысла спорить нет. Нужно разбирать каждый кейс отдельно.
Но я к тому, что сомневаюсь, что метод в 150 строк может соответствовать базовым правилам SOLID, что его адекватно можно покрыть тестами, поддерживать. И сколько новому человеку понадобиться времени чтобы в нем разобраться.
Конечно, есть исключения.
В основном банальные советы, местами очень спорные. Почему это ngrx очень желателен? Без него прекрасно можно жить. Почему использовать material? Каждый раз как с ним столкнусь испытываю ужасную неприязнь. Насчёт использовать lodash вообще молчу, это вообще не имеет отношения к ангуляру, и не является хорошим советом, ибо очень сильно не всегда нужен
Поддержу про NgRx, все эти стейты притянутые из мира Redux далеко не всегда нужны и очень не всегда несут пользу в Angular. Сейчас выпиливаем как раз остатки поделия в виде Mobx, который принес больше боли, чем пользы.
Страшно даже подумать в ползу чего вы его выпиливаете.
Не в пользу, а в корзину... RxJS более чем достаточно для большинства даже вполне тяжелых проектов.
Ок, вот вам простая задачка: у вас есть коллекция из 40к задач. В каждой задаче 20 полей. На одной из сотен страниц выводится 10 списков задач, отфильтрованных отсортированных и сгруппированных по разным полям самим пользователем. 30 раз в секунду вам прилетает событие изменения одного поля одной задачи. Как вы на RxJS реализуете это всё так, чтобы не было адских тормозов из-за ререндера всего приложения 30 раз в секунду?
Я бы взял $mol, чтобы после моего ухода никто бы не смог разобраться в коде!
Всё идет от задач, если вы знаете как это работает под капотом, то для вас не будет никаких проблем это сделать штатными средствами. Всё в Angular по факту базируется на Observable, даже по факту те же сигналы работают на их базе, просто являются сахаром. С любым сахаром придется решать те же проблемы, он легко решает одну проблему и параллельно тихо создает ещё несколько.
То есть вы не знаете как решить эту простую задачку на RxJS?
Вам чё проект надо создать? Рабочие часы оплатите? Если не умеете работать с потоками и проектировать данные, то пользуйте то, что делает это за вас, вам же никто не запрещает
Спасибо, я уже создал. А вам стоит либо сбавить спесь, либо не пороть чушь.
А вот кто бы говорил кстати. Если в моем проекте мне надо забивать гвозди, зачем мне слушать вас с вашими надуманными кейсами и использовать микроскоп для этого? Нет универсальных инструментов.
Вполне реальный кейс: https://www.wrike.com/features/dashboards/
Нет универсальных инструментов.
Докажите.
Вместо хамства можете объяснить в чем сложность этой конкретной задачи и что помешало решить её обычным RxJs? В задаче не вижу ничего принципиально сложного, разве что поля надо у задачи надо сделать Observable, которые стреляют при обновлении - ну это довольно тривиальный кейс если хотя бы немного работали с Angular.
Так на всякий случай, в реализации ангуляровских сигналов нет ни капли Observable
Статья же про ангуляр, поэтому оценка в рамках ангуляра
Много спорных пунктов, и очень уж устарелой информации
"Ограничение на длину метода: 150 строк." - это очень много, до 50 строк максимум, и даже 50 уже прочитать сложно
"Пользуйтесь покомпонентами Angular Material." - Много UI библиотек и Material не лучшая из них
"Роуты отдельного модуля в RouterModule.forChild" - С standalone компонентами это немного неактуально
"Структура модуля" - Чаще всего эти папочки избыточны
"NgRx - желателен (очень)." - Сомнительный совет, куча бойлерплейта и потраченого времени
"API должно быть гибким." - Api чего? Если для работы с бекендом, то это зависит от бекенда
"Данные должны быть разделены на чанки." - Что тут имеется ввиду? Данные приходят с бекенда, и как сделали апи, в таком виде данные и придут
"Расширяйте код при помощи прототипизирвоания" - В Ангуляре? Как вы это видите?
"Использовать monent.js " - Даже разработчики уже не рекомендуют его использовать
"Использовать JSDoc" - Коментарии нужны только там где сложно прочитать написаный код, писать коментарии ради коментариев очень плохой совет
Расширяйте код при помощи прототипизирвоания
Это больше черта Реакта, а не Ангуляра. Как раз таки это в целом не angular way.
Правила хорошего тона на Angular