Comments 28
Оптимизирующий сборщик – это, конечно, хорошо, но не особо помогает, когда фреймворк по своему дизайну требует много писанины. Вот app.module.ts из статьи:
import { BrowserModule } from '@angular/platform-browser';
import { NgModule } from '@angular/core';
import { ReactiveFormsModule } from '@angular/forms';
import { HttpClient } from '@angular/common/http';
import { AppComponent } from './app.component';
import { UserComponent } from './components/user/user.component';
import { ErrorComponent } from './components/error/error.component';
import { GithubService } from './services/github.service';
@NgModule({
declarations: [AppComponent, UserComponent, ErrorComponent],
imports: [BrowserModule, ReactiveFormsModule, HttpClient],
providers: [GithubService],
bootstrap: [AppComponent]
})
export class AppModule {}Весь этот код попадает в конечный бандл и смысл этого не очень понятен.
Но целью этой статьи было показать, что он пригоден для быстрого написания небольших приложений и у него есть свои плюсы.
В частности четкое разделение ответственности, масштабируемость и строгая типизация.
А лишние 100кб бандла в наше время не самая большая проблема. ИМХО
Сейчас часто любят манипулировать размерами библиотек с учетом сжатия.
C min+gzip. Ядро angular занимает примерно 60Кб.
Собранное приложение.
Но его релиз должен решить проблему с размерами бандла.
А что уникального есть у Angular, что он стоит дополнительных килобайт в бандле?
— роутинга,
— http,
— работа с формами,
— подключен RxJs для удобства работы с ассинхронными операциями.
Есть стайлгайд в котором описано чем должны заниматься сервисы, пайпы и компоненты.
Все это от одной команды разработчиков.
Все это разворачивается одной коммандой.
ng new my-appПовторюсь еще раз, что целью является не доказательство того, что Angular меньше, а то что у Angular есть другие достоинства и на нем можно быстро писать небольшие приложения которые ничем (кроме лишних 40кб gzip) не уступают React, Vue и др.
Повторюсь еще раз, что целью является не доказательство того, что Angular меньше, а то что у Angular есть другие достоинства и на нем можно быстро писать небольшие приложения которые ничем (кроме лишних 40кб gzip) не уступают React, Vue и др.
Хорошая попытка, но ИМХО не очень удачная. Для больших приложения все это имеет смысл, но показать достоинства для быстрого написания небольших приложений, я думаю все же не получилось.
Однако, все равно спасибо за статью! Ждем ответ с Vue ))))))
Хорошая попытка, но ИМХО не очень удачная. Для больших приложения все это имеет смысл, но показать достоинства для быстрого написания небольших приложений, я думаю все же не получилось.
Почему, кода много? Так оно все автоматически генерируется при помощи команд для cli.
Перенося это с метафор на разработку. Если у вашего мини-приложения или стартапа большие амбиции и перспективы роста, то стоит взглянуть на Angular, т.к. он даст много плюсов в перспективе.
В противном случае есть более подходящие инструменты.
Поймите меня правильно, я считаю, что Angular — это прекрасный инструмент для крупных и очень крупных проектов, особенно энтерпрайза. Особенно, если большая часть команды пришла из типизированных языков с классическим ООП, типа Java/C# и т.п. Такая команда будет действительно чувствовать себя как рыба в воде, используя Angular. Я считаю, что на сегодняшний день, это сугубо его ниша и ни React, ни Vue и уж тем более Svelte, не дотягивают до нее. Сколькими бы redux'ами не обмазались.
React и Vue довольно хороши в проектах средних и чуть больших. У них обширная инфраструктура и тулинг. Svelte же хорош в небольших и средних проектах, особенно требовательных к производительности и размеру. Наверное, я бы не стал писать на нем крупный проект. Однако какие-то отдельные компоненты, требовательные к перформансу, можно реализовать на Svelte и бесшовно использовать и в большом проекте. Благо, он это позволяет делать, так как не имеет рантайма.
В общем, пусть у каждого будет своя нише, в которой он хорош, а у нас с вами будет большой выбор)))
А у меня сплошные разочарование от предложений ангуляра по архитектуре. После некоторого опыта возникло ощущение, что купил только этикетку. Если убрать из стандартного набора модули роутера и http, то ангуляр мало чем отличатся от того же react или vue.
Под этикеткой я понимаю сразу несколько вещей: консольная утилита, монорепозитории, генераторы, тесты и все это тебе достается из коробки, и это конечно все круто, и экономит время, но к архитектуре относится слишком косвенно.
Еще под этикеткой скрывается длинный стайл-гайд, где примерно половина состоит из воды и половина из соглашений по именованию и по длине/типу отступов. Они пишут про некие принципы, типа LITF, или про буквы из SOLID, это то, что я назвал водой, практические советы, по этим принципам, вовсе сводятся к тому чтобы ограничить количество строк кода в функциях/файлах или количество файлов в папочках, это уже какой-то бред идеологический. Но немного про архитектуру там все же отметил.
В подавляющем большинстве от ангуляра используются компоненты, сервисы и модули. Модуль это структурный объект. Компонент тоже имеет сильно ограниченную зону ответственности. Для всего остального есть сервис, молоток для всех задач. С помощью декораторов, конечно можно использовать все что угодно, тут нет ограничений, но и архитектурные решения в этом случае полностью перекладываются.
В стайл-гайде советуют разбивать код по семантическому признаку, например в один модуль можно объединить компонент списка комментариев, компонент комментария, сервис для загрузки/отправки и уникальные зависимости, или можно список комментариев вместе со списком постов вынести отдельно, в общем случае как взбредет. Если зависимость используется для нескольких семантических модулей, то ее следует вынести в общий модуль. И в случае необходимости, например процесса инициализации для всего проекта, предлагается сделать модуль ядра приложения. Возможно я что-то упустил, но это основные моменты, что у меня отложилось касательно предложений по архитектуре. Соглашения по именованию, по стилю и следование различным принципам, это конечно хорошо и нужно, но с этим справляются и линтеры. А советы по архитектуре, что я смог выделить, будут сносно работать, например, для библиотеки компонентов, желательно изолированных.
Буквально самые основные моменты.
HttpClient не особо отличается от банального fetch. А для банальных REST запросов, предлагается сделать сервис, и на каждую букву из CRUD написать метод. Положить этот файлик нужно либо в модуль подходящий по семантике, либо в общий модуль. Такое решение, даже для их официального туториала, плохо подходит. Клиент-серверное взаимодействие очень типовая задача. В гайде про это пара слов.
Еще для меня типовой является задача построением лайаутов, страницами, их компоновкой, привязкой к роутеру и т. д. Обычно хочется отделить это от компонентов. В целом, для всего этого есть инструменты, но согласованное предложение по организации кода явно было бы не лишним.
Работать с состоянием приложения предлагается, понятно, через сервисы и rxjs. Тут я даже не удивлен, что redux для ангуляр набирает популярность.
Модуль, куда они предлагают выносить все общие части приложения, я убежден, что уже на этапе создания папки, превращается в технический долг. Если в команде 5+ программистов, то уследить за тем что там происходит, будет очень сложно.
В итоге надо либо искать готовые решения, либо создавать свои, уже на самых ранних этапах разработки, и все это без рекомендаций со стороны разработчиков. Даже бэкбон в свое время, гораздо яснее отвечал на большее количество вопросов, касательно архитектуры.
Из опыта: мы с коллегой, независимо, примерно в одно время, разрабатывали с нуля два разных внутренних проекта, на этом ангуляре, это был условно наш первый опыт работы на нем. В плане архитектуры, сейчас это два абсолютно разных проекта.
Я не понимаю, зачем писать лишний код там, где это не имеет никакого смысла. Есть определение модуля:
@NgModule({
declarations: [AppComponent, UserComponent, ErrorComponent],
imports: [BrowserModule, ReactiveFormsModule, HttpClient],
providers: [GithubService],
bootstrap: [AppComponent]
})
export class AppModule {}Здесь создается пустой класс лишь для того чтобы было куда навесить декоратор. Зачем так сделано, почему нельзя было сделать NgModule просто функцией? Создается лишний вес в бандле на ровном месте.
Зачем модули нужны в принципе, я понимаю. Вопрос был про их громоздкий синтаксис. Есть ли ситуации когда класс AppModule оказывается не пустым? А если он всегда пустой, то зачем он вообще нужен?
Например, в момент подключения модуля, как минимум, вызывается конструктор, в нем можно проверить текущее окружение и подстроиться под него. Или, например, в RouterModule содержатся статические методы, которые на основе параметров формируют декларацию подключаемого модуля. Но причины применения декоратора, на пустой класс я вижу немного в другом.
Мета-программирование в ангуляре является частью общей концепции. Исключительно на основе мета-данных, фреймворк связывает части приложения. В коде ангуляровских стандартных и сторонних библиотек — модули, компоненты, сервисы и т. д. используют декораторы для мета-описания, так как это единственный способ обеспечения связей. Совокупность всех декораторов образует вполне конкретный интерфейс и единый механизм описания связей. Как результат, любые связи в приложении можно конфигурировать практически без ограничений, например, одной строчкой в мета-описании модуля, можно подменить сервис в ядре фреймворка и в этом нет ничего криминального.
Понятно, что сами по себе декораторы, это лишь синтаксический сахар, и код что за ними скрывается, может иметь множество алтернатив. Но помимо решения технической задачи, декораторы формируют способ взаимодействия пользовательского кода и фреймворка, формируют один из базовых принципов. Я думаю, пустой класс модуля, допустимый компромисс, но согласен, что выглядит это коряво.
Но целью этой статьи было показать, что он пригоден для быстрого написания небольших приложений и у него есть свои плюсы.
Боюсь, вы лишь показали, что это не так. Слишком много кода для такой простой задачи. Пожалуй, я бы не рекомендовал Angular для средних и небольших приложений.
В частности четкое разделение ответственности, масштабируемость и строгая типизация.
Все, кроме строго типизации, это вопросы архитектуры, а не фреймворка. Да и типизация там от TS, который напрямую с Angular как бы не связан. Кроме того строгая типизация — это штука на любителя и опять же редко приносит реальную пользу на небольших и средних проектах.
А лишние 100кб бандла в наше время не самая большая проблема. ИМХО
Пожалуй это не так.
Все, кроме строго типизации, это вопросы архитектуры, а не фреймворка. Да и типизация там от TS, который напрямую с Angular как бы не связан. Кроме того строгая типизация — это штука на любителя и опять же редко приносит реальную пользу на небольших и средних проектах.
Имел в виду, что Angular предоставляет готовые архитектурные решения, и если вы пришли с одного angular проекта на другой, то они скорей всего будут похожи. И там не будет очень плохого кода.
К примеру в моей практике был случай когда по наследству перешел проект на нативном JS в котором был один файл на 9000 строк и метод render более 500 и единственным возможным решением в этом аду было вставление очередного if/else. И все это выросло из «маленького проекта в котором не нужна архитектура».
Поэтому если вы пишите TODO-app, то Angular действительно не для вас, а если это стартап который предположительно разростется до большого приложения, то стоит задуматься.
Типизация в Angular благодаря TS, но сам Angular написан на TS поэтому большинство приложений тоже написаны на TS.
Боюсь, вы лишь показали, что это не так. Слишком много кода для такой простой задачи. Пожалуй, я бы не рекомендовал Angular для средних и небольших приложений.
бОльшая часть этого кода это каркас сгенерированный angular-cli. А код написаный разработчиком это: верстка 3х компонентов и запрос на сервер, и подписка на изменение инпута.
Как сделать поиск пользователей по Github используя Angular