Комментарии 101
React же для нас — это сборник хороших идей, но из-за отсутствия многих функций из коробки, зачастую каждый лепит из него своего «монстра»
Либо вы лепите своего монстра, либо используете из каталога.
Если сравнивать с тем же реактом, то там для старта надо сначала изучить весь зоопарк пакетов, без которых проект на реакте не взлетит, потом изучить организацию всяких компонентов-контейнеров, компонентов-представления и всего остального.
Но как говорится, дело вкуса…
Да уж, изучить компоненты-контейнеры и компоненты-предствавления — это прям такая проблема большая. Одну страничку мануала прочитать и понять что, компоненты контейнеры могут иметь своe состояние и предопределенные обработчики, а компоненты представления только рендерят ui в зависимости от переданных им свойств.
По-поводу зоопарка — стандарт де факто это реакт + редакс. Второй при желании заменяется на любую другую имплементацию флакс. Но ведь это же плюс, а не минус, можно подобрать необходимый набор пакетов под свои нужды. Ну надо мне например управлять асинхронными экшенами — подключил redux-saga, надо эффективно кэшировать выборки из глобального состояния — подключил reselect.
Но вы правильно написали — дело вкуса.
Ну надо мне например управлять асинхронными экшенами — подключил redux-saga, надо эффективно кэшировать выборки из глобального состояния — подключил reselect.
А есть люди, которым не нужны асинхронно и эффективно?
Насчет зоопарка, тут не соглашусь. Популярный стек React + Redux на моей практики загубил уже немало проектов, да и сам я попался на эту удочку. Люди берут из-за популярности, а потом выпиливают с матом из проекта. Почти все мои знакомые отказались, кто-то в слез на MobX, а кто-то написал свое.
Возвращаясь к зоопраку — мой проект на реакте содержит почти полторы страницы библиотек в package.json, которые мне пришлось притащить. И это настоящий ад, так как за всем этим хозяйством надо следить, да и к тому же частенько самому фиксить баги. Это какое-то вынужденное сотрудничество с комьюнити получается.
По поводу Saga и reselect — видел, да и сам много раз напарывался, что написать хорошие saga обработчики или селекторы не так то просто. Очень просто написать селектор, который будет работать хуже чем обычный код на lodash. А документации и best practice просто нет.
Постоянно идёт сравнение Ангуляра с Реактом, хотя первый пункт "Ангуляр — это фреймворк", а, как известно, Реакт — нет :)
Грубая настройка babel ничуть не сложнее typescript, а иногда лучше их настраивать цепочкой, потому как тонко настроить target компилятор typescript не может, аналогия babel с пресетами, но без возможности брать или добавлять только отдельные плагины, если целевые браузеры лишь чуть-чуть не дотягивают до используемых в исходниках фич.
А про модули не понял. Речь про import/export или что-то другое?
Согласен, что babel не такой уж и страшный зверь и у меня в принципе нет проблем с его настройкой, но не могу этого сказать про некоторых своих коллег. А мне надо было сделать так чтобы процесс сборки совсем не отнимал наше время. И да, конечно код получаемый babel в некоторых местах будет лучше и быстрее, но для нас это не так важно.
Модули в Angular очень похожи на стандартные es6 модули, но имеют некоторые отличия. Так например модуль это сущность для компилятора ангуляр, а значит можно использовать его конструктор как init метод (мы в нем например инжектируем локализацию в продукт). Во вторых вы помещаете весь роутинг вашего модуля внутрь модуля и это очень удобно. Также можно поступить и с сервисами для DI. Ну и наконец, если сравнить в React, то тут с учетом специфика ангуляра, просто добавив модуль вы можете легко использовать все компоненты экспортируемые модулем и вам не надо делать деструктинг компонентов из модуля для jsx.
и привыкли
So cute ;]
P.S. За статью спасибо, читается легко, ну и всегда приятно читать чужой опыт.
а то после того как angular наконец-то релизнулся, меня жутко раздражала долгая сборка проекта, при малейшем изменении на пустом проекте приходилось ждать по 8-10 секунд… да там есть прекопиляция но она как-то криво была сделана.
что сейчас не расскажите, ну или как вы решили эту проблему?
Если совсем надоест, можете посмотреть мой велосипед. Я, правда, так и не нашел времени довести до ума (там есть ветка dev и npm пакет), но если будет интересно, можно развить тему.
Статья актуальна на начало 2016 года.
Сейчас май 2017 и информация немного поменялась.
У React появился cli — create-react-app.
C 16 версии React избавится от необходимости оборачивающих тегов. Компоненты смогут возвращать массив тегов, html станет проще.
Вопрос про многообразие Flux-ов тоже уже закрыт. Если нравится функциональный код — берете Redux, если хотите классических объектов — MobX.
А насколько я знаю про выход Angular 4, то все минусы из статьи по-прежнему на месте. Документация сложная, объем кода, загружаемого в браузер, огромный.
Теперь насчет актуальности статьи. Про cli React я писал что он есть, правда указал немного другой. Насчет 16 версии React — я такой в production не вижу, а значит для меня ее нет. Точнее я конечно же читал про нее, в особенности про их fiber-ы, но уж простите, политика Компании и клиенты обязывают не юзать то, что официально не вышло. Но как я писал это не поможет нам, так как верстальщик у нас не знает JS.
По поводу Redux — да я его не люблю, и не из-за многообразия Flux решений, отнюдь. А не люблю я его из-за огромного кол-ва шаблонного кода, нередко монструозных side effect обработчиков и тормозящих геттеров из стейта (через reselect). У меня до сих пор есть довольно крупный проект на Redux и я каждый раз с неохотой что-то вношу в него. Похожий подход на angular у меня получился в разы компактнее и понятнее. Но это моя субъективная оценка и мой опыт и если кому-то Redux позволяет сделать красивый, простой и поддерживаемый код, я с удовольствием почитаю об этом на Хабре :)
тормозящих геттеров из стейта (через reselect)
Возможно, тормозит неоптимально написанный геттер — сам сталкивался с такой проблемой, когда плохо декомпозировал Селекторы и не работала мемоизация.
Идея в том, что при повторном вызове селектора с неизменившимися параметрами результат будет выдан из кеша без повторного вычисления.
Ну и насчет того, что за Angular стоит гугл это тоже не все так просто. Двое основных разработчиков уволились из Google и теперь зарабатывают деньги на обучении других Ангуляру.
https://blog.nrwl.io/introducing-narwhal-technologies-nrwl-5e192b887413
И в чём проблема? Я думаю у Гугла нет проблем с наймом хороших разработчиков.
Ребята придумали как зарабатывать больше денег. Молодцы. Но с точки зрения большой компании никакой трагедии нет.
Вы так написали как будто то что из за того что они зарабатывают на Ангуляре вне Гугл у Гугл выручка уменьшится. Прям ужос-ужос.
Не в выручке дело, а в том как Ангуляр будет развиваться без основных разработчиков
Найти новых людей не проблема.
Дело в том, что делать фреймворк — это не то же самое что продукт. Это больше как рок-группа. Ушел гитарист, взяли другого, играет нормально, а звучание все равно не то.
Вот и здесь есть шансы, что люди, пришедшие на замену, повернут развитие Ангуляра в другую сторону.
Для реакта, конечно больше материалов, причем русскоязычных, наверное поэтому он является самой популярной библиотекой для фронтенд.
Ага, т.е. когда мне вместо внятного указания ошибки в моем коде в произвольно взятом с codeproject примере выдается вот такая херня — это небольшой порог вхождения?
Так это даже не проблема ангуляра, у вас же сервер вместо js/json отдаёт html, и js-парсер ломается на первом же "<". Но тут такое дело: чтобы писать на том же ангуляре, нужно ещё знать всякие сопутствующие вещи, вроде настройки сборщиков, компиляторов и т.д. Да, это порой трудно, но за такие знания и платят очень неплохо.
Но в любом случае, для облегчения всей этой возни с конфигами есть всякие cli, и у реакта, и у ангуляра. Вы пробовали их использовать? Или пройти туториал на оф. сайте?
Вот такая история. И вопрос у меня ровно один — почему все занимаются изобретательством всякой херни типа Angular уже 4, React и прочие Knockout и никто при этом еще не сделал никакой внятной системы диагности при сборке этого непотребства? Сообщения типа того, что на скриншоте, я ловил пачками и на React, и еще на каких-то поделиях.
Возможно если будет время на праздниках напишу статью по всем возможным способам создания компонентов в angular и какие там есть проблемы.
Написали свой проект на 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 крут, но как нам кажется это технология для больших команд, у которых есть ресурсы, чтобы запустить проект в обозримое время.
DOM собирался 35000 миллисекунд, да вы не ослышались 35 секунд!
Это сколько нод или элементов в доме?
А изменения в дом дерево новый ангуляр вводит очень быстро
Ну возможно что то делали не так?
У меня минимизированная версия Ionic приложения собранная с --prod грузится около 3х секунд.
https://www.youtube.com/watch?v=TCj_oC3m6_U
Если бы все было так просто, universal не нужен был бы, логично?
Вы обжимаете перед выкладкой? Если выкладывать как есть, то 35 сек. будет.
На мобиле с локальной файловой системы примерно такие же цифры, но там ещё Cordova грузится.
Так что какие-то надуманные или более не актуальные проблемы.
пример https://shop.polymer-project.org
Открыл ссылку, а там:
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.То есть, фактически, нормального решения пока нет?
Тикет о поддержке closure compiler — закрыт 3 дня назад. И это нормальное стабильное решение?
Репозиторий с примером кода — требует Brotli. То есть вместо джентельменского сравнения полученного кода нужно применять читы в виде более агрессивного сжатия, чтобы получить адекватные цифры?
Заявлено что в дальнейшем только лучше будет.
Например, создание динамических компонентов, их вставка в кастомные элементы таба. Так же недостаточно информации о повторном использовании созданных компонентов для текущего роутера, у которого меняется только переменная часть типа :id.
К сожалению, не пересоздавать компоненты при переходах между разными роутерами пока невозможно.
Не это: https://github.com/angular/angular/issues/5275#issuecomment-291757819
меняется лишь динамическая часть URL
здесь вместо создания нового объекта компонента используется старый объект с новыми значениями внутренних полей — роутер-то остается старым, хоть и меняется URL…
а вот когда URL новый и связан с другим роутером и компонентом — тогда предыдущий разрушается
Прошу меня извинить, но тут всё так по пунктам разложено, что я не смог удержаться и не сравнить с тем фреймворком, что разрабатываем мы :-)
Начиная работу над проектом, мы выбрали популярный сейчас стек 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 звёзд на гитхабе. Расходимся, ребята :-)
Чёрт, самое главное-то забыл. Весь маркетинг впустую :-D http://mol.js.org
Спасибо, скоро поправим.
Мой опыт подсказывает, что широкая иерархия практичней, чем глубокая. А вы бы как сгруппировали?
У нас микоядерная архитектруа, так что никакого core у нас нет. assets тоже нет, ибо ресурсы кладуются рядом с кодом, который их использует. Можно было бы разделить на "визуальные компоненты" и "всё остальное", но польза сомнительна, а имена все увеличатся.
Отсутствие какого-то общего для всего фреймворка ядра. Одни модули используют одни модули, другие — другие. В зависимости от того, какие модули вы используете — может быть загружен совершенно разный набор модулей.
Верстальщику придётся выучить новый язык (который не сложнее HTML), но оно того стоит — код получается лаконичным, но мощным.
Вот это — истинный убийца вашего чудо-фреймворка.
Нельзя повысить эффективность, не меня привычки. Вот тут я попытался описать то же самое в json и xml форматах — кода получилось больше, понятней не стало.
Так вот ведь в чем дело — нет у верстальщика никакой проблемы с эффективностью.
Есть :-)
Как обычно работает верстальщик:
- Создаёт отдельную страничку, копипастит туда кучу хтмл, чтобы тестить компонент в различных вариациях.
- Руками прописывает классы.
- Периодически руками вносит изменения в каждую копию компонента.
- Отдаёт это дело программисту. Программист выпучивает глаза, но "натягивает шкурку на свой компонент", перелопачивая html до неузнаваемости.
Далее идёт два варианта:
- Верстальщик продолжает работать со своим развесистым хтмл-ом во всех состояниях, а программист периодически "перенатягивает шкурку". Крайне не эффективный вариант.
- Верстальщик пытается разобраться в том, что наворотил программист и ничего не сломав как-то изменять работающий где-то на странице компонент. Так как верстальщик не может видеть этот компонент во всех возможных состояниях одновременно — постоянно где-то что-то ломается.
Как это происходит у нас:
- Верстальщик не просто фигачит хтмл, а сразу создаёт переиспользуемые компоненты, используя другие компоненты. Всё это используя простой декларативный синтаксис.
- Тут же он создаёт демо-компонент, для своего компонента, который выводит его компонент в различных вариациях.
- Этот демо-компонент автоматически появляется в библиотеке компонент, где он сможет увидеть свой компонент в различных вариациях.
- Ему не надо прописывать классы — нужные классы генерируются автоматически, ему остаётся лишь добавить стилей.
- Параллельно с ним может работать программист, который расширяет созданный верстальщиком компонент, добавляя ему поведение. При этом программисту либо не потребуется вносить изменение в "шаблон", либо эти изменения будут незначительным и понятными верстальщику.
- В любой момент верстальщик может вернуться к компоненту и поправить что-то в нём и даже сделать редизайн, совершенно не парясь по поводу программной логики и видя свой компонент во всех вариациях одновременно.
Ну вот возьмём компонент "карточка":
Итак, вы прекрасно объяснили почему при использовании вашего фреймворка верстальщику приходится его изучать.
Осталось объяснить почему это является достоинством фреймворка, а не его недостатком.
Для справки: в том же knockout или angular не происходит никаких
Отдаёт это дело программисту. Программист выпучивает глаза, но "натягивает шкурку на свой компонент", перелопачивая html до неузнаваемости.
Верстальщик продолжает работать со своим развесистым хтмл-ом во всех состояниях, а программист периодически "перенатягивает шкурку". Крайне не эффективный вариант.
Верстальщик пытается разобраться в том, что наворотил программист и ничего не сломав как-то изменять работающий где-то на странице компонент.
Нет, я объяснил, что правильная организация труда и грамотная архитектура повышает эффективность работы как отдельно взятых верстальщика и программиста, так и их взаимодействия. И для этого необходимо разобраться в новых концепциях.
Вы создали соломенное чучело и разнесли его в пух и прах. Повторюсь, тех ужасов которые вы описали — не происходит.
Ну так расскажите нам, как оно на самом деле :-)
Вот как описали вы — только без указанных мною пунктов. Программист не перелопачивает html — а спокойно проставляет атрибуты для дата-биндинга. Верстальщик при необходимости напрямую меняет страницу, не обращая внимания на непонятные атрибуты, используя возможности уже написанного программистом кода для того чтобы смотреть код во всех возможных состояниях.
В случае затруднений есть скайп.
Программист не перелопачивает html — а спокойно проставляет атрибуты для дата-биндинга.
Хороший программист разбивает html от верстальщика на компоненты. Потом приходит верстальщик и не может найти свою копипасту.
используя возможности уже написанного программистом кода для того чтобы смотреть код во всех возможных состояниях
Вручную накликивая по очереди все состояния? Ну да, очень "эффективно". Замечу, что проверять надо не только с разными состояниями самого компонента, но и различные комбинации компонент. Банально: страница с шапкой, страница с шапкой и подвалом, страница шапкой, подвалом и двумя колонками.
Компонент, который используется один раз на одной странице? Хороший программист такой глупостью не занимается.
Ровно как и не занимается созданием компонент, состоящих из одного элемента.
И я с трудом представляю себе страницу, в которой может внезапно появиться подвал и вторая колонка...
Компонент, который используется один раз на одной странице? Хороший программист такой глупостью не занимается.
Нет, который может быть использован и на других страницах. И по хорошему, это должен предусмотреть ещё верстальщик, но для этого его надо научить создавать компоненты, чтобы он не копипастил код, а переиспользовал через компонентную декомпозицию.
И я с трудом представляю себе страницу, в которой может внезапно появиться подвал и вторая колонка...
На разных страницах разный набор контролов, но построены из общих компонент. Я понимаю, непривычно, смотреть на приложение, не как на набор статичных страниц, а как на набор кубиков лего, и которых можно по разному составлять страницы и даже одну страницу динамически менять в зависимости от различных условий, но это позволяет быстрее создавать консистентные интерфейсы.
Не могу представить себе общий компонент для профиля пользователя и списка документов...
Почему? Вот наведите курсор на мою аватарку и увидите шапку моего профиля. А список документов тем более надо выносить в отдельный компонент, мало ли куда нужно будет приаттачивать документы — незачем изобретать велосипед.
Почему мы выбрали новый Angular