Angular 2 достиг беты и имеет все шансы сорвать лавры топового фреймворка в 2016 году. Время разборок. Давайте посмотрим, что он может противопоставить React, душечке из 2015 года.
Disclaimer: Я работал с первым Angular, но переключился на React в 2015 году. Я опубликовал Полный курс React и Flux. Так что да, я предвзят. Но я буду атаковать обе стороны.
Хорошо, пора начинать. И будет кровь.
Вы сравниваете круглое и мягкое.
*Вздыхая* Да, Angular это фреймворк, а React — библиотека. Кто-то скажет, что разница делает эти вещи несопоставимыми. Как бы не так!
Выбор между Angular и React это как выбор между собранным десктопным ПК и сбором своего из отдельных комплектующих.
Этот пост по сути рассматривает эти два подхода. Я буду сравнивать синтаксис и компонентную модель React и Angular. Это уже как сравнивать готовый ЦП с сырыми ЦП 1. Т.е. сравнивать мягкое с мягким.
Преимущества Angular 2
Давайте рассмотрим преимущества Angular 2 над React.Быстрый старт
Angular — это фреймворк, он предоставляет гораздо больше возможностей и функциональности из коробки. С React, вам придется тянуть пул библиотек сторонних разработчиков для построения приложения. Наверняка, понадобиться библиотеки для роутинга, для организации однонаправленного потока, обращения к API, тестирования, менеджера зависимостей, и т.д. Количество решений довольно обширно. Поэтому существует много стартовых пакетов для React (я опубликовал два 2).
Angular предлагает множество решений из коробки, которые помогают вам сразу стартовать без страха перед принятием большого количества решений. Единые решения, также помогают разработчикам менять проекты без необходимости заново вникать в процесс разработки.
Я в восторге как разработчики Angular осваивают TypeScript, что приводит к следующим преимуществам...
TypeScript = Путь чистоты
Конечно, у TypeScript нет всеобщего обожания, но использование его в Angular 2 это большая победа. Во всем вебе вы натолкнетесь на два варианта использования React — он представлен в ES5 и ES6 приблизительно в равной степени, что в свою очередь приводит к трем различным вариантам декларирования компонентов. Это смущает новичков. (Правда Angular предлагает использовать декораторы вместо расширений, многие считают это преимуществом.)
Когда Angular 2 не требует TypeScript, команда разработчиков продолжает использовать его, по умолчанию, в документации. Это означает что проекты с открытым исходным кодом и соотвествующие примеры делает код более однообразным. Angular уже предоставляет наглядные примеры, показывающие как использовать компилятор TypeScript. (нужно признать, повсеместного распространения TypeScript еще нет, но я подозреваю, что вскоре после запуска он станет стандартом де факто). Такой подход помогает избежать недоразумений, нередких при старте работы с React.
Снижение оттока
2015 был годом Javascript усталости. React был ключевым фактором. То что React так и не достиг версии 1.0, говорит нам о критических изменениях в будущем. Экосистема React развивалась дикими темпами особенно это касалось оттенков Flux и роутинга. Имеется ввиду, все то что вы пишите сегодня скорее всего устареет при выходе React 1.0, а, скорее всего, придется вообще переписать.
В этом смысле Angular 2 это тщательное, методическое переосмысление целостного фреймворка. Поэтому Angular 2 не увидит такого оттока клиентов и головной боли после релиза. И как целостный фреймворк, Angular более подходит для долгосрочных решений представленных одной командой. В React же это ваша ответственность собрать вместе множество, быстро развивающихся, библиотек с открытым кодом в одно стабильное приложение. Это трудоемкий, неприятный и непрерывный процесс.
Повсеместная поддержка
Как вы увидите ниже я считаю JSX большим достижением. Тем не менее вам необходим инструментарий с поддержкой JSX. React стал настолько популярным, что инструменты перестали быть проблемой. Но новые инструменты такие как IDE и линтеры вряд ли быстро поддержат этот формат в первый же день 3. Хранилище шаблонов разметки Angular в строках или отдельных файлах HTML не требуют отдельных инструментов поддержки (хотя уже есть умные инструменты для работы со строковыми шаблонами Angular на лету). Хочу сказать, подход Angular имеет свое множество подводных камней, что служит хорошей подводкой к теме преимуществ React...
Преимущества React
Хорошо, давайте посмотрим что нам может предложить React.
JSX
JSX это HTML подобный синтаксис, компилируемый в JavaScript. Разметка и код находятся в одном файле. Это решение позволяет вставлять ссылки на функции, компоненты и переменные. И наоборот, строчные шаблоны Angular тянут за собой явные минусы: нет подсветки синтаксиса во многих редакторах, нет полной поддержки автокомпиляции и подсветки ошибок в коде. Казалось бы это должно привести к ужасному выводу сообщений об ошибках, но команда Angular написали свой собственный парсер HTML кода. (Браво!)
Если вам не нравятся строчные шаблоны Angular, вы можете вынести шаблоны в отдельный файл, но тогда вы получите то что я называю «старые деньки»: писать код в двух файлах в уме, без поддержки автодополнения или проверки синтаксиса перед компиляцией. Это не кажется большой проблемой пока вы не насладитесь жизнью внутри React. Компоненты в одном файле с проверкой синтаксиса, это одна из важнейших причин превосходства JSX.
Сравните только как Angular 2 и React обрабатывают незакрытый тег
Для лучшего осознания преимуществ JSX посмотрите JSX: The Other Side of the Coin
React ошибки — быстро и четко
Когда вы делаете опечатку в JSX у React, он не захочет компилироваться. Это великолепная вещь. Вы сразу точно знаете в каком ряду ошибка. Понятно что это незакрытый тег или ссылка на объявленную переменную. На самом деле, JSX компилятор укажет номер строки в которой вы допустили ошибку. Это существенно увеличивает скорость разработки.
И наоборот, когда вы ошибаетесь с ссылкой на переменную в Angular 2, ничего не произойдет. Angular 2 тихонько себе упадет во время выполнения, а не компиляции. Такие ошибки медленные. Я запускаю свое приложение и задаюсь вопросом, почему мои данные не отображаются. Веселого мало.
React JavaScript центричен 4
Вот оно. В этом заключается ключевое различие React и Angular. К сожалению, Angular остается HTML ориентированным. Angular 2 не удалось решить наиболее принципиальную проблему архитектуры:
Angular 2 продолжает помещать JS в HTML. React же помещает HTML в JS
Я не достаточно выделил этот раскол. Это принципиально влияет на опыт разработки. В Angular HTML ориентированный дизайн остается его слабым местом. Как я и подчеркнул в JSX: The Other Side of the Coin, JavaScript более мощный чем HTML. Гораздо логичнее усиливать возможности JavaScript для поддержки разметки, чем HTML расширять логикой. HTML и JavaScript все равно должны быть как-то склеены и JavaScript ориентированный подход React является несомненным превосходством над Angular, Ember и Knockout c их HTML ориентированным подходом.
Вот почему...
JavaScript ориентированный React = простота
Angular 2 продолжает подход версии 1 в попытке сделать HTML более мощным. Поэтому вы должны использовать особый синтаксис Angular для простых вещей типа циклы или условные операторы. Например, Angular предлагает разный синтаксис для односторонней и двухсторонней привязки данных:
{{myVar}} //One-way binding
ngModel="myVar" //Two-way binding
В React, привязка не меняет синтаксис (она обрабатывается в другом месте, подразумевается, что так и должно быть). В любом случае это выглядит так:
{myVar}
Angular поддерживает встроенный шаблонизатор с помощью такого синтаксиса:
<ul>
<li *ngFor="#hero of heroes">
{{hero.name}}
</li>
</ul>
В приведенном выше фрагменте кода идет перебор массива героев. У меня есть несколько опасений.
- Объявление «шаблонизатора» через звездочку неочевидно.
- Решетка перед hero объявляет локальную переменную в шаблоне. Эта ключевая концепция выглядит как ненужный шум (при желании вы можете использовать var).
- ngFor семантично добавляет цикл в HTML c помощью Angular атрибута.
Вопреки Angular, React использует «чистый» JS: (правда key специфичен).
<ul>
{heroes.map(hero =>
<li key={hero.id}>{hero.name}</li>
)}
</ul>
Цикл нативно поддерживается JS. React JSX может запросто задействовать всю мощь JS для подобных вещей.
Просто почитайте Angular 2 Cheat Sheet. Это не HTML. Это не JavaScript. Это Angular.
Для чтения Angular выучи длинный список спицифичного для Angular синтаксиса
Для чтения React выучи JavaScript
React уникальный в своей простоте и концепции синтаксиса. Рассмотрим итерации в популярных сегодня JavaScript фреймворках/библиотеках:
Ember: {{# each}}
Angular 1: ng-repeat
Angular 2: ngFor
Knockout: data-bind=”foreach”
React: JUST USE JS. :)
Все, кроме React, используют специфичный синтаксис для замены стандартного в JS цикла. Вот в чем прелесть React. Он содержит всю мощь JavaScript для обработки разметки, так что ничего дополнительного не требуется.
Синтаксис Angular 2 продолжает удивлять привязкой обработчика клика по элементу:
(click)=”onSelect(hero)"
В то же время React использует простой JavaScript, опять:
onClick={this.onSelect.bind(this, hero)}
И, поскольку, React включает свою надстройку над событийной системой (также как и Angular 2), вам не придется беспокоиться о влиянии на продуктивность таких объявлений обработчиков событий.
Зачем забивать голову дополнительными уникальным синтаксисом фреймворка, если вы можете не делать этого? Почему бы просто не использовать всю мощь JS?
Роскошный опыт разработки
JSX автодополнение, проверка во время компиляции и информативный обработчик ошибок уже создает отличную базу для разработки, что очень экономит время набора. Но если объединить это все с Hot Reloading with Time Travel и вы получите неповторимый опыт как нигде более.
Размер имеет значение
Вот размеры упомянутых библиотек/фреймворков, минифицированные:
Ember: 580k
Angular 2: 565k (759k with RxJS)
React + Redux: 204k
Angular 1: 145k
Чтобы посмотреть реальный размер я создал приложение Tour of Heroes в Angular и React (для React я использовал новый стартовый набор React Slingshot)
Angular 2: 764k minified
React + Redux: 216k minified
Итак Angular 2 более чем в три раза больше React + Redux в сопоставимой простоте5. (После последнего релиза Angular несколько похудел)
Конечно, я признаю что опасения по поводу размеров фреймворка несколько преувеличены.
Большие приложения, как правило, содержат минимум несколько сотен килобайт кода, зачастую больше, вне зависимости пострены они с фреймворком или без. Разработчикам необходимы абстракции для построения сложных приложений, вне зависимости из фреймворка они или рукописные, они отрицательно влияют на производительность приложения.
Даже если вы избавитесь от всех фреймворков, множество приложений по прежнему будут весить килобайты кода
— Tom Dale
Том прав. Такие фреймворки как Angular или Ember большие потому что они содержат множество решений из коробки.
Как бы то ни было, я считаю, что многие приложения не нуждаются в полном списки возможностей фреймворка. В мире где микросервисы и микроприложения занимают все больше жизненного пространства, React дает вам силу выбирать для своего приложения только необходимые компоненты. В мире где существует более 200 000 npm модулей это несомненное преимущество.
React включает Философию UNIX
React это библиотека. Это точно противостоит философии комплексных фреймворков, таких как Angular и Ember. Итак когда вы выбираете React, вы вольны выбирать современные, лучшие в своем классе, библиотеки. Вы сможете решить вашу проблему лучшим путем. JavaScript развивается очень быстро, и вы вольны включать в ваше React приложение лучшие библиотеки вместо ожидания обновления фреймворка.Unix выдержал проверку временем. Вот почему:
Философия маленьких, составных, одноцелевых инструментов никогда не выйдет из модыReact это сфокусированный, составной, служащий одной цели инструмент используемый многими сайтами в мире. Это говорит о большом будущем. (Стоит заметить что Angular имеет не меньшее распространение)
Подводя итоги
Angular 2 это большой шаг по сравнение с версией 1. Новая компонентная модель проще для понимания чем директивы в первой версии, он поддерживает изоморфный/универсальный рендеринг, и он использует виртуальный дом что дает 3–10 кратный прирост производительности. Эти изменения делают Angular 2 очень конкурентоспособным React. Не будем отрицать, что его полнофункциональная, самоуверенная природа предлагает некоторые явные преимущества за счет сокращения “JavaScript усталости”.
Тем не менее в Angular 2 размер и синтаксис останавливает меня. Приверженность Angular к HTML-ориентированному дизайну делает его сложным по сравнению с проще на JavaScript-ориентированной модели React. В React, вам не придется учить специфичный HTML синтаксис такой как ngWhatever. Вы тратите время на написание чистого JavaScript. Я верю что у этого есть будущее.
Комментировать тут Reddit или тут Hacker News.
Об авторе: Кори Хаус является автором “Building Applications with React and Flux”, “Clean Code: Writing Code for Humans” и многих других курсов на Pluralsight. Он является архитектором программного обеспечения в VinSolutions и тренер разработчиков программного обеспечения на международном уровне в сфере фронтенд разработки и чистого кодинга. Кори Microsoft MVP, Telerik Developer Expert, и основатель outlierdeveloper.com
1 — простите, не понял что такое raw CPU
2 — у меня тоже такой есть
3 — тут я с автором не согласен уже есть поддержка во всех IDE (хотя я в MS не проверял) и уже видел много расширений для линтеров
4 — мне кажется в этом случае центричен подходит более
5 — comparable simplicity
П.С. (от переводчика) Лично я использую React, и данная статья мне показалась интересной. Мне больше нравится расширения, а не декораторы. Мне нравится мой стартовый набор и возможность менять содержимое фреймворка. Я не очень люблю TypeScript и предпочитаю ES6. Но всегда с интересом участвую в ангуларных проектах :)
Пишите мне об ошибках, опечатках и неточностях постараюсь быстро внести правки в статью!
Комментарии (183)
greabock
05.01.2016 22:56+4Все просто и понятно: Angular — уг, React — must have. Невероятно информативная статья. [/sarcasm]
spmbt
05.01.2016 23:12Все, кроме React, используют специфичный синтаксис для замены стандартного в JS цикла.
Почему? Backbone со встроенным Underscore тоже в шаблонах использует нативные циклы и JS. Правда, отлаживать их приходится по ошибкам не в исходном коде (такие же проблемы у всех шаблонизаторов и Angular в том числе), а в компилированных шаблонах — в JS-файлах. Но структура этих файлов легко читаема и повторяет текст шаблонов. Поэтому нативный JS в шаблонах — не всегда есть преимущество. Другое дело, что смешивание шаблонов и логики в продвинутых моделях неизбежно, и тренд «нести HTML в JSX» — выигрышнее по названной в статье простой причине.JCHouse
06.01.2016 01:40-1Нативные или методы underscore?
Все таки в ES6 это делается так:
someArray.map((x) => x + 'someText');
а в Underscore:
_.map(someArray, function (x) { return x + 'someText'; });
Разница есть же хотя читать документацию для этого уже необязательноspmbt
06.01.2016 08:49+1В _шаблонах_ Underscore используется любой нативный JS.
Потом они компилируютя по _.template(текст_шаблона, параметры).<div>Этот текст повторится 5 раз: <% for(var i=0; i < 5; i++) { %> номер <%= i %> / <% } %> </div>
non4me
05.01.2016 23:36+3Думаю важно отметить что Ангулар стал, де факто, корпоративным фреймворком. Возможно именно в силу своей однозначности и комплексности. С второй версией уйдут и всякие детские болезни (надеюсь).
А Реакт это сборник хороших идей, но каждый их лепит по своему усмотрению. В итоге время вхождения нового разработчика в сложный проект куда большее.
Сужу сугубо исходя из личного опыта участия в нескольких проектах.non4me
06.01.2016 07:52+1Да, еще забыл упомянуть. Существует же третий путь, ngReact. Причем вполне жизнеспособный. Можно же всегда скрестить коня и трепетную лань. ;)
Fesor
06.01.2016 11:36это было более-менее актуально для первого ангуляра (и то сомнительно). Для второго смысла в ngReact нет. А вот ngRedux — да, штука полезная.
Я полностью с вами согласен что бессмысленно спорить кто круче, пытаясь сравнивать библиотеку и фреймворк. Да и ангуляр с самого начала нацелен был на энтерпрайзы.
И то что реакт популяризировал хорошие идеи (stateless-компоненты, unidirectional data flow), это хорошо.
jakobz
06.01.2016 13:48Это да. Но все упирается в то, что решительно непонятно как на ангуляре (первом) писать корпоративные сайты. Там же нет ничего для того чтобы масштабироваться в сложность — на каком-то размере проекта оно заливается копипастой и сливается в треш из колбеков.
Мы пробовали сделать на ангуляре несложный бекофис — с гридами, фильтрами, формами, и попапами. Не получилось — когда даже сильно загаженный проект на TypeScript+React уверенно едет вперед, проект на ангуляре перешел в фазу «чиним одно — ломается другое».
Для несложных красивых сайтов — может оно ок.non4me
06.01.2016 14:19Не очень понятно зачем вообще делать корпоративный сайт на Ангулар. В подавляющем большинстве это просто информационный сайт, для которого хватает всяких Drupalов, Битриксов, Вордпресов…
Не хочу показаться кепом, но Ангулар, впрочем как большинство других JS фреймворков, это прежде всего инструмент для создания сервисов. Т.е. там где на стороне клиентов требуется сложная логика и главное ее целесообразно иметь именно там. Всякие там клиент-банки, системы подбора чего нибудь, ну и подобное… что с категорий несложных сайтов имеет мало общего.
Для бэкофисов тоже, милое дело. Не знаю что у вас конкретно не сложилось в нем с Ангуларом. У меня наоборот наиболее успешный опыт именно с бэкофисами и всякими админками.jakobz
07.01.2016 17:25Под корпоративными я больше понимал всякие там бекофисы — с гридами, формами и прочим. У нас это называют «опердни». Т.к. теперь требования по UX сейчас сильно выше чем «лишь бы работало, пофиг что глючит и выглядит как кака», всякие корпоративные приложения теперь не сильно проще той же JIRA. Всякие RIA — штуки типа trello, багтрекеры, и прочее — туда же.
И вот на мой взляд как раз для таких RIA — с добротным UX и сложной логикой на UI, реакт заходит куда лучше. Тот же google analytics, trello, jira, и даже какую-нибудь web-based IDE — я бы смело взялся бы делать на реакте. Ангуляр такую сложность уже не держит по моим наблюдениям.non4me
07.01.2016 17:55А как именно проявляется недержание? Какие то конкретные примеры можете привести?
Fesor
07.01.2016 19:51+1Ангуляр такую сложность уже не держит по моим наблюдениям.
У вас выборка не репрезентативна.
У ангуляра есть свой минус — это старая технология. Angular появился аж в 2009-ом году. Директивы до 2011-ого были только оберткой над DOM, позволяющие делать кирпичики для декларативной разметки. И это уже само по себе было довольно мощьной концепцией позволяющей перестать завязывать UI на DOM и начинать оперировать состоянием данных.
React (и всякие там Twitter Flight и т.д.) появились только в 2013-ом году. К этому моменту мысль о том что в ангуляре API тех же директив слишком сложны или там то что сделать двусторонний дата биндинг единственным вариантом проброса состояния между UI компонентами это плохая идея, уже и так все знали.
Но в том то и отличие хипстерских библиотек с ветками 0.x от решений применимых в эентерпрайз мире — надежность API, обратная совместимость и т.д. Что бы пофиксить эти проблемы надо было вводить версию 2.0 и где-то уже тогда начали думать о том как исправить проблемы первых версий.
Но и первая ветка эволюционирует. Вот например я привел очень простой пример (который не должен работать а только демонстрирует суть) эволюции компонентов в ангуляре (там от версии 1.5 до 1.0). Почувствуйте разницу. По примеру видно что где-то с версии 1.3 на ангуляре можно было уже делать вещи хорошо. Тем более что все проблемы и идеи для второго ангуляра обсуждались поблично. Я мало знаю ангулярщиков которые делают UI без stateless компонентов и без штук типа redux.
К сожалению проблема двусторонниего датабиндинга для первой ветки до сих пор актуальна (пример кастыля), но есть PR добавляющий поддержку одностороннего биндинга. Если подобная штука будет добавлена, то делать как в реакте вообще не проблема.
Во втором же ангуляре подобных проблем нет.jakobz
08.01.2016 16:17+1Но в том то и отличие хипстерских библиотек с ветками 0.x от решений применимых в эентерпрайз мире — надежность API, обратная совместимость и т.д.
Ну т.е. Ангуляр — поменявший формат директив несколько раз, и вводящий новую не совместимую по API версию — хиптерская библиотека.
А реакт — вводивший от старта только пару реальных breaking changes, заботливо выводящий warning-и про отмену каких-то фичей в будущих версиях, и даже иной раз предлагающий автоматические скрипты для обновления — это энтерпрайз-решение.
Всё верно?Fesor
08.01.2016 17:14Ну т.е. Ангуляр — поменявший формат директив несколько раз
Код который у вас работал на верси 1.0 будет продолжать работать на версии 1.5. В каком именно месте они сломали обратную совместимость? Все строго согласно semver.
Реакту до версии 1.0 более чем законно ломать обратную совместимость между релизами (ну в пределах разумного, все ж не дураки пишут).
aav
06.01.2016 15:43+3Я бы еще понял, если бы жаловаться начали на производительность — это стандартная песня. Но жаловаться на копипаст при написании проекта на AngularJS — это какой-то новый уровень…
jakobz
07.01.2016 17:58Я там ниже на комментарий написал почему ангуляр более располагает к копипасте, чем реакт. Если коротко:
— директивы весьма ограничены по фичам
— императивное программирование на колбеках менее расположено к декомпозиции чем функциональный стиль
— система модулей ангуляра навязывает лишнее трение для выноса общего кода
— если сравнивать со связкой react+typescript — то добавляется еще что строго типизированный код гораздо лучше поддается декомпозиции: проще рефакторинг, автокомплит помогает найти уже написанные хелперы
Безусловно, если ввести адский фашизм на проекте — code review, ататашки за копипасту, и т.п. — можно добиться хорошего качества кода и в случае с ангуляром. Но это все дорого и сложно. В то время как реакт сам по себе располагает писать нормально сразу — там без всякой принудиловки получается нормальный код — эдакий tar pit of success.
Fesor
06.01.2016 15:53+1проект на ангуляре перешел в фазу «чиним одно — ломается другое».
Была такая чудная песенка у Веьямина Дыркина — Хожу и гажу.
отрывокШоколадку вкусну-сладку
Ты съела, и тебя стошнило,
И весь день тебя потом тошнило,
И всю ночь тебя потом тошнило.
И нет загадочней на свете загадки:
Может, дело все и не в шоколадке?jakobz
07.01.2016 17:13>Ну и тесты таки надо писать.
Самое смешное — что в проекте на ангуляре 100%-е покрытие, а на react+typescript — считай что 0%-е. При этом в ангуляре регрессий драматически больше.
>А делать в ангуляре как на реакте (stateless компоненты) — это запросто.
В ангуляре получается больше копипасты, потому что директивы — гораздо слабее чем компоненты реакта. По нескольким причинам: API компонент ограничен простыми структурами, твои компоненты обязаны поддерживать очень нетривиальные механизмы датабиндинга, вокруг директив очень много магии.
Я пробовал сделать на ангуляре классический для реакта ход: в таблицу передаются шаблоны ячеек как аргументы. Мне натурально пришлось пробраться через тонны советов в стиле «чувак, в ангуляре так не надо, лучше копипасти»; в деталях разобраться как внутри работают директивы, контексты и прочая магия; прочитать прилично исходников ангуляра; и все-равно я не дожал чтобы нормально все работало.
В результате я вижу ng-repeat для каждой таблички, в каждом шаблоне — со всем сопутствующим копипастом разметки этой таблички.
Кроме того, копипасте в ангуляре прекрасно способствует его IoC с модулями: они банально создают лишнее «трение» на вынос общего кода наружу.
Ну и сама парадигма ангуряра — императивная, jQuery-style, лапша из колбеков мутирующих общий стейт — она не сильно способствует появлению реюзабельных кусков кода вообще.
Ну и все в сумме дает то, что в ангуляре — проще копипастить, в реакте — проще выносить компоненты (или даже просто функции внутри одного компонента).aav
07.01.2016 19:29+1Самое смешное — что в проекте на ангуляре 100%-е покрытие, а на react+typescript — считай что 0%-е. При этом в ангуляре регрессий драматически больше.
100% покрытие, а регрессий куча. Может не то и не так тестируете?.. Вопрос на самом деле риторический, потому что эта ваша фраза звучит очень плохо. И говорит больше не про Angular. Странно, что вы сами себе не задали вопрос «как так получается, что мы столько усилий тратим на тесты, а они не работают».
В результате я вижу ng-repeat для каждой таблички, в каждом шаблоне — со всем сопутствующим копипастом разметки этой таблички.
Что даже банального
<some-cell-type param1="..." param2="..."></some-cell-type>
вместо копипасты не получилось? Это надо очень сильно не разобраться.
Мне натурально пришлось пробраться через тонны советов в стиле «чувак, в ангуляре так не надо, лучше копипасти»; в деталях разобраться как внутри работают директивы, контексты и прочая магия; прочитать прилично исходников ангуляра; и все-равно я не дожал чтобы нормально все работало.
Пробираться надо было не через тонны исходников ангуляра (чем они тут сильно помогут?), а через хотя бы несколько вариантов реализации похожих вещей из различных библиотек типа angular-ui. Код там, конечно, далеко не всегда хороший, но когда рядом представлены 3 варианта примерно одного и того же, думаю, не сложно понять, где получше, да поправильнее.
Ну и сама парадигма ангуряра — императивная, jQuery-style, лапша из колбеков мутирующих общий стейт — она не сильно способствует появлению реюзабельных кусков кода вообще.
Что-то, мне кажется, тут смешались в кучу кони и люди. Будете писать лапшу из колбэков, будет лапша. Не будете — не будет. Тут парадигма ангуляра ни при чем.
Единственное, в чем вы правы — в React сразу побеспокоились о рекомендованных лучших практиках в разработке приложений. В AngularJS это решили отдать на откуп самим разработчикам.jakobz
08.01.2016 16:07+1Речь не о
<some-cell-type param1="..." param2="..."></some-cell-type>
а о
<my-grid ng-model="vm.items"> <my-column name="Name">{{ row.name }}</my-column> <my-column name="Value"><input ng-model="row.value"/></my-column> </my-grid>
У меня там вырисовывалась редактируемая табличка, в 20-ти местах. Везде разные наборы колонок, и всякие там разные input-ы в ячейках. Но везде у них одинаковый внешний вид, много где одинаковые кнопки типа «стереть строчку», и прочие общие фичи типа сортировки.
Я не смог этот компонент абстрагировать до конца. Бросил вроде на том, что не смог понять почему валидация не просасывается. Но и на тот момент было понятно что слишком много магии для продакшна — там приходилось всячески хакать контексты, и динамически компилировать шаблоны. И если что-то бы там сломалось, потребовались бы дни чтобы разобраться.Fesor
08.01.2016 16:15У меня там вырисовывалась редактируемая табличка, в 20-ти местах.
А проблем с UX это не вызывает?
Вообще такие штуки проще решать конструкторами форм вроде angular-formly и т.д.jakobz
08.01.2016 16:31+1А какие проблемы с UX может это вызвать?
Angular-formly вообще прекрасен — оно же заменяет ангуляр на свой eDSL на JS, по дороге теряя всю гибкость.
Bronx
12.01.2016 11:15+1Отдельные редактируемые ячейки, да ещё и со сложной логикой валидации — сам по себе спорный UX. Формы и кнопку Save/Apply/Submit не просто так придумали, они позволяют откладывать валидацию и не заваливать юзера преждевременными сообщениями об ошибке ввода, и вообще упрощают жизнь. Я бы делал нормальную форму для целой строки таблицы, а не для отдельных ячеек. Её можно сделать inplace, если хочется. Проблем с прокидыванием валидации через весь грид не будет, так как вся валидация в единственной активной ng-form, и она не должна быть частью грида, а должна быть отдельным компонентом на странице. Проблем с дублированием тоже [почти] нет: хоть и придётся для каждой таблицы делать два шаблона (для строки статического текста и для строки редактирования), но они весьма отличны функционально, и разделение режимов вывода/ввода на уровне шаблонов позволяет менять редактор, не заботясь о том, что поломается вывод. Например, замена inplace form на flyout, или на sidebar, или на modal становится элементарным действием, совершенно не затрагивающим грид.
Fesor
07.01.2016 20:05Самое смешное — что в проекте на ангуляре 100%-е покрытие, а на react+typescript — считай что 0%-е. При этом в ангуляре регрессий драматически больше.
И о чем это говорит? О том что тесты кривые? О том что метрики покрытия кода считаются неадекватно? Вы через DOM тестируете или нормально?
В ангуляре получается больше копипасты, потому что директивы — гораздо слабее чем компоненты реакта. По нескольким причинам: API компонент ограничен простыми структурами, твои компоненты обязаны поддерживать очень нетривиальные механизмы датабиндинга, вокруг директив очень много магии.
Ммм… иногда приходится впиливать кастыли (пример, посмотрите к слову этот простенький todomvc) из-за дурацкого двустороеннего датабиндинга. Самый популярный вариант (и тот на котором я пожалуй остановлюсь в скоре) — это обертка над API компонентов, появившаяся в версии 1.5. В частности брать параметры биндинга для директивы и добавлять в link отслеживание изменений и копирование данных в контроллер. Звучит страшно но это можно сделать как прозрачную фигню которая решает миллион проблем.
И никакой магии там нет. Оно посложнее компонентов реакта но в принципе на angular 1.5 все с этим хорошо.
Кроме того, копипасте в ангуляре прекрасно способствует его IoC с модулями: они банально создают лишнее «трение» на вынос общего кода наружу.
Поясните мысль. Пока это звучит как «штука для управления зависимостей заставляет разработчиков разбираться в ней и потому люди копипастят код вместо того что бы выносить все в сервисы».
Ну и сама парадигма ангуряра — императивная, jQuery-style, лапша из колбеков мутирующих общий стейт
Это ни в коем случае не «парадигма ангуляра». Это видимо то как готовили ваш проект вы или разработчики до вас.
Angular с первых версий вводит понятие декларативных шаблонов. То есть у вас отдельно есть viewmodel в которую экспоузится часть состояния, и UI (шаблоны) за счет биндингов реагируют на изменения и подстраиваются. Дальше — можно уже по разному. Можно мутировать состояние прямо в контроллерах, можно прокидывать изменения через сервиснй слой и обновлять стэйт сверху (как это реализовано в redux) ну и т.д.
По асинхронщине — все на промисах. Если вы babel используете то с async/await все вообще превращается в сказку. О чем вы вобще. Были определенные проблемы с версией 1.0 и т.д. но в 1.2 с введением .finnally и controllerAs большая часть проблем устранилась.
Самая большая проблема ангуляра, которую я могу наблюдать — разработчики в основном берут его потому что это модно. Ну то есть человек не может сказать что такое замыкание но уже начинает активно разбираться с реактами или ангулярами. В итоге да, первый год он будет говнокодить. И с ангуляром это сделать чуточку проще поскольку… оно будет работать. С другой стороны реакт предоставляет больше степеней свободы и за счет этого можно сдуру сделать все плохо так же легко как и в ангуляре.
serf
05.01.2016 23:37-3Так вроде давно понятно, React для стартапиков и гиков всяких которые любят разводить зверинец и тащатся от всяких модных базвордов. Angular для коплексных длительных проектов, возможно того самого интерпрайз уровня, с более высоким порогом вхождения, диктует структуру и самодостаточен, что полезно во многих ситуациях.
zorro1211
06.01.2016 06:15+2github.com/facebook/react/wiki/Sites-Using-React среди этих компаний никто так и не дотянул инерпрайз уровня, судя по вашим словам.
serf
06.01.2016 07:40-5похоже что нет, даже само слово «sites» указывает на это, интерпрайз обычно это приложения/проекты как правило разрабатываемые для крупных компаний, а не сайты
denis_g
06.01.2016 10:01+1А зачем приложению/проекту без сайта клиентский веб-фреймворк? /* здесь картинка с размышляющим динозавром */
faiwer
06.01.2016 10:30Гхм. А что вы понимаете под сайтом? Положим интерфейс какого-нибудь кофе-шоколадо-автомата с тач-экраном назовёте сайтом? Или инфо-киоск? А в таких проектах удобно применять подобные технологии. Они позволяют быстро и удобно развернуть сложный UI.
Часто наблюдаю web-UI и в качестве ПО для операторов будь то банков, каких-нибудь центров по обслуживанию населения и пр. органов. Сам уже 3-ий год пишу закрытое ПО с web-UI для гос. органов.
Delias
05.01.2016 23:47-1Тоже начинал переводить эту статью, потом забил после тезиса
Angular 2 не требует TypeScript, но команда разработчиков продолжает использовать его, по умолчанию, в документации. Это означает что проекты с открытым исходным кодом и соотвествующие примеры делают код более однообразным.
Для меня это и есть минус, я не хочу погружаться в TypeScript, изучать его тонкости и бэст практики, в преддверии ES6го по-моему это бессмысленное занятие. Но большая часть документации сейчас как раз на TypeScript и я так понимаю команда будет продолжать его драйвить. Вообще не понимаю этой дружбы разработчиков Гугла с технологией от Майкрософт. Как такое могло получиться? :)serf
06.01.2016 00:00+12Вообще не понимаю этой дружбы разработчиков Гугла с технологией от Майкрософт. Как такое могло получиться? :)
Это свободная и полезная технология, зачем себя ограничивать рамками слепой «религии».
Вот что точно глупо так это к примеру использовать кофискрипт в наше время, но упоротые специалисты продолжают о чем-то спорить.Shance
06.01.2016 19:29не срача ради, сам давно перестал использовать кофескрипт, но почему вы с такой уверенностью утверждаете, что он нынче моветон?
serf
06.01.2016 19:30-2потому что уже есть es6 который стандарт
Fesor
06.01.2016 20:30а как же es5 который раньше был стандартом?
serf
06.01.2016 21:01-2раньше не было es6 и тогда кофи кому-то был полезен, сейчас есть стандарт который перекрывает кофи => в настоящее время кофи не нужен и вреден.
hats
07.01.2016 03:29+3Честно говоря, давно не понимаю при чем здесь CoffeeScript, ES2015 и =>.
Неужели им столько людей пользовалось только из-за =>?
А как же классный python-like синтаксис? И ненадобность писать море лишних скобочек и ;? Или проверки возвращаемых методами значений через знак вопроса? Строгое сравнение по-умолчанию? Или @ вместо this?
Это я все к тому, что кто бы там что не говорил, но за CoffeeScript всегда стояли best practices написания кода на JS и никакой ES2015/16/17 их привнести не сможет.
Поэтому я надеюсь, что команда CS не опустит руки и все у них будет отлично :)serf
07.01.2016 21:22Все верно, вполне возможно что кофи сыграл свою роль при разработке стандарта, и теперь ему пора на заслуженный покой.
Fesor
07.01.2016 20:08fat-arrow функции и сахар для объектов это пожалуй самые популярные фичи но далеко не самые полезные. И их в ES6 нет.
Проблема кофе и почему я его так не люблю — потому что эти самые фичи люди очень бездумно начали использовать. Ну и без модулей еще к тому же. Те же fat-arrow выражения начали делать как замену нормальным функциями. Это же так сложно написать лишних парочку символов.
Короче кофескрипт это была хорошая штука, и я думаю еще что-то будет подобное, но ИМХО плохо оно не потому что концепция гнилая, а потому что разработчики склонны не верно использовать предоставляемые им фичи (оверюзить если хотите).serf
07.01.2016 21:20Так дело ведь не в том что гнилая, она таковой стала ввиду прихода es6, сам по себе кофи ведь не плохой, это ведь прогресс в конце концов, но просто кофи уже не рационально использовать для новых проектов, не оправданно, а инжерены ведь обычно принимают програтичные и просчитанные решения.
Fesor
07.01.2016 22:16она таковой стала ввиду прихода es6
Спор в этой ветке как раз о том что кофескрипт — не гнилой. Он просто не актуален конкретно сейчас. И развивать именно кофескрипт насколько я помню не планировали, а адаптировать недостающие фичи для ES6-7 плагировали уже в рамках другого проекта.
Вообще никто не мешает взять babel6 и реализовать плагины добавляющие недостающий функционал. Эпоха транспайлеров.
sl_bug
06.01.2016 22:07Вам глупо, так и не используйте :) Я тоже многие вещи глупыми считаю, но молчу же
serf
06.01.2016 22:11-1Бывает мнение, а бывает объективная действительость, так вот про кофи это действительность. Я понимаю если проект уже давно в разработке на кофи, но есть ведь деятели готовые писать новые проекты на кофи, утопия.
sl_bug
06.01.2016 22:14+1т.е. вместо coffeescript мне использовать babel? зачем?
JCHouse
06.01.2016 22:17Затем что однажды, я верю что в недалеком будущем, транслятор кода можно будет отключить, так как бабель просто реализует то что уже в спецификации. А как вы отключите транслятор кофискрипта?
sl_bug
06.01.2016 22:23-2www.airpair.com/coffeescript/posts/migrating-coffeescript-to-es6-javascript
tech.noredink.com/post/111583727108/dont-replace-coffeescript-with-es6-transpilers
З.Ы. И я не верю что в ближайшие лет 5 ES6 будет во всех браузерах (и реализован одинаково)
serf
06.01.2016 22:21Мне казалось причина очевидна, потому что через некоторое от трансляции es6 кода в es5 (babel) можно будет отказаться и написанный es6 код будет работать нативно в браузере тк это стандарт. Отсюда вытекает вредность использования кофи в новых проектах. Если уже хочется транслировать код, то почему не взять тайпскрипт, он может все что кофи и es6 + уникальные/полезные и при этом опциональные фичи.
sl_bug
06.01.2016 22:25Ну вот не нравиться мне тайпскрипт. На остальное ответил выше.
serf
07.01.2016 21:25мне не нравится ответ для пет-проектов, в коммерческой разработке обычно решения принимаются на несколько другой основе, но это совсем не говорит о том что эта технология должна быть навязана всем поголовно, я тоже стараюсь не делать того что мне не нравится насколько получается, выбор то есть.
symbix
06.01.2016 19:51Очень просто получилось: ангуляровцы стали развивать (вроде бы на основе Traceur Compiler) свое надмножество TypeScript под названием AtScript, разработчики TypeScript заинтересовались спецификацией и быстро добавили в TS то, чего разработчикам Angular не хватало, те возрадовались, что не надо пилить свой велосипед, и перешли на TS.
Fesor
06.01.2016 20:33я не хочу погружаться в TypeScript, изучать его тонкости и бэст практики
прежде чем делать какие-либо выводы, хотя бы почитайте что такое TypeScript. Если коротко — это ES6/ES7 + информация о типах (ну и интерфейсы). Причем последние два пункта — сугубо опциональны, влияют только на качество статического анализа, автокомплиты и т.д. Никакого нового синтаксиса (кроме нотаций типов) там нет. Все строго по стандарту.
Так что зная ES6 — нет никаких проблем с чтением TypeScript.
serf
05.01.2016 23:50Для меня это и есть минус, я не хочу погружаться в TypeScript, изучать его тонкости и бэст практики, в преддверии ES6го по-моему это бессмысленное занятие.
Почему бессмысленно если в целом TypeScript это и есть ES6 (JavaScript код сам по себе уже будет являтся валидным TypeScript кодом) + другие уникальный фишки — тайп сейф, статическая типизация (разумеется не в рантайме), TypeScript доплняет ES6. Хотя безхусловно при плотном использовании TypeScript теряется некоторый «шарм» — привычка держать все в голове работая с JavaScript.
vintage
06.01.2016 00:50-1Поделюсь-ка я некоторыми своими наработками :-)
Вот размеры упомянутых библиотек/фреймворков, минифицированные:
Ember: 580k
Angular 2: 565k (759k with RxJS)
React + Redux: 204k
Angular 1: 145k
В на моих колёсах ToDoMVC целиком (вместе с «фреймворком») занял 60 неминифицированных килобайт. Всё это благодаря простой реализации (как следствие мало кода) и микромодульной архитектуре (подключаются только те модули, что реально используются). Я это к чему: что Angular, что React — это жирный такой «bloatware», а никак не «unix-way».
Angular 2 продолжает помещать JS в HTML. React же помещает HTML в JS
И то и другое — плохо. Хотя, конечно, второе чуть менее плохо, чем первое. Почему это плохо — вы не можете разделить работу верстальщика и работу программиста. Верстальщику неизбежно приходится программировать. Кроме того, у вас появляются проблемы с не html компонентами. Например, фигуры на canvas или нативные контролы. Для сравнения, вот декларативная реализация простейшей компоненты, предоставляющей 3 слота. А тут тесты для вёрстки, чтобы окинув страницу со всеми вариантами можно было понять всё ли свёрстано верно. И это без единой строчки кода, без единого ветвления или условного перехода. Такое описание компонент транслируется в TypeScript, который при компиляции проверяет типы, так что компоненте нельзя передать параметр, который она не предоставляет. Для каждой компоненты генерируется таким образом класс, который может быть расширен уже программистом на тайпскрипте — тут уже добавляется вся логика, циклы, условия и тп. Получается довольно простая, но очень мощная архитектура.serf
06.01.2016 01:12И то и другое — плохо. Хотя, конечно, второе чуть менее плохо, чем первое.
Почему «второе чуть менее плохо, чем первое» если во втором случае верстальщик залезет в ваш JS код с логикой и будет там копаться (все ведь в одном файле), а если шаблоны в отдельных html файлах, то там верстальщики и будут работать и кода как правило в html не много и выглядит он как атрибуты (что полагаю понятнее и привычнее для верстальщиков), а не чистый JS код.vintage
06.01.2016 01:23+1В JSX его никто и не пустит. Да он и сам не полезет, ибо там матёрый JS. А лучше в том смысле, что не изобретает свой кривой синтаксис для логики как Angular, а просто берёт полнофункциональный JS/TS.
JCHouse
06.01.2016 01:26-2Это ж где вы нашли отдельно джисеров от верстальщиков в одностраничном приложении? Я уже лет 5 как такое в принципе не встречал. Хотя вот недавно был случай в Magenta увидел такую расстановку, но они тоже понимают ущербность этого пути и старательно работают над интеграцией команд.
serf
06.01.2016 01:31+2Допустим когда работаешь в распределенных командах, удаленно, такое случается. Я к примеру не люблю верстать и предпочитаю что-бы кто-то другой этим занимался, хотя часто потом приходится адаптировать сверстанное к структуре проекта.
JCHouse
06.01.2016 01:36Именно, чтобы не тратить время на адаптацию все и отказываются от отдельных верстальщиков. И в Яндексе и в моей нынешней команде верстают только дизайнеры. И то в рамках посмотреть как оно будет в браузере.
serf
06.01.2016 01:43Мне не важно как они называются, дизайнеры или верстальщики, суть в том что не я. Сам верстаю обычно только когда делаю новые фичи, там верстки как правило не особо много. А адаптация обычно происходит один раз на начальном этапе, когда верстается «база» проекта.
JCHouse
06.01.2016 01:53О нет код после дизайнеров нельзя использовать на проде. Это в моем частном случае:) они же генерируют его из графических редакторов в XHTML например.
vintage
06.01.2016 01:43Отказываются потому, что инструменты не рассчитаны на разделение этих работ. То HTML в JS, то наоборот. А верстальщику-то для работы нужно просто набросать макет, чтобы видеть, что он верстает. А чтобы потом не «адаптировать» и нужно, чтобы программный код мог цепляться к этому, верстальщикоориентированному макету. Пример, как это можно сделать, я привёл выше: верстальщик использует простой декларативный синтаксис для создания и использования компонент, а программист либо наследуется от них, либо их агрегирует.
JCHouse
06.01.2016 01:51Пример проекта есть или библиотека с таким подходом мне сложно понять такое на пальцах. А было бы интересно посмотреть.
vintage
06.01.2016 02:01Я же ссылки там навставлял: демо-страничка компонента, её исходники.
JCHouse
06.01.2016 02:10И где же там отдельная работа верстальщиков? Или это уже о другом?
vintage
06.01.2016 02:26Везде, эта компонента целиком «создана верстальщиком». Точнее там две компоненты:
$mol_panel — использует компоненты $mol_block и $mol_scroller
$mol_panel_demo — компонента, которая демонстрирует компоненту $mol_panel в различных состояних, используя для этого компоненты из модуля $mol_demosl_bug
06.01.2016 02:52+8Как «не верстальщик» и не «фронтенд разработчик» считаю это все ужасом :)
vintage
06.01.2016 02:57Вас же не затруднит рассказать почему?
sl_bug
06.01.2016 10:49+2Внешне это выглядит как каша непонятно чего. Понять это без ящика водки не реально. Это если кратенько :)
vintage
06.01.2016 11:10+1Как, собственно, и с любой незнакомой технологией. Хотя, можно и догадаться, там же всё наглядно:
Комбинация вида "< head" возвращает значение свойства «head». Всё, что начинается с "$" — имя компоненты. На первом уровне вложенности имя компоненты — это её объявление, на остальных уровнях — использование. При использовании можно переопределять любые свойства. ":" — предикат эквивалентности. Вот и все идиомы.
$mol_panel : $mol_block child < header : $mol_scroller content < head : null < bodier : $mol_scroller content < body : null < footer : $mol_scroller content < foot : null
Тут мы объявляем компоненту $mol_panel как расширение компоненты $mol_block и перегружаем свойство child в которое засовываем список из значений 3 свойств: header, bodier, footer, каждое из которых имеет значение по умолчанию, являющееся расширением компоненты $mol_scroller у которого свойство content перегружено соответствующим свойством из $mol_panel: head, body, foot; каждое из которых имеет пустое значение по умолчанию.
Пример использования:
$mol_panel_demo : $mol_panel head : =Lorem Ipsum body : $mol_demo_lorem footer : null
Тут мы объявляем компонент $mol_panel_demo, как расширение $mol_panel, где в шапке выводится просто текст, в теле компонентой $mol_demo_lorem рисуется портянка текста, а подвала вообще нет.JCHouse
06.01.2016 11:39+2По вашему это проще чем нативный JS и HTML? У нас разные понятия о простоте:) Реакт на столько прост и удобен что наши Джависты без напряга начинают на нем писать на второй день.
vintage
06.01.2016 11:55Ну что ж вы так голословно-то? Как эквивалентный код будет выглядеть на реакте? С наследованием компонент, перегрузкой свойств (причём именно свойств, а не их значений, то есть и геттер и сеттер), автоматической генерацией css-классов в БЭМ нотации, быстрым доступом к инстансу компоненты из консоли.
Ремарку про свойства проиллюстрирую следующим примером:
$mol_panel_demo : $mol_panel head < title : =Unnamed page body =Enter page name, please: $mol_stringer value < title footer : nullJCHouse
06.01.2016 12:11+3Ну так это не нативный синтаксис:) Как раз называть этот треш интуитивно понятным вот настоящее голословие.
vintage
06.01.2016 12:16То есть более простого и интуитивно понятного кода я от вас не дождусь? Жаль, а то я уже приготовился закапывать свой велосипед.
JCHouse
06.01.2016 13:35Еще раз, ваш подход непонятен без объяснения, и не мне одному, просто попробуйте дать его неподготовленному человеку. В принципе это уже видно из комментариев выше, где вы объяснили что происходит:) На React это будет выглядеть примерно так:
<html> <Head title={this.state.title}> <body> <input onChange={this.handleChange}> <body> </html>
Проще и понятнее? Однозначно:) Доступ из консоли, не вопрос. БЭМ генерация классов, ок это задача на два метода.
А вот умеет ли ваш велосипед строить виртуальный дом и обновлять только измененные компоненты без обновления всего компонента?vintage
06.01.2016 14:15Было бы странно, если бы новый подход был понятен без объяснения. Иначе бы в нём не было новизны, не находите? Разница лишь в том, что тут все принципы укладываются в один абзац текста, а в случае, например, Ангуляра постоянно приходится копипастить волшебную строку для итерирования из документации, хотя и год на нём писал приложение.
Вы привели простой статический шаблон, единственный способ кастомизировать который — скопипастить и изменить. Реализайте аналог $mol_panel. Это простейший виджет, рисующий шапку, тело и подвал с ограничениями по размерам и скроллингом при переполнении. При этом он не конкретизирует, что именно должно быть в шапке теле и подвале — это даётся на откуп пользователя, который в момент создания виджета решает что туда поместить. Сможете сделать это проще и понятней?
Моему велосипеду не требуется виртуальный дом, так как он и так знает где что надо поменять. Также как и KnockOut.sl_bug
06.01.2016 14:24+1facebook.github.io/react/docs/more-about-refs.html все что вы описали только что
vintage
06.01.2016 14:34Там о том, как получить ссылку на отрендеренный элемент. При чём тут это?
sl_bug
06.01.2016 14:43+1Да блин. Вы просите поместить в какой-то компонент друге компоненты. И все. раз, два, три. Выбирайте.
vintage
06.01.2016 15:09Вы не злитесь, а постарайтесь понять о чём я говорю. По вашим ссылкам есть много запутанного кода, которой, однако, делает совсем не то. Если React вам кажется проще, то в чём сложность реализовать аналог $mol_panel и $mol_panel_demo? У меня они заняли всего 8 строк кода. На реакте это наверняка займёт не больше 5.
napa3um
06.01.2016 14:55+1А вот умеет ли ваш велосипед строить виртуальный дом и обновлять только измененные компоненты без обновления всего компонента?
Патчинг DOM'a дельтами изменений, вычисленных от предыдущего и целевого состояния DOM'a — костыль, следствие наложения «протекающей абстракции» (по Спольски) React'а, очень похожей на «классический PHP» и являющийся, по-сути, реализацией архитектуры тонкого клиента (отрисовываем состояние страницы/компонента с нуля для простоты логики этого самого клиента и его алгоритмов отрисовки) на семантику DOM'а (имеющего собственное состояние, что противоречит «отрисовке с нуля»). Отсутствие этого костыля в каком-то фреймворке не говорит об ограниченности данного фреймворка — возможно, идеям этого фреймворка просто не нужны такие костыли для совместимости с моделью DOM.JCHouse
06.01.2016 15:12Мы не рассматриваем «какие-то фреймворки» мы сравниваем конкретные части конкретных библиотек.
fetis26
06.01.2016 01:45-1вы не можете разделить работу верстальщика и работу программиста
Не знаю, не знаю. Нет больше никаких верстальщиков. Есть фронтенд разработчики. Если человек не может писать код, значит ему надо подучиться. Идет тенденция проектирования сложных систем не от дизайна экранов, а от библиотеки компонентов, из которых уже без дизайна эти экраны составляются. И получается никаого разделения верстальщик/программист не нужно.vintage
06.01.2016 01:54+2Вот именно вёрстка и кроссбраузерная стилизация этих библиотек компонент и делегируется верстальщикам. Кроме того, составление страницы из библиотечных блоков тоже может быть делегировано верстальщику, а дорогой программист уже подключается для добавления динамики. Ну и, конечно, далеко не все дизайнеры/заказчики такие современные, что рисуют/принимают визуальные библиотеки, а не уникальные страницы.
JCHouse
06.01.2016 01:55Я все таки считаю в одностраничном приложении это практически невозможно.
vintage
06.01.2016 02:04+1Ещё как возможно, особенно при использовании ангуляра, где создавать директивы на каждый чих напряжно, так что просто берут и копипастят для каждого экрана приложения отдельный шаблон с полным фаршем внутри.
serf
06.01.2016 07:53Ещё как возможно, особенно при использовании ангуляра, где создавать директивы на каждый чих напряжно, так что просто берут и копипастят для каждого экрана приложения отдельный шаблон с полным фаршем внутри.
В моем случае наоборот копипастить напряжно, потом оно аукнется, так что на каждый чих новая директива (или если простое что-то, то просто кастомный инклуд), совсем не напряжно. Зачем тогда использовать ангуляр если не структурировать код согласно его модели.
vladar
12.01.2016 11:51А вот скажем в iOS или Android приложениях — там тоже делегируется верстальщикам? HTML+CSS с разделением на программирование и верстку — это только один из способов создания UI, но далеко не единственный.
Причем этот подход теряет эффективность по некой функции от количества взаимодействий с пользователем в интерфейсе.Fesor
12.01.2016 17:00А вот скажем в iOS или Android приложениях — там тоже делегируется верстальщикам?
Ну да, а в WEB уже есть что-то такое же удобное для построения UI как андройдовские лэйауты (или из iOS), или может быть у WEB появились жесткие гайдлайны как делать дела? Или может быть нативные какие-то элементы?
Для web ситуация намного сложнее и интереснее чем для мобильников. Скажем для iOS никаких проблем с UI вообще небыло до появления всех этих 6+ и ipad mini/pro. И то проблемав iOS9 полностью решена схожими штуками как и в android.
Isopropil
06.01.2016 01:14-11Сам люблю Реакт. А тайпскрипт — поделка MS, что и отпугивает, и предостегегает от его использования. Ну не сделали они ничего хорошего.
shuron
06.01.2016 02:22+3Вопреки тому что это майкрософт. Typescript получися отличный. Прошел их тоториал. Офиггенно. наконецт нормальный язык для веба.
Гугл сним дружит и с ангуляр2 выглядит очень классно.
stalkerg
06.01.2016 01:20<ul> <li *ngFor="#hero of heroes"> {{hero.name}} </li> </ul>
Ухожу в монастырь:
for(var i=0; i < heroes.length(); i++) { var li_element = document.createElement("li"); li_element.textContent = heros[i].name; ul_element.appendChild(li_element) }vintage
06.01.2016 01:27+2Добавьте сюда ещё аттрибутов, обработчиков событий, инкрементальный рендеринг и попробуйте делегировать задачу верстальщику.
stalkerg
06.01.2016 02:04К слову о птичках (верстальщиках):
попробуйте делегировать задачу верстальщику
в React это как решается с их JSX?
А вообще мало где видел, что бы в процессе разработки OPA встречался верстальщик, давно одни Frontend разработчики (а то и Fullstack).
JCHouse
06.01.2016 01:28Простите, вы неверно поняли суть этих фреймворков, это не просто шаблонизаторы.
Shablonarium
06.01.2016 04:00JSON уже победил XML, осталось добить его братца по скобкам.
Не понимаю зачем react смешивают с HTML, когда можно взять JSON и потом транслировать в разметку.
JCHouse
06.01.2016 06:47JSON это формат передачи данных сделанный для экономия места относительно XML, как сделать без скобочек нормальный парсинг из строки? Вот предложите.
vintage
06.01.2016 10:50Проблема в том, что модель данных JSON (списки+словари) плохо подходит для описания деревьев (типизированные узлы, содержащие списки узлов). В статье со сравнением разных форматов подробности в разделе про AST.
faiwer
06.01.2016 07:07Было бы интересно почитать сравнение React, AngularJS и… KnockoutJS. Последний активно использую уже 3-ий год. Всё время поглядываю в сторону AngularJS, даже прошёл tutorial для 1.х версий. Но… Никак не могу найти реальных причин использовать его вместо KnockoutJS. Да и, честно говоря, привык к более ограниченным, не таким всеобъёмлющим инструментам. Которые решают одну или несколько задач, а не все сразу.
Глядя на React прихожу в замешательство. Я так и не понял сути этой библиотеки. Механика knockout или angular binding-ов мне ясна. Она лежит на поверхности и кажется более, чем логичной и очевидной. Но вот перерисовка HTML, исходя из поиска разницы в итоговом HTML, это что-то очень странное. Я так и не смог понять ? зачеем? Механизм состояний… Я постоянно натыкаюсь на статьи с хвалебными отзывами о React и мне кажется что я упускаю что-то то очень большое и важное о нём, и поэтому вообще не понимаю его сути.serf
06.01.2016 08:01Но вот перерисовка HTML, исходя из поиска разницы в итоговом HTML, это что-то очень странное
А вам не обязательно это понимать, это просто техническая деталь которая призвана оптимизировать перформанс перересовки dom дерева. Просто не обращайте на этот момент внимание и подумайте есть ли что-то что вам может быть полезно в самой стурктуре и подходе (собирать приложение из разрозненных компонентов) предлагаемой риактом. Да название «риакт» видимо историчеки пошло отсюда (нужно ведь как-то было привлеч внимание), но в данное время это просто техническая деталь, которая (virtual dom) уже реализована в очень многих современных фреймворках как элемент оптимизации. К тому же «скорость» далеко не всегда главный критерий выбора инструмента.
dzugaru
06.01.2016 08:34Если вам нужно создавать *очень* большое количество динамических контролов и не хочется писать для них каждый раз методы render и update, да еще и если между ними всякие сложные связи и зависимости, основаные на собыиях и смене состояний, то React снимает чудовищное количество головной боли.
Плюс React своей самой парадигмой подталкивает к тому, чтобы правильно продумывать компонетную модель и эти компоненты обходятся почти бесплатно и с минимумом бойлерплейта.faiwer
06.01.2016 09:14+1и не хочется писать для них каждый раз методы render и update
и с минимумом бойлерплейта
Разве это не относится ко всем фреймворкам этой «волны»? В чём фишка непосредственно React-а? К примеру меня смущает то, что даже для изменения одного аттрибута тега, он будет рендерить шаблон целиком. А чтобы это не тормозило, то делать он будет это не наживую, а на detached-копии, найдёт разницу и применит её в нужное место. Гхм. А зачем?
Я глубоко не копал, но поверхностными соображениями пришёл к выводу, что такой подход позволяет иметь меньше дорогостоящих привязок. Тогда получается что вся суть React-а в производительности?
В случае KnockoutJS, принцип работы несколько иной. Положим у нас есть биндинг, задающий класс исходя из каких-либо условий. Например data-bind=«css: {opened: isOpened}». Где isOpened это ko.computed из viewModel-и. Которая в свою очередь вычисляется исходя из какой-либо бизнес-логики. В итоге когда isOpened пересчитывается, она автоматически уведомляет всех подписчиков (включая биндинг css этого тега). Подписчики что-нибудь выполняют. Данный биндинг добавит или уберёт css-класс «opened». Т.е. рендерить весь шаблон не пришлось. Вызвать руками render или update тоже. По сути бизнес-логика хорошо изолирована от шаблона. В JS-коде мы оперируем объектами, реализовываем всё что угодно и как угодно. «Наблюдатель» всё обновит и определит сам, без ручного вмешательства. И обновит сразу по месту назначения. Этим knockout мне очень нравится.
Правда на «*очень* большое количество динамических контролов» KnockoutJS будет люто тормозить. Этого нельзя не учитывать. Но мне всегда казалось, что огромное кол-во HTML-а ? это уже специфика. В том числе и для SPA.JCHouse
06.01.2016 09:31Вся суть как раз в том что он НЕ рендерит весь шаблон, а тольку ту часть которая зависит от измененного состояния.
faiwer
06.01.2016 10:03Почему-то во всех ознакомительных статьях самое важно упоминает вскольз. В итоге совершенно не ясна суть технологии.
Вот у меня есть шаблон. Он состоит из некоего HTML-а, где есть использование данных из модели. Положим нас интересуют 4-5 переменных.
В рамках HTML, какие-то переменные используются для css-классов, какие-то для аттрибутов, какие-то определяют видимость, какие-то задают innerText, ну и т.д.
И вот в рамках бизнес логики мы изменили одну из переменных. В случае knockout-а я просто задаю новое значение этой переменной. В случае React-а я должен поменять состояние. Так? Состояние изменяется целиком? В примерах я вижу «setState». Т.е. именно им я меняю состояние?
Ок. Состояние изменилось. Что делает Knockout? Он уведомляет всех подписчиков этой переменной, а что они будут делать — решают сами. Раз мы говорим только о view (ведь React это только view? верно?), то в рамках knockout-а мы говорим об HTML-биндингах. Они являются обычными подписчиками, как и любые другие. Получают новое значение и могут с ним что-угодно сделать. Биндинг CSS уберёт или добавит нужный класс.
Что сделает React? У него есть Shadow DOM. Будет ли этот Shadow DOM полностью перерендерен? Или только та крошечная часть (допустим добавился css-класс), которая зависела от изменения той самой единственной переменной в состоянии? Если 2-ое, то получается React хранит все зависимости в удобно виде, кои получается при рендере шаблона. Он так делает? Если он так делает, то получается, что он точно знает, что изменилось и сравнивать HTML в DOM и Shadow-DOM нет никакого смысла. Можно просто сразу накатить точечное изменение. И зачем тогда Shadow DOM был нужен? Зачем накатывать его на кошках, чтобы потом заюзать в деле?
Если же он всё таки в Shadow DOM рендерит всё целиком (ну или хотя бы целиком только 1 тег), а затем сверяет различия с реальным DOM (перебирает все аттрибуты, их значения, innerText и пр.?) и точечно накатывает различия… То в чём фишка? Предполагаю, что фишка может быть в быстродействии. Ведь тогда получается что никаких схем связей элементов состояния с HTML он не хранит, и накладных расходов на их содержание и поддержание у него нет. Но приходится вот так вот извращаться. В этом фишка?
Из статьи к статье пишут невесть чего. И даже примеры мне не дали понять сути. Заостряется внимание на том как удобнее писать, код меняющий state и пр… Но почти ни слова о сути. Хотя может быть я просто на такие материалы натыкался.
В случае Knockout-а я не оперирую никакими состояниями. По сути я просто пишу бизнес логику в чистом виде. Как мне удобнее. Про HTML я просто забываю. Он второстепенен. Точнее даже, его может не быть вовсе. Если HTML нужен, то я пишу HTML разметку и расставляю в нём биндинги. Чем декларативнее и примитивнее это будет сделано, тем правильнее. Затем возвращаюсь к бизнес-логике и продолжаю в ней шуровать. Объектная модель которую я при этом использую моё личное дело. По сути то, что в React называется состоянием, видимо, в случае Knockout-а и Backbone это просто модель. Т.е. состоянием является всё, кроме HTML-кода. Оно не вынесено в отдельную сущность.
В случае React-а получается, что модель идёт отдельно? И модель должна при необходимости влиять на состояние view-и, чтобы React сделал всю скучную работу сам?sl_bug
06.01.2016 10:48Если вам очень нужно понять как реакт работает внутри, то предлагаю почитать исходники. Лучший вариант чем читать статьи и не понимать.
faiwer
06.01.2016 16:23Если вам очень нужно понять как реакт работает внутри
Не представляю как можно пользоваться технологией не имея базового представления о том, как она работает.
то предлагаю почитать исходники
Далеко вы меня послали. Бегло проанализировать сотни килобайт кода? :) Мне кажется тут хватит пары «да, именно так», «нет, совсем не так» и «почти, но …» применительно к комментарию выше.
JCHouse
06.01.2016 11:10Это слишком много текста, попробуйте поставить и через вебинспектора глянет что и как он изменяет, в вебкит есть подсветка измененных компонентов в реальном времени. Фактически он строит виртуальное дерево, сравнивает с построенным и те части которые отличаются обновляет.
faiwer
06.01.2016 16:20А вы мой комментарий читали? Или «слишком много текста»? Я там задал конкретные вопросы. Конкретные логические цепочки, которые можно подтвердить или же опровергнуть.
dzugaru
06.01.2016 18:53+1>Вот у меня есть шаблон. Он состоит из некоего HTML-а, где есть использование данных из модели. Положим нас интересуют 4-5 переменных.
Вы раз за разом задаете неправильный вопросы и пытаетесь получить на них ответы. В рекате нет понятия шаблонизаторов. В рекате нет понятия биндингов на шаблоны. В реакте нет понятия view.
Реакт это не DSL, не шаблонизатор, и не MVC фреймворк в традиционном его смысле, это парадигма чистых компонентов и в этом плане он гораздо ближе к обычному vanilla js, чем скажем, к тому же ангуляру.
kant2002
07.01.2016 06:14+11.
В случае knockout-а я просто задаю новое значение этой переменной. В случае React-а я должен поменять состояние. Так? Состояние изменяется целиком?
Да, действительно в React надо менять одно свойство состояния. Дерево зависимостей между различными свойствами одной бизнес-модели надо самостоятельно отслеживать и не забывать обновлять при изменении одного свойства, другие измененные свойства модели. Когда меняешь одно свойство состояния через setState все остальные свойства остаются прежними, поэтому setState это своего рода указание изменений в состоянии.
2.Что сделает React? У него есть Shadow DOM.
у React используется Virtual Dom (не стоит путать с Shadow DOM, что само по себе тема для отдельной дискуссии). Сам по себе Virtual DOM нужен для достаточно эффективной перерисовки HTML DOM. Сравнивается тот DOM который уже был, с тем который стал после вызова setState, находятся изменения между этими DOM выраженные в изменении свойств HTML элементов (как позиционирования, так и CSS стилей, и другого). Таким образом появляется список изменений которые надо сделать на реальном DOM.
3.Если 2-ое, то получается React хранит все зависимости в удобно виде, кои получается при рендере шаблона. Он так делает?
Это не так, React не хранит никаких зависимостей тех или иных частей DOM от тех или иных свойств состояния. Состояние компонента используется только для формирования нового DOM компонента.
4.Если же он всё таки в Shadow DOM рендерит всё целиком (ну или хотя бы целиком только 1 тег), а затем сверяет различия с реальным DOM (перебирает все аттрибуты, их значения, innerText и пр.?) и точечно накатывает различия… То в чём фишка? Предполагаю, что фишка может быть в быстродействии. Ведь тогда получается что никаких схем связей элементов состояния с HTML он не хранит, и накладных расходов на их содержание и поддержание у него нет. Но приходится вот так вот извращаться. В этом фишка?
Да, фишка в быстродействии. Но также не менее важные вещи это полный контроль над компонентом через следующие вещи — явное описание состояний компонентов, ручное управление когда перерисовывать компонент. Тестируемость визуальных компонентов в React у программиста менее низкой квалификации в среднем будет лучше, чем например в Angular. Если сравнивать с Knockout, то скорее всего уровенить подверженности приложения тестированию будет примерно одинаков, потому что как и в React, так и в Knockout весьма проблематично объявить интерактивность не объявляя явно публичных методов которые будут выполнять действие, что автоматически позволяет использовать эти методы в тестировании.
5.В случае Knockout-а я не оперирую никакими состояниями. По сути я просто пишу бизнес логику в чистом виде. Как мне удобнее. Про HTML я просто забываю. Он второстепенен.
При написании LOB приложений это действительно большой плюс, потому что проблемы производительности менее важны. Но когда приходишь в землю мобильных приложений, и не дай бог еще они должны быть продуктом массового использования, тебе важно контролировать производительность. Поэтому тебе становится важен не только HTML, но также алгоритмы работы браузера по отрисовке контента.
6.По сути то, что в React называется состоянием, видимо, в случае Knockout-а и Backbone это просто модель.
Да, именно так, и причем React не пытается определять самостоятельно когда поменялось состояние визуального компонента. Разработчик сам должен говорить React что визуальный компонент должен быть обновлен.
anmiles
13.01.2016 03:31огромное кол-во HTML-а ? это уже специфика. В том числе и для SPA.
HTML-а — да.
Данных — нет.
Когда моё SPA поняло, что в одной из табличек рендерится 700+ строк из соразмерного массива из вьюмодели, оно поняло, что пора повыпендриваться и потормозить.
Смотрел, измерял — понял, что по мельчайшим долям секунды на каждый рендер строки таблицы из элемента массива данных складываются те несколько секунд, которые превращают экспириенс конечного пользователя в ад.
Пока думаю, что с этим делать.Fesor
13.01.2016 03:42+1Пока думаю, что с этим делать.
Реюзать DOM, что ж еще. Либо виртуальный скрол.
vintage
13.01.2016 09:47В данном случае нужно рендерить лишь то, что попадает в видимую область. Конкретно для табличек — это несколько проблематично.
Fesor
13.01.2016 11:35700+ строк таблички — это не сильно много. Больше пары тысяч — тут уже да, и если у нас фиксированная высота рядов то можно и виртуальный скролл для таблички сделать.
faiwer
13.01.2016 11:59Конкретно для табличек — это несколько проблематично.
Особенно для таблиц с произвольными row-Span-ами и col-Span-ами. Особенно когда таблицы могут быть на сотни A4 листов. Мы так и не придумали решения. Наш виртуальный скроллинг работает по принципу «примерно» :)Fesor
13.01.2016 12:49если таблица не перестраивается динамически, то есть один раз все рандомное отрендрилось и более не меняется (или меняется редко очень) — то можно один раз посчитать размеры и далее использовать их в виртуальном скроле, отрендривая с погрешностью чуть больше чем надо.
Еще как вариант разбить таблицу на сегменты и рендрить отдельные сегменты. Словом, варианты есть, но универсального решения нет.faiwer
13.01.2016 12:56и более не меняется
Меняется. Это редактор.
то можно один раз посчитать размеры и далее использовать их в виртуальном скроле
Эм. А как посчитать? Там могут быть тексты (а это шрифты, буквы, всякие мягкие переносы), изображения, вложенные таблицы и пр. Никак не посчитать. Более того (row|col)-span-ы убивают эту затею на корню.
отрендривая с погрешностью чуть больше чем надо.
Сейчас у нас используется механизм примерного подсчёта высоты, который в случае таблиц довольно сильно ошибается. Но учитывая, что scrollBar свой собственный и, по сути, отрабатывается не позиция scrollbar-а, а то насколько он был мышью смещён, это становится не сильно критичным. Худшее что может произойти: это если scroll-панелька закончилась, а документ еще нёт. Чаще: документ уже закончился, а панель — нет. Но это не фатально. Рассматриваем как неизбежное зло.Fesor
13.01.2016 13:05Меняется. Это редактор.
Ну тогда надо пытаться сделать изменения предсказуемыми.
Эм. А как посчитать?
Один раз отрендрить и потом убрать лишнее. Это не настолько тяжелая операция.faiwer
13.01.2016 13:09Ну тогда надо пытаться сделать изменения предсказуемыми.
Изменяет юзер. Что ему нужно, то и меняет ;) «Руками».
Один раз отрендрить и потом убрать лишнее. Это не настолько тяжелая операция.
Это более, чем тяжёлая операция. Допустимая задержка на рендер кадра до 1 секунды, а рендренинг некоторых таблиц целиком (вы встречались с районными бюджетами?) может занять около получаса. И там может быть сквозная колонка сверху до низу, а то и две. А то и несколько сквозных лесенкой.
Fesor
13.01.2016 13:28на рендер кадра — да, но я же предлагаю один раз отрендрить всю таблицу и потом больше этого не делать.
faiwer
13.01.2016 13:46Ответил в личку. Не приемлимо долго. Нужно за секунду-две, а там многие минуты (а в особо запущенных случаях и десятки минут). И такой вот ре-layout придётся делать практически при любом изменении в рамках таблицы. Отсюда и всевозможные ограничения в CSS и HTML, применительно к таблицам. Таблица ? это всегда большая заноза в любом ПО, где эти таблицы могут иметь сложную структуру.
Fesor
13.01.2016 13:52+1такие огромные таблицы просто не нужны. Они не несут пользы. Это называется «пользователь, я не хочу думать, я хочу выплюнуть миллион рядов тебе в лицо а ты сам разбирайся».
просто следует решать задачу исходя не из того что у нас рандомная таблица с бесконечным количеством вариантов развития событий, а как-то детерминировать проблему. Ограничить количество случаев когда нужно что-то перестраивать и т.д. Ну и тогда уже рендрить по кускам.faiwer
13.01.2016 13:59такие огромные таблицы просто не нужны.
Верно
Это называется «пользователь, я не хочу думать, я хочу выплюнуть миллион рядов тебе в лицо а ты сам разбирайся».
Это называется: «Мне сказали ? я сделал! Я человек подневольный, что вы ко мне привязались! Шефы меня не слушаются! Я не хочу ничего решать!» ну и т.д…
просто следует решать задачу исходя не из того что у нас рандомная таблица
Оттого, что я придумаю идеальный мир с розовыми понями, он таковым не станет. Есть исходные данные, и есть задачи, по работе с исходными данными. Личное мнение разработчика будет детально выслушано психотерапевтом, но дальше этого не уйдёт :D
Как то так.Fesor
13.01.2016 14:14Да я не о вас конкретно, а о людях которые ставят такие таски.
Оно то понятно, но проблемы надо как-то решать. Иногда коорндинально.
vintage
13.01.2016 15:16Лучше, конечно, не рендерить всё, а рендерить лениво. То есть рендерим от начала до конца видимой области. По мере скролла удаляем вышедшие за пределы видимой области ячейки, запоминая их размеры. Если пользователь кликнул сразу в конец сколлбара, то сам себе злобный буратино. Размер скроллящейся области складываем из уже известных размеров + оценка оставшихся неотрендеренных строк. По мере скролла актуализируем это значение. С реактивностью это реализуется не сильно сложно.
faiwer
13.01.2016 15:21Вы сейчас описали принцип работы виртуального скролла. Именно так и работает, ага.
faiwer
13.01.2016 11:57Пока думаю, что с этим делать.
Мы столкнулись с похожей проблемой. Впрочем, более, чем ожидаемой. Сделали прототип на knockout-е. Он бодро и комфортно работал на паре тысяч элементов. Но реально требуется поддержка плоть до миллиона.
Решение было сложным. Полностью отвязались от любой реактивщины. Взяли курс на иммутабельность. Но… миллион блоков это миллион блоков, браузер не сдюжит. Тут только виртуальный скролл. Он собственно проблему и решил. Производительность выросла на 2-3 порядка. И есть ещё заделы на будущее.
Всё остальное в приложении осталось на knockout-е и ничего с этим делать не планируем.Bronx
13.01.2016 14:14+1Любопытно, это реально есть такие, кто хочет скроллить таблицы в миллион… ок, пусть хотя бы несколько тысяч строк? И они всю эту портянку вдумчиво читают от и до, или им просто по-быстрому убедиться, что ячейки чем-то (неважно чем) заполнены, на всякий случай, чтобы крепче спать? Если они вдумчиво читают, то зачем им быстрый скроллинг? А если не читают, или не вдумчиво, то зачем им вся эта куча по сути ненужной информации? Если им нужно быстро находить какие-то значения, то почему нельзя делать это поиском/фильтрацией, а не скроллингом?
anmiles
13.01.2016 14:18Скроллить не хотят, а вот фильтровать на лету хотят. По умолчанию должны выводится все строки, при фильтрации — только некоторые
Bronx
13.01.2016 14:24«Все строки» == «все 10000 строк»? Или достаточно показать первую сотню (хоть фильтрованную, хоть нефильтрованную), а в конце добавить кнопку «Ещё, ещё, покажи больше!» (или повесить триггер автоподгрузки), зная что в 95% случаев никто дальше второй сотни не пойдёт?
faiwer
13.01.2016 14:23Угу, бывают такие таблицы. Нет, никто их целиком не читает. Только те части, которые нужны здесь и сейчас. И не только читают. Но и вносят изменения. В том числе и в структуру :) Т.е. нужна полноценная возможности работы с такой вот дурой. Ответил бы и на остальные вопросы, но инфа не публичная, sorry :)
Скажем так, есть ТЗ. В рамках него нужно обеспечить вот такой вот функционал. Угу, такое бывает. В качестве аналогии, представьте, что вы разработчик MS-Word-а. Ваш продукт должен быть в состоянии обеспечить нормальную работу с цельными таблицами, со сложной структурой, длинною в сотни A4 страниц. Интересная, задача, не правда ли? До того момента, пока я с такой не столкнулся, я никогда не задумывался над тем, как могут работать офисные редакторы, почему кол-во страниц заранее не известно и можно на время быть не актуальным, да и вообще не задумывался, что там внутри. Это только на первый взгляд кажется, а чего там… Блоки текста, таблички, сложные layout-ы, страницы, изображения с заранее не известными размерами, … oh shi… И это должно ещё «летать» по ходу работы с таким документом. Ну… Зато интересно :D
ajaxtelamonid
06.01.2016 09:42+7Когда вы учите Angular, вы инвестируете своё время в приобретение знания о внутреннем языке (DSL) Angular. Полученное вам пригодится дальше, если вы будете использовать Angular. Если нет (вспоминаем, как закончилось время первого ангуляра ) — большая часть времени окажется потраченным впустую.
Когда вы учите React, вы инвестируете свое время в приобретение знания о Javascript — DSL в React практически нет. Полученное знание 100% пригодится вам на дальнейшем пути, даже если React вы использовать не будете.
Выбор очевиден.faiwer
06.01.2016 10:07+5Когда вы учите Angular, вы инвестируете своё время в приобретение знания о внутреннем языке (DSL) Angular
Неужели всё настолько плохо, что на это потребуются годы? Это же не Haskell! Если же нет, то разве преимущества подхода не позволят сократить уйму времени на дальнейшую разработку? Если позволят, то есть ли смысл тут горевать? Вы не передёргиваете?ajaxtelamonid
06.01.2016 11:26+2Я описываю собственный опыт. Я веб-программист с упором на сервер, и пару лет назад озаботился вопросом «что бы такого узнать про фронт, чтобы безболезненно его писать». Тогда гремел первый ангуляр, и я его освоил. Это, конечно, не хаскель, но все-таки на изучение и поддержания этого знания в голове, когда оно не приоритетно, тратятся ресурсы — пара проектов без фронта, и на третьем, где фронт нужен, уже начинаешь мучительно вспоминать синтаксис директив и лазить в прошлые проекты за копипастой. Отказ от совместимости второго ангуляра (и недостатки первого ангуляра — писать на нем было очень неудобно) окончательно утвердил меня в мысли, что я делаю что-то не то — мне предстояло с нуля пройти дорогу, которую я считал уже пройденной и закрытой. Я сделал следующую попытку и обратился к эмберу. Но в процессе изучения я понял, что в итоге приду к тому же самому, что и с ангуляром, все бросил, погуглил эту проблему, увидел в каком-то блоге мысли, которые я изложил в комментарии выше, попробовал Реакт и понял — да, это оно. Это путь почти без утраты наработанного.
Возможно, это поможет таким же людям как я, у которых js не в приоритете и которые не могут держать в голове несколько DSL от js-фреймворков одновременно.serf
06.01.2016 13:10-2> Возможно, это поможет таким же людям как я, у которых js не в приоритете и которые не могут держать в голове несколько DSL от js-фреймворков одновременно.
Вам как в большей степени бэкенд разработчику (полагаю на бэкенде что-то со статической типизацией) возможно стоит обратить внимание на TypeScript, там ведь синтаксис запоминать особо и не нужно будет — автокомплит (статическая типизация).Fesor
06.01.2016 13:26полагаю на бэкенде что-то со статической типизацией
Скажите это рубистам, они порадуются.
Я пишу и на бэкэнде и на фронтэнде с примерно одинаковым соотношением времени (50/50), если изучил JS (а архитектурные принципы можно с бэкэнда перенести) то изучить Angular не составляет проблем. Синтаксис шаблонов — ну это как новый шаблонизатор для бэкэнда подучить. То что на фронтэнде сейчас набирает популярноть функциональщина — так это даже плюс, ибо на бэкэнде ситуация ровно та же.
Вообще если не зацикливаться на деталях то различий становится все меньше.serf
06.01.2016 13:30Только в случае веба и ангуляра в частности изучить синтаксис далеко не достаточно чтобы писать грамотно и эффективно.
Fesor
06.01.2016 13:48конечно. Как и на бэкэнде, знание синтаксиса не позволят использовать эффективно тот же Spring просто так.
serf
06.01.2016 13:50все же на сервер сайде обычно все очевиднее тк обычно работает предсказуемо
Fesor
06.01.2016 13:55Я думаю тут дело привычки. На клиенте все осложняется только тем, что приложение может запускаться в разных окружениях а для бэкэнда его ограничивать проще.
serf
06.01.2016 13:57дело не только в окружении, ангуляр допустим пропагандирует не работать с DOM напрямую и вот если кто-то начинает осваивать JS и веб с ангуляра, то вероятно упустит важные для веба детали.
ajaxtelamonid
06.01.2016 15:36Нет, я для себя понял и решил, что двигаться проще в мейнстриме. ES6, ES7 и так далее.
faiwer
06.01.2016 16:27Хех. Ну это как кардиологу жаловаться на то, что слишком уж у стоматологов оборудование перемудрённое. Вы желаете «узнать что то про фронт, чтобы безболезненно писать», а затем берёте топ-framework и жалуетесь на то, что как то много сразу хапнули :-)
ajaxtelamonid
06.01.2016 17:32Сейчас у меня тоже «топ-фреймворк», с, к тому же, непростой системой взаимодействия между компонентами (react + redux) — и мне не хочется жаловаться.
Fesor
06.01.2016 17:58+2непростой системой взаимодействия между компонентами (react + redux)
Это самая простая система взаимодействия между компонентами. В этом же ее преимущество.vintage
08.01.2016 11:26Превращать вызовы колбэков в создание событий, после чего делать гигантский switch по этому событию, чтобы произвести действие — далеко не самая простая система взаимодействия компонент. Можно проще, реально, и с лучшей поддержкой статической типизации.
symbix
06.01.2016 20:46Действительно глубокое изучение angular1 требует понимания его принципов работы, а для глубокого понимания этих принципов требуется хорошее знание JavaScript. Совсем не считаю это время потраченным впустую, даже если и перейду полностью на React.
bromzh
13.01.2016 15:36А что значит «учить ангуляр»? Если ты знаком с MV* фреймворками, с паттернами типа DI и знаешь JS, то достаточно посмотреть пару туторов и почитать styleguide и, самое главное, нужно начать писать какой-то проект. Все вопросы типа «как в ng писать фильтры» можно гуглить по мере их поступления. Зато набив руку, можно экономить время, используя фреймворк.
Если же знания JS есть, а паттернов — нет, то время, потраченное на изучение ангуляра будет полезным: принципы там довольно общие.
Ну и сами по себе знания JS будут увеличиваться вне зависимости, ангуляр это, реакт или ещё что-то.
Вот реально, что в ангуляре такого, что используется только в нём и не пригодно для других технологий/решений?
enleur
06.01.2016 09:43+5Мне иногда кажется что я где-то в параллельном вебе нахожусь где бОльшая часть сайтов и приложений(ebay, amazon etc) все еще используют серверный рендеринг. В таком случае применимость angular скатывается к нулю, а в случае с react сразу же указывают на nodejs где якобы используется серверный рендеринг для компонентов и если хочешь использовать его с бекендами не на ноде — тогда это выливается в оверхед и головняк, который не оправдывает себя никак. Я наверное что-то не понимаю?
faiwer
06.01.2016 10:10+1Присоединяюсь к вопросу. Складывается впечатление, что весь web переезжает на SPA. Но видимо как-то параллельно, так что мы этого не замечаем…
fetis26
06.01.2016 10:58+3Ну Амазон до сих пор текст на кнопках графикой пишет. Да и в целом дизайн у них привет из 2000, но это не значит что мы все теперь должны так делать. А потом это суперкрупные компании, у них другие задачи и количество посетителей.
serf
06.01.2016 13:01Ну Амазон до сих пор текст на кнопках графикой пишет.
А чем, шрифтами? Сейчас вон уже svg иконки модны, что гораздо более кастомизируемо чем шрифты.
vlreshet
06.01.2016 13:23Ну не знаю, ИМХО — дизайн амазона отличный.Дизайн != красотульки. Дизайн amazon aws консоли позволяет мне быстро и чётко находить нужные вещи. А дизайн, например, google analytics, с их упором на material и всё такое — заставляет меня 5 минут хаотично тыкать в иконки чтобы найти чёртов функционал.
serf
06.01.2016 13:00-1А во втором ангуляере ведь должен быть серверный рендеринг. Вот что-то нагуглил www.youtube.com/watch?v=0wvZ7gakqV4 (не смотрел).
evil_random
06.01.2016 14:43У меня за серверный рендердинг только один аргумент: гуголь и прочие поисковики. В крупной компании неизбежно есть сеошники, которые считают, что нельзя на сервере рендерить одно, а на клиенте другое. Приходится пилить изоморфные приложения и рендерить на сервере. Реакт, кстати, неплохо страдает на больших списках и решения этой проблемы мы так и не нашли.
vintage
06.01.2016 15:13-2Для гугля есть prerender.io. Но я согласен, что изоморфность по приятней и эффективней будет.
evil_random
06.01.2016 15:17+3Ох, жестко-то как. А как быть если у тебя база чего-то с миллионами записей? Да и вообще идея парсить у кого-то меня не вдохновляет.
baka_cirno
06.01.2016 11:43+2Второй Ангуляр видится мне совсем уж каким-то монстром. Он пытается покрыть собой сразу все модные фичи и технологии, выпуклившиеся в последние годы. Из-за этого у него имеется куча разных тонкостей, которые применимы, скажем, при серверном рендеринге, но не нужны при работе с NativeScript. Недавно читал статью о том, как человек пытался оптимизировать простую игрушку-головоломку. В итоге ему это удалось, но только после долгих мытарств и обсуждений на форумах.
Меня его учить никто не заставляет, а мне и не хочется, да и необходимости в нем не вижу. Подобные ощущение уже не раз замечал у других людей, которые использовали Angular 1.x.serf
06.01.2016 13:03Неободимость зависит от проектов с которыми работаете, разумеется есть множество проектов где ангуляре более чем избыточен либо имеет слишком большой порог вхождения.
Akuma
Поддержу переводчика. Мне тоже React больше нравится.
Хотя на него я перешел с первого Ангуляра :)
А вот вторая версия вообще не впечатляет. Вообще всегда судил о библиотеке по принципу «Нужна документация — это плохо».
Вот не могу я понять второй ангуляр «с пол пинка». Реакт — можно примерно понять что куда, даже не читая документацию. Первый ангуляр — худо-бедно, но тоже можно разобраться. Второй ангуляр: перечитал уже несколько статей, ну не понимаю я зачем опять придумывать новый синтаксис, к тому же для новичка вообще непонятный.
Плюс TypeScript. Может кто-то объяснит для чего было привязывать фреймворк к TS? Не то чтобы я его не любил… просто не полюзуюсь. Хватает ES6-7 и Babel или полифилов.
serf
Так ведь привязка к TypeScript опциональна, и это полезно для больших проектов (статическая типизация, тайп сейф, все дела).
Fesor
То есть к реакту вы документацию не читали? Все методом тыка?
Что вы привязались к синтаксису шаблонов то? Он более чем логичный и разобраться в нем можно за пару часов чтения документации и эксперементов.
В остальном же концепции там те же что и у реакта. Дробление UI на независимые компоненты, поток данных строго в одну сторону…
TypeScript это тот же ES6-7, просто помимо этого там так же добавляется информация о типах. И информация о типах — строго опционально, то есть вы можете на TS писать тот же ES6-ES7 код кто и пишите. Для больших проектов от этого профит в виде повышения качества статического анализа.
Angular — большой проект потому там польза от TS проявляется. Но вас мало того что не заставляют его использовать (хоть ES5 используйте) но и TS никак не заставляет вас декларировать интерфейсы или типы для своего кода.
Akuma
Не совсем верно. Я имею ввиду, что должна быть возможность хоть что-то понять в библитеке при отсутствии документации. А так: само-собой читал, куда ж без нее.
Не охото с вами спорить. Да я и не говорил, что он плохой.
Вот об этом я узнал только из комментариев к этой статье :) До этого все, на что я натыкался было про TS.
Fesor
Angular в отличии от реакта — это не библиотека, а фреймворк. Вообще все очень просто. Если вам фреймворки жмут, то тогда можно использовать набор библиотек и затачивать все под себя. И я могу сказать что большинству разработчиков давать такую свободу не стоит.
Я к тому что я могу написать вам пример кода на TS и вы подумаете что я просто взял babel + stage1 плагины. Но в целом — angular только в бете. Это значит что сейчас идет период стабилизации API и написания документации. Все будет со временем.
Akuma
Да, но в данной статье как раз и сравниваются библиотека с фреймворком.
Вообще я просто высказал свое мнение )) А уже и комментарий заминусили :)
Первый ангуляр зацепил, реакт зацепил, второй ангуляр — ну не цепляет он. Может как выйдет стабильная версия, так все и наладится. Посмотрим ))
Fesor
Меня зацепили подходы реакта и я их успешно применяю с angular1 (а второй их по умолчанию в документации рекомендует). Сам же react… я слишком ленив для оного.
Akuma
Попробуйте сам реакт, вам понравится )) Правда, как по мне, так он совершенно для других задач.
А можно побыть извращенцем и попробовать ngReact :)
Fesor
Вы думаете я не пробовал реакт? Повторюсь — мне очень понравилась идея, но я уж лучше на Ember буду писать.
Akuma
Я подумал что вы слишком ленивы чтобы его попробовать :)
В итоге — каждому свое. Что понравилось, тем и пользуемся.
Fesor
Именно так. Вопрос вкусов. Ну и задачи разные)
Akuma
Про задачи точно подмечено. Кому-то и jQuery слишком много под проект )