В своей статье я хочу поделиться с вами опытом использования нового Angular как основы для наших enterprise приложений. Речи о том, что новый Angular лучше, чем React, Vue или какая-то другая популярная сейчас библиотека, в статье не пойдет, хотя, конечно, я буду сравнивать его с конкурентами. Все решения имеют свои плюсы и минусы, и то, что хорошо подошло одному проекту, может устроить сущий ад в другом. Итак, прежде чем объяснить, чем нас зацепил новый Аngular, расскажу немного о том, что мы уже используем в разработке.
Наш основной проект имеет долгий путь развития и построен на уже устаревших технологиях — Marionette + Backbone + Coffescript. Пару лет назад мы поняли, что развивать проект в таком стеке стало довольно тяжело, и начали изучать альтернативы в экосистеме фронтенда и думать, как же нам мигрировать туда нашего «зверя».
Начиная работу над проектом, мы выбрали популярный сейчас стек React + Redux + [Reselect, Redux-Saga, Redux-form, etc]. Это была наша первая попытка выбора нового стека и, к сожалению, неудачная — он показался нам не столько удобным, как Marionette много лет назад. В результате исследований около полугода назад наш выбор пал на новый Аngular и мы им довольны. Пока новый Angular не используется на основном проекте компании, но в перспективе мы не видим препятствий для его переноса на это решение (ну разве что нас останавливает огромная кодовая база на Coffeescript). Итак, давайте посмотрим, что же мы нашли в новом Angular и чем он нам понравился.
Пункты будут излагаться в произвольном порядке, а не по степени значимости. Начнем, конечно же, с тех вещей, которые считаем преимуществами решения, а в конце поговорим и про недостатки.
Плюсы
Angular — это фреймворк
Это один из самых важных для нас плюсов. Когда пять лет назад я начинал проект в компании, то думал, что будет легко построить классный и целостный продукт. Как же я был наивен! :) Чем больше народу подключалось в проект, тем больше времени я тратил на приведение целого «зоопарка» решений к общему стилю и архитектуре. Отчасти это было вызвано той свободой, что давал нам Marionette, ведь это был лишь набор примитивов, который никак не ограничивал разработчика.
Все люди разные и каждый будет строить код своего кусочка продукта так как ему нравится. Как я только не боролся с данной проблемой — вводил coding style, ревьювил код, делал описание архитектуры, но все равно периодически сталкивался с нестандартным решением от одного из своих коллег, и приходилось тратить много усилий, чтобы вернуть проект к однотипному развитию и архитектуре.
Потом было время разработки на React и, казалось бы, Redux и Flux пришли мне на помощь. Да, это позволило больше не беспокоиться, что изменение данных моделей будет разбросано по коду, но одна из проблем все же осталась. Мне приходилось следить за всем набором библиотек, которые тащились в продукт. Наш стек просто пестрил своей разнообразностью и подходами.
Потом мы перешли на Angular. Несмотря на всю его гибкость, это все-таки довольно ограничивающий разработчика фреймворк. А так как он содержит в себе довольно много возможностей, то привнесение новой библиотеки в проект стало для нас довольно редким событием, которое было проще контролировать. Наличие же стандарта кодирования, предоставляемого командой Angular, позволило мне окончательно выдохнуть и расслабится, и больше времени уделять разработке.
Конечно, в Angular все равно можно устроить хаос, но это сделать гораздо сложнее, так как неверно построенный код тут же всплывает либо при оценке производительности, либо при попытках его переиспользовать. Я был бы рад наличию более жесткого фреймворка, но, боюсь, тогда бы мы потеряли возможность его расширения, а мне бы этого не хотелось. Как мне кажется, в Angular мы нашли золотую середину — это и не позволяющий все Marionette, но и не жесткий Extjs.
Наличие cli системы
Это, конечно, далеко не killer-фича ангуляра, да и у React тоже есть свой cli (react-starter-kit), но тем не менее, начать изучение нового решения гораздо проще, используя консольный клиент, а не тратя часы на выбор boilerplate и поиск причин почему что-то не работает. Кроме этого, у консольного клиента есть огромный плюс в том, что он сразу генерирует минимальный шаблон приложения, позволяет легко запускать код как в режиме разработки или в production, так и запускать тесты.
Все это, безусловно, снижает порог входа и позволяет сразу начать писать бизнес-код, не раздумывая (до определенного момента) о расположении файлов или о написании "скелета" приложения. Также надо отдать должное ребятам из Angular — их консольный клиент построен поверх клиента emberjs. Когда-то давно я сталкивался с ember и был приятно удивлен удобством их консольного клиента, правда, это было единственное преимущество ember, отмеченное мной на тот момент.
Typescript
Когда Typescript только появился, мы не понимали его предназначение и считали, что проверка типов — это все «от лукавого» и у нас не так много дефектов связано с неверной передачей данных. Со временем мы изменили мнение и даже попытались внедрить в готовый проект на React пакет flow, но после недели мучений сдались и решили, что сможем жить и без него.
Затем обратили внимание на Angular, который полностью написан на Typescript, и подумали, а почему бы не попробовать поработать с ним снова. Первое, что мы оценили после перехода на Typescript, это возможность легкого использования es6 без ненужной возни с настройками babel и других транспилеров (и уверенность, что очередное обновление не сломает вам сборку кода). Вы просто пишете код, а компилятор без проблем преобразует их в es5.
Но больше всего нас порадовало то, что писать код в IDE стало намного удобнее и приятнее — правильно работает автодополнение, можно посмотреть документацию метода, не покидая контекста кода, код стал самодокументированным. Нам больше не надо было описывать в комментариях, что за объект мы передаем в метод, это обеспечивал за нас Typescript.
Чуть позднее мы оценили всю прелесть интерфейсов и декораторов. Да, конечно, можно писать на Typescript, используя React, поэтому это не уникальный плюс для Angular, но, когда сам фреймворк написан на Typescript — это дает вам бесшовную интеграцию вашего кода.
Компонентный подход
Почти все текущие решения используют парадигму компонентного подхода и Angular не первый, кто предлагает такое решение. Но если сравнивать подход Angular с подходами других решений, есть ряд отличий:
Вы можете не только создавать новые теги для html-разметки, но и изменять существующие. Далеко не всегда при использовании React нам удавалось сделать чистую разметку без лишних html-элементов в иерархии и это ужасно раздражало нашего верстальщика. В Angular же вы можете изменить поведение существующего html-тега через атрибут, и это делает нашу разметку чище и приятнее.
Вы можете вынести верстку в отдельный файл. В нашей компании JS-разработчики не очень любят верстать html, поэтому у нас есть верстальщик. Когда он занимался версткой React-кода без знания JS и es6, для него это было сродни хождению по минному полю. Я знаю, что в React есть возможность вынести разметку, но когда ваш код генерируется множеством JS-функций, это не так-то просто. Оказалось, что проще объяснить верстальщику на какие вещи ему не надо обращать внимание (речь о директивах, конечно же), чем научить его JS. Использование Pipe позволило нам скрыть от верстальщика всю сложную магию обработки данных, оставив только небольшое вкрапление директив.
Вы можете настраивать поведения компонента, меняя параметры работы Change Detector или работы компонента с CSS-классами. Причем при наследовании от базовых компонентов все ваши настройки сохранятся. Таким образом, можно одним параметром включить работу change detector в режим сравнения immmutable-объектов, и при наследовании от такого базового компонента избежать лишних циклов change detector механизма. Конечно, это требует от разработчика понимания, что он делает, когда наследуется от базового класса. Инкапсуляция стилей позволила нам избежать мучений с выбором названия для очередного класса selected внутри одного из многих компонентов.
- Можно указать какие параметры могут приходить компоненту на вход и какие события могут от него исходить. После этого, при попытке передать лишний параметр на вход компонента, компилятор даст вам знать, что компонент ничего не знает о таком параметре. Это помогает избежать ошибок при использовании чужих компонентов. Конечно, в React есть PropTypes, которые также позволяют контролировать то, что попадает на вход вашего компонента, так что Angular тут не уникален.
RxJS
Angular построен поверх библиотеки RxJS и странно было не использовать её. Но когда мы первый раз столкнулись с этой библиотекой, то пришли в ужас. Нам потребовалось несколько дней, чтобы понять, как правильно написать цепочку обработки наших данных. В результате получился код, который может прочитать только тот, кто хоть раз пробовал что-то писать на этой библиотеке. Нас настолько это пугало, что мы даже подумывали отказаться от использования RxJS.
Прошло немного времени, мы несколько раз перечитали документацию, попробовали библиотеку в действии и привыкли. Библиотека RxJS позволяет мне творить очень крутые вещи с обработкой данных и почти всегда мой код работает так, как я и задумал. Правда, даже сейчас, по прошествии полугода я понимаю, что не знаю полностью всей мощи этой библиотеки. Но зато я понимаю, что вряд ли откажусь от её использования.
Конечно, RxJs можно встроить и в React, но, повторюсь, когда ваш фреймворк использует то же, что и вы, можно легко связывать свой код с фреймворком, например, используя HTTP-модуль Angular для работы с backend’ом.
Dependency Injection
Надо начать с того, что Dependency Injection используется Angular почти везде, значит, это дает возможность изменять поведение фреймворка в очень больших границах: можно вклиниваться в определенные процессы работы, например, сконструировать роуты на старте продукта, можно полностью заменять некоторые части продукта своими.
Кроме этого, DI в Angular настолько гибкий, что позволяет реализовывать на нем многие хорошо известные паттерны, такие как Singleton, Factory, Facade и т.д. Мы используем DI повсеместно, начиная от взаимодействия компонентов, заканчивая созданием сервисов для показа модальных окон или нотификаций пользователю. И конечно, вся работа с backend’ом построена через сервисы и DI.
Я не являюсь приверженцем redux-подхода, так как имею негативный опыт работы с ним – (в одном из проектов я устал от огромного количества шаблонного кода, нередко больших redux saga обработчиках и тормозящих reselect геттеров). Возможно, мы его неправильно использовали, но как мне кажется, дело было не в этом. Мы встраивали весь этот стек в готовый проект с его интерфейсами, а не строили новый, затачивая работу с backend’ом для удобной укладки всего в стейт и side-effect обработчики.
Но вернемся к Angular. Если у вас нет необходимости в redux-подходе, но вы хотите иметь так называемый «single state of true», то можете использовать сервисы, RxJS-компоненты и Uniderectial data flow, поддерживаемый в Angular. Код получится гораздо компактнее и будет не хуже redux-подхода. Со временем вы сможете трансформировать его и в redux-подход, почти не меняя код. Как будет выглядеть такая архитектура в конце, можно посмотреть тут.
Модули
Впервые с модулями я познакомился в Marionettejs и это было безумно удобно. Я разбивал модуль на множество файлов — контроллеры отдельно, вьюхи отдельно и т.д. А после Marionette собирал за меня все вместе.
Занимаясь разработкой проекта на React, я часто вспоминал про модули, но из коробки React ничего похожего не предлагает, а искать или реализовывать что-то подобное не было времени. Angular же, напротив, дает вам понятие модуля с самого начала. И они здорово упрощают совместную работу с кодовой базой. Вы просто собираете все кусочки вашего бизнес-компонента в модуль, и для его использования другим разработчиком, достаточно просто добавить в код ваш модуль.
Так как модули имеют собственное пространство имен для компонентов, вы можете не беспокоиться о том, что ваши «внутренности» будут доступны кому-то во внешнем коде. Это отличный слой абстракции от остального кода. И конечно, у вас есть возможность экспортировать нужные компоненты наружу, чтобы их могли использовать другие разработчики.
Кроме этого, модули — отличный инструмент для документирования кода. Конечно, есть особенности использования модулей и о них надо знать. Первая особенность заключается в том, что сервисы, определенные в модуле, доступны всему приложению, и надо быть аккуратней с именованием этих сервисов. Angular предлагает решение в виде использования аналога Symbol типа из нового стандарта JS, чтобы избежать коллизий.
Вторая особенность скрыта в lazy load-модулях и заключается в том, что сервисы, подгружаемые из таких модулей, доступны только внутри модуля. Это довольно неприятная особенность, которая заставила нас искать обходное решение, так как наш продукт построен по плагинной системе и нам необходим беспрепятственный доступ к сервисам. Эту особенность мы исключили благодаря ранней предзагрузке сервисов на старте приложения.
Развитие фреймворка и его поддержка
Angular, в отличие от React, развивается всего одним мейтенером, гуглом, и для нас это имеет важное значение. Из нашего опыта работы с React, развитием стека которого, по сути, занимается комьюнити, мы пару раз попадались на том, что выбранные библиотеки переставали поддерживаться или имели очень низкий темп исправления дефектов, а это тормозило нашу разработку.
Пару раз нам приходилось менять одни библиотеки на другие, и много раз нам приходилось форкать библиотеки и вносить свои правки. Да, мы не застрахованы от подобного и с Angular, но тут сторонних библиотек у нас гораздо меньше в силу того, что фреймворк содержит многое в себе. Что же касается дефектов именно в самом Angular, то при острой необходимости, можно воспользоваться платной поддержкой от команды Angular, которая поможет решить проблему или найти другое решение. Но, конечно, на это придется потратить немного бюджета.
Это далеко не все плюсы, которые есть в Angular, а только те, которые показались нам важными. Кроме этого, в Angular есть возможность перевести код в WebWorker-ы, что сделает его многопоточным, Server Side Rendering и многое другое. Сейчас у нас нет необходимости в этих возможностях, но приятно что если они нам понадобятся, то мы в любой момент сможем ими воспользоваться, не сильно меняя свой код.
Минусы
Как и любое другое решение, Angular далеко не идеальный продукт и, конечно же, содержит минусы.
Довольно посредственная документация
Документация есть, но её качество оставляет желать лучшего. Нередко открыв документацию, видно просто название методов класса, без какого-либо описания, что они делают и как. Даже если описание будет присутствовать, то не всегда без живого примера можно понять, как использовать тот или иной метод.
Кто пробовал создавать компоненты в Angular динамически, меня поймут. Некоторые вещи просто отсутствуют в документации, и приходится лезть в код, чтобы понять, как достигнуть цели. Но я думаю, со временем данная проблема уйдет, и ребята допишут документацию.
Большой объем результирующего кода
Если использовать Angular из коробки, то на выходе мы получаем здоровенные модули, от которых наступает тоска и печаль. Но если немного покопаться в документации, то можно найти ряд решений, которые существенно уменьшат размер кода на выходе. И тут есть несколько подходов:
Исключить те модули, которые не используете. Например, если не используете анимацию, которую предлагает Angular, или формы, то не нужно и тащить эти пакеты с собой. Также можно использовать tree-shaking при сборке проекта, что исключит из кода неиспользуемые части. Например, это сильно уменьшит размер RxJS, который вы включаете в production код.
Использовать AOT-компиляцию, что исключит runtime-компилятор из вашего кода, а он немало весит. Правда, это возможно только если не генерировать компоненты динамически, как это делаем мы. Но, даже в этом случае, компилятор можно вынести в отдельный модуль и загружать его отдельно.
- Использовать Lazy loading-модули. Роутер Angular умеет работать с lazy loading-модулями из коробки и даже позволяет выбрать стратегию загрузки модулей или написать свою. По умолчанию модули грузятся только при первом обращении к ним, но можно задать подгрузку модулей в бэкграунде, что ускорит переход в подгружаемые модулями разделы.
Для нас данный минус не особо критичен, так как наше приложение релизится раз в полгода, огромной нагрузки на него нет, и нас спасет браузерный кэш. И мы не предполагаем, что его кто-то станет использовать с мобильных девайсов, для этого лучше сделать отдельное native-приложение.
Сложный порог входа
Angular очень сложный фреймворк. С одной стороны, используя cli, можно легко начать на нем писать код, но, с другой стороны, не изучив документацию, к примеру, как работает change detector, можно написать очень неоптимальный код или даже неработающий вовсе.
Мы тоже не обошли стороной данный минус и довольно много времени убили на попытки понять, почему сервис из lazy load-модуля не виден в другом модуле. Кроме самой сложности Angular, много времени у нас отняла библиотека RxJs, в которой не так просто разобраться, но оно того стоит.
Заключение
Исходя из сказанного, мы пришли к выводу, что Angular стал действительно корпоративным фреймворком, на котором можно не бояться строить большие приложения. В основном это произошло благодаря осмыслению опыта с первой версией Angular, цепочки правильно принятых решений, например, выбор RxJs и Typescript, а также целостности сделанного решения.
React же для нас — это сборник хороших идей, но из-за отсутствия многих функций из коробки, зачастую каждый лепит из него своего «монстра» из возможностей, предоставляемых сообществом. В итоге время вхождения нового разработчика в сложный проект куда большее, чем у Angular, а нередко проблемы возникают даже у соседних команд. Но, повторюсь, это сугубо наше мнение, выведенное из нашего опыта и созданных проектов. Выбирая Angular, нам важна скорость нашей разработки и то, насколько быстро наши разработчики смогут вносить изменения в код, двигая продукт вперед.
Комментарии (92)
VolCh
05.05.2017 10:54+1Постоянно идёт сравнение Ангуляра с Реактом, хотя первый пункт "Ангуляр — это фреймворк", а, как известно, Реакт — нет :)
Грубая настройка babel ничуть не сложнее typescript, а иногда лучше их настраивать цепочкой, потому как тонко настроить target компилятор typescript не может, аналогия babel с пресетами, но без возможности брать или добавлять только отдельные плагины, если целевые браузеры лишь чуть-чуть не дотягивают до используемых в исходниках фич.
А про модули не понял. Речь про import/export или что-то другое?
KyKyPy3uK
05.05.2017 12:35+3От сравнений мне было не уйти, иначе не всегда можно донести в чем же плюс. Но я старался делать это как можно мягче, дабы не обидеть сторонников другого решения :)
Согласен, что babel не такой уж и страшный зверь и у меня в принципе нет проблем с его настройкой, но не могу этого сказать про некоторых своих коллег. А мне надо было сделать так чтобы процесс сборки совсем не отнимал наше время. И да, конечно код получаемый babel в некоторых местах будет лучше и быстрее, но для нас это не так важно.
Модули в Angular очень похожи на стандартные es6 модули, но имеют некоторые отличия. Так например модуль это сущность для компилятора ангуляр, а значит можно использовать его конструктор как init метод (мы в нем например инжектируем локализацию в продукт). Во вторых вы помещаете весь роутинг вашего модуля внутрь модуля и это очень удобно. Также можно поступить и с сервисами для DI. Ну и наконец, если сравнить в React, то тут с учетом специфика ангуляра, просто добавив модуль вы можете легко использовать все компоненты экспортируемые модулем и вам не надо делать деструктинг компонентов из модуля для jsx.
RubaXa
05.05.2017 11:49+6и привыкли
So cute ;]
P.S. За статью спасибо, читается легко, ну и всегда приятно читать чужой опыт.
klerick
05.05.2017 12:20+1До этого оооень долго использовал первую версию AngularJs, знал все его минусы и плюсы. Затем был полугодовалый опыть использования второй версии Angular, понравился, стал проще. Теперь вот работаю с ReactJs. И я как-то даже разочерован, столько было про него сказано, а в итоге.
haiflive
05.05.2017 12:40+1как там сейчас со временем сборки проекта?
а то после того как angular наконец-то релизнулся, меня жутко раздражала долгая сборка проекта, при малейшем изменении на пустом проекте приходилось ждать по 8-10 секунд… да там есть прекопиляция но она как-то криво была сделана.
что сейчас не расскажите, ну или как вы решили эту проблему?KyKyPy3uK
05.05.2017 13:05Мы уже ушли от cli ангуляра и переписали весь процесс сборки для поддержки плагинной системы. Холодный старт, при учете что vendor у нас вынесен в dll, у нас занимает около 30 секунд. При изменении пересборка по прежнему идет около 6-8 секунд. В целом для нас 8 секунд не критично и наверно поигравшись с Webpack можно ускорить процесс.
PFight77
05.05.2017 21:29Если совсем надоест, можете посмотреть мой велосипед. Я, правда, так и не нашел времени довести до ума (там есть ветка dev и npm пакет), но если будет интересно, можно развить тему.
medvedmike
05.05.2017 12:55+2Наконец-то статья о том, что кто-то выбрал Angular! Столько статей про React последнее время… Как любителю Angular становилось грустно, спасибо за статью!
justboris
05.05.2017 14:30+3Статья актуальна на начало 2016 года.
Сейчас май 2017 и информация немного поменялась.
У React появился cli — create-react-app.
C 16 версии React избавится от необходимости оборачивающих тегов. Компоненты смогут возвращать массив тегов, html станет проще.
Вопрос про многообразие Flux-ов тоже уже закрыт. Если нравится функциональный код — берете Redux, если хотите классических объектов — MobX.
А насколько я знаю про выход Angular 4, то все минусы из статьи по-прежнему на месте. Документация сложная, объем кода, загружаемого в браузер, огромный.
KyKyPy3uK
05.05.2017 15:01+1Начну с минусов. Если сравнивать размер ангуляра на начало 2016 года и сейчас, то он довольно сильно похудел. И если раньше размер получаемого кода у меня вызывал панику, то сейчас уже я вижу, что у мня есть ряд возможностей для уменьшения размера (о них написано в статье). Да и команда гугла продолжает заниматься уменьшение размера получаемого бандла. Минус документации тоже устраняется потихоньку, так например текущий спринт команды гугла направлен как раз на улучшения сайта и документации. Но так как для нас это не критичные минусы, то я особо не слежу за этой темой. Возможно для кого-то это stop-проблема и им лучше выбрать Vue.
Теперь насчет актуальности статьи. Про cli React я писал что он есть, правда указал немного другой. Насчет 16 версии React — я такой в production не вижу, а значит для меня ее нет. Точнее я конечно же читал про нее, в особенности про их fiber-ы, но уж простите, политика Компании и клиенты обязывают не юзать то, что официально не вышло. Но как я писал это не поможет нам, так как верстальщик у нас не знает JS.
По поводу Redux — да я его не люблю, и не из-за многообразия Flux решений, отнюдь. А не люблю я его из-за огромного кол-ва шаблонного кода, нередко монструозных side effect обработчиков и тормозящих геттеров из стейта (через reselect). У меня до сих пор есть довольно крупный проект на Redux и я каждый раз с неохотой что-то вношу в него. Похожий подход на angular у меня получился в разы компактнее и понятнее. Но это моя субъективная оценка и мой опыт и если кому-то Redux позволяет сделать красивый, простой и поддерживаемый код, я с удовольствием почитаю об этом на Хабре :)
alexbaum
09.05.2017 13:11тормозящих геттеров из стейта (через reselect)
Возможно, тормозит неоптимально написанный геттер — сам сталкивался с такой проблемой, когда плохо декомпозировал Селекторы и не работала мемоизация.
Идея в том, что при повторном вызове селектора с неизменившимися параметрами результат будет выдан из кеша без повторного вычисления.
justboris
05.05.2017 14:34Ну и насчет того, что за Angular стоит гугл это тоже не все так просто. Двое основных разработчиков уволились из Google и теперь зарабатывают деньги на обучении других Ангуляру.
https://blog.nrwl.io/introducing-narwhal-technologies-nrwl-5e192b887413
astec
05.05.2017 16:24И в чём проблема? Я думаю у Гугла нет проблем с наймом хороших разработчиков.
Ребята придумали как зарабатывать больше денег. Молодцы. Но с точки зрения большой компании никакой трагедии нет.
Вы так написали как будто то что из за того что они зарабатывают на Ангуляре вне Гугл у Гугл выручка уменьшится. Прям ужос-ужос.
VolCh
05.05.2017 16:35+1Не в выручке дело, а в том как Ангуляр будет развиваться без основных разработчиков
astec
05.05.2017 20:57С их бюджетом я думаю у них нет проблем с привлечением и заменой основных разработчиков.
justboris
05.05.2017 22:07+2Найти новых людей не проблема.
Дело в том, что делать фреймворк — это не то же самое что продукт. Это больше как рок-группа. Ушел гитарист, взяли другого, играет нормально, а звучание все равно не то.
Вот и здесь есть шансы, что люди, пришедшие на замену, повернут развитие Ангуляра в другую сторону.
x07
05.05.2017 14:51Трудно согласится с тем, что на сегодняшний день, порог вхождения в Angular большой. Раньше когда не было документации и стабильной версии, да — разобраться было трудно.
Для реакта, конечно больше материалов, причем русскоязычных, наверное поэтому он является самой популярной библиотекой для фронтенд.glestwid
10.05.2017 15:19+3Трудно согласится с тем, что на сегодняшний день, порог вхождения в Angular большой.
Ага, т.е. когда мне вместо внятного указания ошибки в моем коде в произвольно взятом с codeproject примере выдается вот такая херня — это небольшой порог вхождения?bromzh
10.05.2017 18:24Так это даже не проблема ангуляра, у вас же сервер вместо js/json отдаёт html, и js-парсер ломается на первом же
"<". Но тут такое дело: чтобы писать на том же ангуляре, нужно ещё знать всякие сопутствующие вещи, вроде настройки сборщиков, компиляторов и т.д. Да, это порой трудно, но за такие знания и платят очень неплохо.
Но в любом случае, для облегчения всей этой возни с конфигами есть всякие cli, и у реакта, и у ангуляра. Вы пробовали их использовать? Или пройти туториал на оф. сайте?senglory
12.05.2017 20:48Проходил туториал. А толку — он про то, что проект я собираю в студии, ни ухом ни рылом. Второе — он также ни ухом ни рылом про то, что на codeproject проект был под RC4, а компонента, которую я добавил, рассчитана на RC5 (и хоть бы написала при сборке что, мол, твой ангуляр старый, мне нужен RC5 минимум). Ну и вишенкой на торте то, что в туториале ни слова про то, что компонент этот надо подключать теперь через forRoot(), а не напрямую, как десяток других, задействованых в этом балагане.
Вот такая история. И вопрос у меня ровно один — почему все занимаются изобретательством всякой херни типа Angular уже 4, React и прочие Knockout и никто при этом еще не сделал никакой внятной системы диагности при сборке этого непотребства? Сообщения типа того, что на скриншоте, я ловил пачками и на React, и еще на каких-то поделиях.
snrostov
05.05.2017 15:28Правда, это возможно только если не генерировать компоненты динамически, как это делаем мы.
Вы генерируете исходный код шаблонов и компилируете его в рантайме?
Спрашиваю т.к. у нас возникает похожая задача: компоновать компоненты в рантайме. Но она в итоге решилась без компилятора. API по инстанцированию компонентов в рантайме полностью покрывает нашу задачу.
Есть возможность по подробнее рассказать про вашу задачу и решение?
KyKyPy3uK
05.05.2017 15:32+1У нас сложнее. Наш продукт использует плагинную систему. При старте продукта мы загружаем все известные нам плагины и кладем их в кеш SystemJS. Для показа какого-то компонента мы сначала компилируем модуль через compileModuleAndAllComponentsAsync, потом находим в нем нужную фабрику используя имя компонента, а потом уже создаем его и добавляем в DOM.
Возможно если будет время на праздниках напишу статью по всем возможным способам создания компонентов в angular и какие там есть проблемы.snrostov
05.05.2017 15:42+1Возможно если будет время на праздниках напишу статью по всем возможным способам создания компонентов в angular и какие там есть проблемы.
Это было бы очень круто
При старте продукта мы загружаем все известные нам плагины и кладем их в кеш SystemJS.
Ну а плагины не получится скомпилировать заранее и класть в кэш уже скомпилированные фабирки компонентов?
И кстате, почему SystemJS а не web pack?
KyKyPy3uK
05.05.2017 16:02SystemJS нам нужен так как WebPack статически анализирует код и не умеет грузить что-то, о чем он не знал на этапе компиляции. Мы же предполагаем, что наши партнеры могу написать свой плагин к нашей системе и зарегистрировать его у нас через UI. После этого мы на старте будем грузить его с бекэнда и вставлять компоненты из него в GUI.
snrostov
05.05.2017 16:16+1Ок, про SystemJS в таком случае понятно. Но почему же все таки не получается компилировать эти самые сторонние модули не в браузере, а заранее, или даже не лету, но на сервере?
KyKyPy3uK
05.05.2017 16:58А как? Для нас это просто JS файл, в котором собрано все что надо плагину — модули, локализация, ресурсы и прочее. И собираем его в бандл не мы, а сторонняя компания. Если бы мы рендерили все на сервере, то тогда можно было бы не тащить компилятор.
snrostov
05.05.2017 18:27Хороший вопрос. Идея есть, но требует проверки. С ts точно проблем нет, а вот по поводу js есть сомнения что его получится открытым api скомпилировать. Но используя внутренний api — совершенно точно можно.
Попробую на праздниках поэкспериментировать.
DenimTornado
05.05.2017 15:34А Ember не смотрели? Там есть всё, что вы хотели и давно + сообщество и документации получше. Из коробки там нет TS, это правда.
dustik
05.05.2017 15:42Мы с другом делаем вдвоем свой проект и столкнулись со следующим:
Написали свой проект на Angular2(django backend, по сути просто как прослойка для REST), запустили альфа версию (на своем личном мощном сервере) и ужаснулись — на мобильных устройствах с android и ios, в браузере chrom, DOM собирался 35000 миллисекунд, да вы не ослышались 35 секунд!
Есть же universal, не унывали мы, и начали писать дальше, в итоге в декабре 2016 года, мы поняли, что для того чтобы запустить наш проект, мы создаем инфраструктуру для инфраструктуры и еще потратим примерно пару месяцев, чтоб все настроить. У нас уже были задействованы: Django, Angular2, nginx, universal, nodejs.
В итоге, волевым решением, все было переписано на Django за две недели. Конечно, так быстро мы все переписали благодаря тому, что в Angular2 все очень круто со структурированием кода, автор об этом как раз таки пишет. Сейчас наш проект использует Django, nginx, VanillaJS. подумываем частично использовать React. Сейчас наш проект на мобиле открывается за 2000 миллисекунд.
Какой вывод: Angular2 крут, но как нам кажется это технология для больших команд, у которых есть ресурсы, чтобы запустить проект в обозримое время.VolCh
05.05.2017 15:48DOM собирался 35000 миллисекунд, да вы не ослышались 35 секунд!
Это сколько нод или элементов в доме?
dustik
05.05.2017 15:57+1Сейчас уточнил у коллеги, он говорит что было что-то порядка 300.
А изменения в дом дерево новый ангуляр вводит очень быстроastec
05.05.2017 16:28Ну возможно что то делали не так?
У меня минимизированная версия Ionic приложения собранная с --prod грузится около 3х секунд.
dustik
05.05.2017 16:48Вот эти чуваки, тоже что-то делают не так:
https://www.youtube.com/watch?v=TCj_oC3m6_U
Если бы все было так просто, universal не нужен был бы, логично?
MOTORIST
05.05.2017 17:24Я не знаю что там чуваки делают, но у меня приложение каждый день используют, уже как пол года. На 35 сек. никто не жаловался. Даже на планшетах за 2500 руб. android 4.4 приложение открывается быстрее 35 сек. Повторюсь ionic 2 намного тяжелее angular 2.
Вы обжимаете перед выкладкой? Если выкладывать как есть, то 35 сек. будет.
astec
05.05.2017 21:01https://debtstracker.io/ — с ленивой загрузкой на компе 2009 года грузится 2 секунды по 4G. Нет особого дискомфорта от скорости загрузки.
На мобиле с локальной файловой системы примерно такие же цифры, но там ещё Cordova грузится.
Так что какие-то надуманные или более не актуальные проблемы.
MOTORIST
05.05.2017 16:42+1Не верю. Писал на ionic 2. Выводил 700 элементов. Да подтупливает на несколько секунд, но не 35с.
Arta
08.05.2017 00:25у вас не настроена AoT компиляция и все шаблоны компилятся JiT в браузере при каждом открытии?
jankovsky
05.05.2017 16:49+1Размер игры doom2 в архиве — 6,8 мегабайт. Размер загружаемого кода js в dev-версии Angular2 ~7 мегабайт. Отличная штука.
KyKyPy3uK
05.05.2017 16:54Ну мы сейчас все же не во времена doom2 живем. Да и вопрос с размером все же решаем
justboris
05.05.2017 17:15Открыл ссылку, а там:
Disclaimer: This article explains a research which uses experimental tools tools which WILL change in near future. Do not use anything described here in production.
То есть, фактически, нормального решения пока нет?
KyKyPy3uK
05.05.2017 17:27Это было экспериментально на момент написания статьи, сейчас это уже вполне нормальное решение. И это не единственное решение, просто лень искать более честные методы.
justboris
05.05.2017 17:39Тикет о поддержке closure compiler — закрыт 3 дня назад. И это нормальное стабильное решение?
Репозиторий с примером кода — требует Brotli. То есть вместо джентельменского сравнения полученного кода нужно применять читы в виде более агрессивного сжатия, чтобы получить адекватные цифры?snrostov
05.05.2017 18:24То есть вместо джентельменского сравнения полученного кода нужно применять читы в виде более агрессивного сжатия, чтобы получить адекватные цифры?
В README.md же даны честные цифры с gz — 36kb.
Brotli добавлен для демонстрации и отключается коментированием двух строчек вот тут https://github.com/alexeagle/closure-compiler-angular-bundling/blob/master/size_report.sh#L18
Тикет о поддержке closure compiler — закрыт 3 дня назад. И это нормальное стабильное решение?
Конкретно closure compiler — для очень искушенных пользователей. Далеко не все зависимости совместимы с advanced режимом closure compiler.
А вот связка rollup и uglify работала изначально: https://angular.io/docs/ts/latest/cookbook/aot-compiler.html#!#run-rollup. Причем от релиза к релизу они исправляют код ангулара как раз таким образом чтобы минификаторы сжимали его больше.
Кстате в версии 4, код который генерирует aot сам по себе стал на 60% меньше (правда в ущерб его производительности). И было заявлено что helloworld в несколько десятков Кб — это один из приоритетов для следующих релизов.
jankovsky
05.05.2017 17:50+5Так в doom2 была музыка, спрайты и куча куча всего! А в angular2 даже музыки нет.
astec
05.05.2017 21:08В моём приложении для учёта долгов на Ionic/Angular основной модуль 289KB gzip — вполне приемлемо за предоставляемый функционал.
Заявлено что в дальнейшем только лучше будет.
pilot911
05.05.2017 18:14Пробовал второй ангуляр — удобная разработка благодаря Typescript, хорошая документация, если читаете по английски. Но тонкие моменты освещены недостаточно широко.
Например, создание динамических компонентов, их вставка в кастомные элементы таба. Так же недостаточно информации о повторном использовании созданных компонентов для текущего роутера, у которого меняется только переменная часть типа :id.
К сожалению, не пересоздавать компоненты при переходах между разными роутерами пока невозможно.astec
05.05.2017 21:17Насколько я помню на GitHub в комментариях к issue на это тему были примеры как можно реализовать сохранение компонентов.
Не это: https://github.com/angular/angular/issues/5275#issuecomment-291757819pilot911
05.05.2017 21:38спасибо за ссылку, видел её… как раз для случая, когда роутер и компонент теже
меняется лишь динамическая часть URL
здесь вместо создания нового объекта компонента используется старый объект с новыми значениями внутренних полей — роутер-то остается старым, хоть и меняется URL…
а вот когда URL новый и связан с другим роутером и компонентом — тогда предыдущий разрушается
vintage
05.05.2017 23:21Прошу меня извинить, но тут всё так по пунктам разложено, что я не смог удержаться и не сравнить с тем фреймворком, что разрабатываем мы :-)
Начиная работу над проектом, мы выбрали популярный сейчас стек React + Redux + [Reselect, Redux-Saga, Redux-form, etc].
Нет ничего хуже, чем выбирать инструмент не по его практичности, а по популярности. Популярность приходит и уходит. Поэтому выбирать надо такой инструмент, который даже без популярности позволяет эффективно развивать проект, не превращая его в болото, в котором никто не может разобраться. Этим "популярный сейчас стек" и плох — он требует больших объёмов копипасты ради сомнительных целей.
Angular — это фреймворк
Стоит отметить, что Ангуляр — это низкоуровневый фреймворк. Он предоставляет архитектуру и набор инфраструктурных библиотек, но не предоставляет готовых решений. Выливается это в те же проблемы, что и с React&Co — в проект тянутся компоненты из разных источников, написанные как правило кое-как. Или велосипедятся свои компоненты даже для базовых вещей (кнопки там, формочки, графики и пр). Поэтому, разрабатывая свой фреймворк, мы сразу задались целю создать стандартную библиотеку компонент, идеально совместимых друг с другом, и которую комьюнити сможет улучшать легко и просто. Достигается это следующим образом:
- Все компоненты сразу выкачиваются в проект в отдельную директорию, при желании разработчик может их тут же изменить и закоммитить, предложив в дальнейшем пул-реквест.
- Все компоненты очень маленькие и решают свою конкретную задачу. Это упрощает их разработку, поддержку и просто исследование, показывает разработчикам "хорошие практики" и позволяет легко компоновать их с другими компонентами.
- Ничто не мешает разработчикам создавать свои наборы компонент и распространять их наравне с фреймворком. Достаточно воспользоваться сторонним компонентом в своём коде и он автоматически будет скачан и включён бандл.
в Angular все равно можно устроить хаос, но это сделать гораздо сложнее
Это хороший принцип. Фреймворк должен побуждать разработчика к хорошим практикам и препятствовать применению плохих. В соответствии с ним мы навязываем следующие идеи:
- Именование должно соответствовать расположению. По имени модуля всегда понятно где лежит его код. Это естественным образом гарантирует уникальность имён всех модулей и позволяет сборщику понимать какие файлы включать бандл просто по факту использования описанных в них модулей.
- У каждого компонента должно быть уникальное имя в рамках владельца. Это имя используется для стилизации и для динамического формирования интерфейса.
- Стилизация по БЭМ. Соответствующие атрибуты генерируются автоматически по уникальным именам. Разработчику остаётся лишь написать стили для них.
- Разделение логики (скрипты), структуры (шаблоны) и оформления (стили). Это позволяет программисту и верстальщику не мешать друг другу. Повышает эффективность верстальщика, не требуя от него знания программирования. Позволяет верстальщику вносить изменения в уже работающие компоненты.
Наличие cli системы
Опять же, мы сразу разработали cli, который обеспечивает все необходимые процессы: девелоперский сервер, сборка по требованию, компиляция TS, JS, CSS, шаблоны и прочее в бандлы с отдельными сорсмапами. Примечательная особенность — отсутствие "девелоперского" режима сборки — всегда собирается ровно то, что будет крутиться на проде. Тесты билдятся в отдельный бандл. Сразу билдятся бандлы под разные окружения: нода, веб, кордова.
Холодный старт, при учете что vendor у нас вынесен в dll, у нас занимает около 30 секунд. При изменении пересборка по прежнему идет около 6-8 секунд.
У нас свой реактивный сборщик, который сам отслеживает записимости. Так что при изменении, например, стилей — пересобирается только CSS бандл. А результат парсинга TS файлов кешируется (с автоматической инвалидацией, размеется).
Прогнал сейчас для всей стандартной библиотеки (включая десяток демо приложений и кучу компонент). Холодная сборка CSS, JS бандлов и бандлов с локализацией — 12с. Горячая сборка JS бандла при изменении TS файла — 6c.
Кроме этого, у консольного клиента есть огромный плюс в том, что он сразу генерирует минимальный шаблон приложения
У нас минимальный шаблон приложения — пустая директория, для этого даже не нужен никакой cli. Просто создаётся директория, в неё накидываются файлы и вложенные директории. Любую директорию можно собрать в бандлы. Это позволяет в одной кодовой базе иметь множество приложений и множество отчуждаемых библиотек. Собственно любой модуль можно собрать в независимых бандл, включающий как его, так и все его зависимости. Модуль — это директория с файлами на самых различных языках: стили, скрипты, шаблоны, картинки, тесты и пр.
Typescript
Вы можете не только создавать новые теги для html-разметки, но и изменять существующие.Весь код у нас написан на TS, даже "шаблоны" компилируются в TS со всеми вытекающими. Любой компонент — это обычный TS-класс. При создании своего компонента достаточно просто отнаследоваться от уже существующего и расширить его своим поведением. Причём создать компонент может даже верстальщик в "шаблоне", не написав ни единой строчки скриптов, а потом уже программист может добавить компоненту поведение, не меняя "шаблона".
Вы можете настраивать поведения компонента, меняя параметры работы Change Detector или работы компонента с CSS-классами.
Наши компоненты построены по открытому принципу — у них отсутствует какое-либо приватное апи, что позволяет настраивать их извне как душе угодно, при этом не ломая их, так как взаимодействие с состоянием всегда происходит через реактивные акцессоры. У нас нет никакого change detector, вместо него у нас наиболее эффективная на сегодняшний день реализация Объектного Реактивного Программирования, которая позволяет писать простой, понятный и быстрый код. Ещё один принцип, которым мы руководствовались — написать эффективный код должно быть проще, чем неэффективный.
Можно указать какие параметры могут приходить компоненту на вход и какие события могут от него исходить.
Как уже было сказано, любое свойство у наших компонент — это одновременно и его "параметр", который можно менять при создании. Это своего рода DI. Благодаря этой идее у нас реализуется не просто настройка, но и связывание компонент между собой: односторонние (как в одну, так и в другую сторону) и двусторонние биндинги. Соответственно и событий никаких у нас нет — компонент просто меняет своё локальное свойство, но владелец может его подменить на свою реализацию.
Библиотека RxJS позволяет мне творить очень крутые вещи с обработкой данных и почти всегда мой код работает так, как я и задумал.
Достигается это очень большой ценой. Эффективный код на RxJS — крайне громоздкая штука, в которой легко накосячить. А по умолчанию RxJS работает крайне не эффективно. Сравните, например, два примерно эквивалентных кода на FRP и ORP:
FRP
const Greeting = Is_name_showing .select( is_name_showing => { if( is_name_showing ) { return User_name .map( user_name => { return `Hello, ${ user_name }!` } ) } else { return Rx.Observable.of( 'Hello!' ) } } ) .switch() .distinctUntilChanged() .debounce( 0 )
ORP
greeting() { if( this.is_name_showing() ) { return `Hello, ${ this.user_name() }!` } else { return 'Hello!' } }
когда ваш фреймворк использует то же, что и вы, можно легко связывать свой код с фреймворком, например, используя HTTP-модуль Angular
Наша реализация ОРП позволяет писать даже такой код:
@ $mol_mem() namesakes_message() { const texts = this.texts() const user = this.user() const count = this.namesakes_count( user.name ) return texts.namesakes_message .replace( /\{count\}/g , count ) }
При этом texts будет загружен в параллель с user и count, но count только после загрузки user, так как зависит от него по данным.
Довольно посредственная документация
У нас она, по отзывам, тоже так себе, но это компенсируется нарочно простым и понятным кодом. Тем не менее мы работаем над её улучшением. Для всех компонент у нас уже есть демо страничка. А в скором времени мы планируем добавить к ней "конструктор", который позволит взять любую демку, посмотреть какие там у компонента свойства, какие их значения, засунуть туда что-нибудь своё и даже запрототипировать своё приложение.
Кто пробовал создавать компоненты в Angular динамически, меня поймут.
Использовать AOT-компиляцию, что исключит runtime-компилятор из вашего кода, а он немало весит.У нас компиляция кода происходит строго на сервере и строго в бандлы. Тем не менее все компоненты у нас создаются динамически с помощью фабрик, которыми владеет компонент-владелец. То есть в рантайме перекомпоновывать компоненты можно как угодно: можно ссылку вложить в карточку, можно наоборот, а можно оставить что-то одно.
Если использовать Angular из коробки, то на выходе мы получаем здоровенные модули
Исключить те модули, которые не используете.У нас все модули очень маленькие и включаются в бандл лишь те, что фактически используются, так что размер бандла не зависит от размера библиотеки, а зависит от объёма используемого функционала. Бандлы у нас получаются настолько маленькими, что мы их даже не минифицируем, чтобы не огребать проблем с отладкой и долгой сборкой. Вся стандартная библиотека (включая десяток демо приложений и кучу компонент) у нас сейчас занимает полторы сотни килобайт в зазипованном виде.
Использовать Lazy loading-модули.
Маленькие бандлы у нас грузятся и инициализируются быстро, так что мы просто грузим их целиком при старте приложения и далее оно работает максимально эффективно без лишних запросов к серверу. Ленивая же загрузка модулей приводит к двум хопам: сначала за модулем, а затем за данными, которые он запросит. А если у того модуля ещё и зависимости, то хопов будет пропорционально глубине. Без ленивой загрузки модулей можно сразу показать пользователю страницу, на которую он перешёл, а на ней уже индикатор загрузки данных в тех местах, для которых данных ещё нет.
И мы не предполагаем, что его кто-то станет использовать с мобильных девайсов, для этого лучше сделать отдельное native-приложение.
А мы как раз разрабатываем в расчёте в том числе и на мобильные приложения, поэтому:
- Разрабатываем компоненты так, чтобы они и под большой экран адаптировались и под маленький. Всё на флексах без media-queries, что позволяет адаптироваться столько к размеру экрана, сколько к размеру контейнера.
- Рендерим все компоненты по возможности лениво, стараясь не рендерить то, что пользователь всё-равно не видит. Это позволяет переключаться между страницами крайне быстро.
Сложный порог входа
Мы постарались сделать правила работы как можно более простыми и интуитивными, но некоторые привычки всё же придётся кардинально менять:
- Отказ от HTML в пользу композиции компонент. Верстальщику придётся выучить новый язык (который не сложнее HTML), но оно того стоит — код получается лаконичным, но мощным.
- Перестроение мышление с контроля потока (императивное программирование) на контроль данных (реактивное программирование). Опять же, оно того стоит — архитектура приложения (и не только приложения, по тем же принципам можно строить целые информационные системы) получается гораздо более простой и предсказуемой.
- Опять же TypeScript. Но мы намеренно не вводим сложные конструкции и тучи интерфейсов. Код у нас как правило очень поход на JS, так как мы по максимуму используем автоматическое выведение типов.
А теперь о минусах: всего 50 звёзд на гитхабе. Расходимся, ребята :-)
KyKyPy3uK
05.05.2017 23:37А ссылочку дадите на Ваш чудо фреймворк? А то я больше люблю смотреть в код, чем читать буковки.
vintage
06.05.2017 00:02Чёрт, самое главное-то забыл. Весь маркетинг впустую :-D http://mol.js.org
alsii
10.05.2017 13:06Ошибку в примерах поправьте. Todomvc при выборе фильтров all и active показывает весь список.
p.s. там последний параметр в запросе стоит /completed, а надо /completed=false :-)
mayorovp
06.05.2017 07:04Верстальщику придётся выучить новый язык (который не сложнее HTML), но оно того стоит — код получается лаконичным, но мощным.
Вот это — истинный убийца вашего чудо-фреймворка.
vintage
06.05.2017 10:48Нельзя повысить эффективность, не меня привычки. Вот тут я попытался описать то же самое в json и xml форматах — кода получилось больше, понятней не стало.
mayorovp
06.05.2017 10:57Так вот ведь в чем дело — нет у верстальщика никакой проблемы с эффективностью.
vintage
06.05.2017 12:02Есть :-)
Как обычно работает верстальщик:
- Создаёт отдельную страничку, копипастит туда кучу хтмл, чтобы тестить компонент в различных вариациях.
- Руками прописывает классы.
- Периодически руками вносит изменения в каждую копию компонента.
- Отдаёт это дело программисту. Программист выпучивает глаза, но "натягивает шкурку на свой компонент", перелопачивая html до неузнаваемости.
Далее идёт два варианта:
- Верстальщик продолжает работать со своим развесистым хтмл-ом во всех состояниях, а программист периодически "перенатягивает шкурку". Крайне не эффективный вариант.
- Верстальщик пытается разобраться в том, что наворотил программист и ничего не сломав как-то изменять работающий где-то на странице компонент. Так как верстальщик не может видеть этот компонент во всех возможных состояниях одновременно — постоянно где-то что-то ломается.
Как это происходит у нас:
- Верстальщик не просто фигачит хтмл, а сразу создаёт переиспользуемые компоненты, используя другие компоненты. Всё это используя простой декларативный синтаксис.
- Тут же он создаёт демо-компонент, для своего компонента, который выводит его компонент в различных вариациях.
- Этот демо-компонент автоматически появляется в библиотеке компонент, где он сможет увидеть свой компонент в различных вариациях.
- Ему не надо прописывать классы — нужные классы генерируются автоматически, ему остаётся лишь добавить стилей.
- Параллельно с ним может работать программист, который расширяет созданный верстальщиком компонент, добавляя ему поведение. При этом программисту либо не потребуется вносить изменение в "шаблон", либо эти изменения будут незначительным и понятными верстальщику.
- В любой момент верстальщик может вернуться к компоненту и поправить что-то в нём и даже сделать редизайн, совершенно не парясь по поводу программной логики и видя свой компонент во всех вариациях одновременно.
Ну вот возьмём компонент "карточка":
mayorovp
06.05.2017 12:05Итак, вы прекрасно объяснили почему при использовании вашего фреймворка верстальщику приходится его изучать.
Осталось объяснить почему это является достоинством фреймворка, а не его недостатком.
Для справки: в том же knockout или angular не происходит никаких
Отдаёт это дело программисту. Программист выпучивает глаза, но "натягивает шкурку на свой компонент", перелопачивая html до неузнаваемости.
Верстальщик продолжает работать со своим развесистым хтмл-ом во всех состояниях, а программист периодически "перенатягивает шкурку". Крайне не эффективный вариант.
Верстальщик пытается разобраться в том, что наворотил программист и ничего не сломав как-то изменять работающий где-то на странице компонент.vintage
06.05.2017 12:09Нет, я объяснил, что правильная организация труда и грамотная архитектура повышает эффективность работы как отдельно взятых верстальщика и программиста, так и их взаимодействия. И для этого необходимо разобраться в новых концепциях.
mayorovp
06.05.2017 12:10Вы создали соломенное чучело и разнесли его в пух и прах. Повторюсь, тех ужасов которые вы описали — не происходит.
vintage
06.05.2017 12:12Ну так расскажите нам, как оно на самом деле :-)
mayorovp
06.05.2017 12:15Вот как описали вы — только без указанных мною пунктов. Программист не перелопачивает html — а спокойно проставляет атрибуты для дата-биндинга. Верстальщик при необходимости напрямую меняет страницу, не обращая внимания на непонятные атрибуты, используя возможности уже написанного программистом кода для того чтобы смотреть код во всех возможных состояниях.
В случае затруднений есть скайп.
vintage
06.05.2017 13:40Программист не перелопачивает html — а спокойно проставляет атрибуты для дата-биндинга.
Хороший программист разбивает html от верстальщика на компоненты. Потом приходит верстальщик и не может найти свою копипасту.
используя возможности уже написанного программистом кода для того чтобы смотреть код во всех возможных состояниях
Вручную накликивая по очереди все состояния? Ну да, очень "эффективно". Замечу, что проверять надо не только с разными состояниями самого компонента, но и различные комбинации компонент. Банально: страница с шапкой, страница с шапкой и подвалом, страница шапкой, подвалом и двумя колонками.
mayorovp
06.05.2017 13:46Компонент, который используется один раз на одной странице? Хороший программист такой глупостью не занимается.
Ровно как и не занимается созданием компонент, состоящих из одного элемента.
И я с трудом представляю себе страницу, в которой может внезапно появиться подвал и вторая колонка...
vintage
06.05.2017 14:01Компонент, который используется один раз на одной странице? Хороший программист такой глупостью не занимается.
Нет, который может быть использован и на других страницах. И по хорошему, это должен предусмотреть ещё верстальщик, но для этого его надо научить создавать компоненты, чтобы он не копипастил код, а переиспользовал через компонентную декомпозицию.
И я с трудом представляю себе страницу, в которой может внезапно появиться подвал и вторая колонка...
На разных страницах разный набор контролов, но построены из общих компонент. Я понимаю, непривычно, смотреть на приложение, не как на набор статичных страниц, а как на набор кубиков лего, и которых можно по разному составлять страницы и даже одну страницу динамически менять в зависимости от различных условий, но это позволяет быстрее создавать консистентные интерфейсы.
mayorovp
06.05.2017 14:44Не могу представить себе общий компонент для профиля пользователя и списка документов...
vintage
06.05.2017 15:00Почему? Вот наведите курсор на мою аватарку и увидите шапку моего профиля. А список документов тем более надо выносить в отдельный компонент, мало ли куда нужно будет приаттачивать документы — незачем изобретать велосипед.
mayorovp
06.05.2017 15:06Шапка профиля, подобная той которая там возникает, не относится к странице напрямую. Она делается в рамках отдельной задачи и верстается отдельно.
vintage
06.05.2017 15:49-1Да нет, сначала обычно делается большой профиль, а потом приходит менеджер и говорит "нам надо сделать, чтобы при наведении на аватар показывалась краткая инфа, как в шапке профиля, у вас есть пол часа".
DenEncode
06.05.2017 11:14+2А не пугают beraking changes минимум раз в год в Angular? (А скорее всего каждые пол года)
KyKyPy3uK
06.05.2017 11:15+2За все время что мы используем новый Angular я всего лишь раз столкнулся с проблемой от beraking changes и она решилась за час. Так что пока не пугают.
MOTORIST
07.05.2017 23:59Меня вот пугает =) Но JavaScript тоже на месте не стоит =) Не успеешь выучить одно, а через год уже что то новенькое. Тяжелая ноша фронтенщика.
VolCh
08.05.2017 10:44+1Новенькое без ломания старенького можно внедрять постепенно или обходиться только стареньким. А вот когда обратную совместимость ломают, то надо код переписывать. Что особенно весело, если никому толком не понятно, а что код должен делать в терминах бизнеса, UI и т. п.
Hazrat
Либо вы лепите своего монстра, либо используете из каталога.
x07
Angular тем и хорош, что все необходимое в нем уже есть, и его архитектура не позволяет лепить что попало. Благодаря этому, те, кто приходят в проект, сразу понимают где что, и могут сразу выполнять поставленные задачи.
Если сравнивать с тем же реактом, то там для старта надо сначала изучить весь зоопарк пакетов, без которых проект на реакте не взлетит, потом изучить организацию всяких компонентов-контейнеров, компонентов-представления и всего остального.
Но как говорится, дело вкуса…
eks1985
Да уж, изучить компоненты-контейнеры и компоненты-предствавления — это прям такая проблема большая. Одну страничку мануала прочитать и понять что, компоненты контейнеры могут иметь своe состояние и предопределенные обработчики, а компоненты представления только рендерят ui в зависимости от переданных им свойств.
По-поводу зоопарка — стандарт де факто это реакт + редакс. Второй при желании заменяется на любую другую имплементацию флакс. Но ведь это же плюс, а не минус, можно подобрать необходимый набор пакетов под свои нужды. Ну надо мне например управлять асинхронными экшенами — подключил redux-saga, надо эффективно кэшировать выборки из глобального состояния — подключил reselect.
Но вы правильно написали — дело вкуса.
vintage
А есть люди, которым не нужны асинхронно и эффективно?
KyKyPy3uK
Насчет компонентов-контейнеров и прочего согласен. Понимается за час, а дальше главное соблюдать правила. Я и в ангуляре придерживаюсь похожей практики.
Насчет зоопарка, тут не соглашусь. Популярный стек React + Redux на моей практики загубил уже немало проектов, да и сам я попался на эту удочку. Люди берут из-за популярности, а потом выпиливают с матом из проекта. Почти все мои знакомые отказались, кто-то в слез на MobX, а кто-то написал свое.
Возвращаясь к зоопраку — мой проект на реакте содержит почти полторы страницы библиотек в package.json, которые мне пришлось притащить. И это настоящий ад, так как за всем этим хозяйством надо следить, да и к тому же частенько самому фиксить баги. Это какое-то вынужденное сотрудничество с комьюнити получается.
По поводу Saga и reselect — видел, да и сам много раз напарывался, что написать хорошие saga обработчики или селекторы не так то просто. Очень просто написать селектор, который будет работать хуже чем обычный код на lodash. А документации и best practice просто нет.