Comments 140
Но там на текущий момент ангуляр 2 в версии RC5. А к релизу они обещали повысить скорость.
Плюс, в свежих версиях появилась возможность скомпилировать шаблоны заранее и бутстрапить всё уже из модуля @angular/platform-browser (а не из @angular/platform-browser-dynamic), что ускорит первоначальную загрузку приложения, см. https://angular.io/docs/ts/latest/guide/ngmodule.html#bootstrap
Думаю теперь можно и в продакшен проекты выводить на нём, а то эти бесконечные правки в API уже начали пугать.
Мир будет дальше гавно кодить. Только конечно TypeScript завели, самый большой плюс наверное.
React как библиотека дает надежный фундамент, да в каждой команде есть свой набор обвязок, но это не минус приложений на реакте, а плюс. Плюс который показывает всю гибкость подхода и неограниченное число возможностей.
А чем jsx лучше html для шаблонов?
переиспользовать часть шаблона — нужно городить компонент либо делать $compile
Если шаблон — просто кусок HTML без биндингов, то можно его сохранить в строке, а в шаблоне сделать так: <div [innerHTML]="theHtmlString"></div>. Если шаблон содержит какие-нибудь биндинги, то используется специально предназначенная для этого штука — HTML templates.
А в реакте по-сути, тот же $compile (хотя во втором ангуляре это по-другому зовётся, но не суть), только синтаксис немного компактнее. Да и в доках советуют обёртки создавать.
Всё еще директивы
Они прекрасно подходят для расширения готовых компонентов. Так, например, я могу сделать директиву-валидатор и использовать её и со стандартными, и со своими кастомными контролами:
<input type="text" name="foo" required myValidator>
<select myValidator></select>
<my-custom-control myValidator></my-custom-control>А в реакте надо городить обёртку для этих контролов. Это выглядит стремновато. А Это вообще ужас.
так же убого выглядит template
Дело вкуса конечно. Но шаблоны ангуляра — это обычный html (ну ладно, ещ] совсем немного сахара, но шаблоны по-прежнему остаются валидным html-кодом), они декларативны и этим хороши. По-мне, это
<ul>
<li *ngFor="item of items">{{ item.text }}</li>
</ul>куда лучше, чем это:
// Враппер для li? серьёзно?
var ListItemWrapper = React.createClass({
render: function() {
return <li>{this.props.data.text}</li>;
}
});
var MyComponent = React.createClass({
render: function() {
return (
<ul className=""> // с className я вообще всегда угораю, ну что за костыли
// js вперемешку с вроде как разметкой? И это в оф. доках...
{this.props.results.map(function(result) {
return <ListItemWrapper key={result.id} data={result}/>;
})}
</ul>
);
}
});Всё ещё остался двух-сторонний биндиг в лице NgModel
Да, и он очень часто более удобен, чем его односторонний вариант. Хотя если не нравится — используйте "реактивные" директивы, никто не запрещает. Присутствие выбора — это вроде как хорошо.
Плюс который показывает всю гибкость подхода и неограниченное число возможностей.
Второй ангуляр, в отличие от первого, супер гибкий. Можно изменить буквально всё: рендерер элементов (например, можно рисовать на канвасе, вместо отображения в дом), стратегию проверки изменений, и многое другое. Причём, изменять это всё можно не только глобально, но и для какой-то части приложения или даже одного компонента.
да в каждой команде есть свой набор обвязок
В итоге, у каждой команды получается свой фреймворк, который нужно самим поддерживать в актуальном состоянии. Новичкам труднее вникнуть в новый проект, так как никакого более-менее единого набора нет. Не, выбор — это хорошо. Однако, если приложение намечается крупным, то лучше сразу взять готовый фреймворк.
И вообще, каждый выбирает то что ему нравится.
В официальной документации немного иное имелось в виду:
Если у вас список элементов со сложной структурой (внутри нечто большее, чем один <li> c текстом), то ключ надо присваивать на верхнем уровне для компонента ListItem, а не внутри него, где он раскрывается в тег li c контентом.
Для простых случаев есть пример выше, и он прекрасно работает
render: function() {
var results = this.props.results;
return (
<ol>
{results.map(function(result) {
return <li key={result.id}>{result.text}</li>;
})}
</ol>
);
}> Если шаблон — просто кусок HTML без биндингов
нет, конечно же такой пример не интерестен, нам интересны шаблоны с биндигами, но даже на простом куске HTML React выглядит красивее и идеоматично с точки зрения HTML:
<...>
<JustFewHtmlTags/>
</...>
> А в реакте по-сути, тот же $compile
Вообще не так, плохая аналогия, $compile создает новый скоуп, вешает листенеры https://github.com/angular/angular.js/blob/master/src/ng/compile.js#L2750 и т.д. JSX же просто способ описать кусочек виртуального дома.
Мы делаем $compile когда нам нужно сделать динамический компонент. В реакте за счет jsx — всё динамический компонент.
> то используется специально предназначенная для этого штука — HTML templates
Могли бы показать где описана эта штука? Нет, в гугле не забанили, просто нету такого понятия в документации:
site:angular.io html templates
Я видел пример из статьи про порталы, и то что на ангуляр 2 это просто ужасно. А подобные задачи часто встречаются у меня в проектах.
https://habrahabr.ru/post/305892/
> Да и в доках советуют обёртки создавать.
Прочитайте пожалуйста документацию еще раз, ничего такого там не написано.
> Они прекрасно подходят для расширения готовых компонентов. Так, например, я могу сделать директиву-валидатор и использовать её и со стандартными, и со своими кастомными контролами:
```
<my-custom-control myValidator></my-custom-control>
```
ух, это классный валидатор будет, особенно доставляет разбираться в то что где когда дернется, а если несколько директив повесить, самый сок, не забываем про formatters и parses на ngmodel.
В Реакте это много способов сделать тоже самое что делают директивы, можно даже сделать аттрибуты которые будут работать как директивы. В целом это всегда может быть просто компизиция компонентов.
А вот это выглядит отлично, после двух лет разработки на ангуляре как глокот свежего воздуха: http://redux-form.com/6.0.5/examples/simple/
> По-мне, это куда лучше, чем это…
По мне все директивы это 1% от того что я могу сделать в JSX
```
<li *ngFor=«item of items»>{{ item.text }}
const ItemsList = (items) => (
{items.map((item, idx) => {item.text}}
);
</...>
```
И то чего всегда не хватало в ангуляре:
```
<...>
<Component {...this.props}/>
</...>
```
> Второй ангуляр, в отличие от первого, супер гибкий.
Окей, как мне сделать два инстанса Http сервиса с разным списком интерсепторов? Если и есть способ из коробки, придется лезть в доки и разбираться. Но вообще речь шла про View, выше обсудили достоинства JSX.
> Да, и он очень часто более удобен, чем его односторонний вариант.
jQuery тоже удобно, но хочется писать понятный, поддерживаыемый софт. Двухсторониий биндинг битч первого ангуляра. Посмотрите на так называемые controlled inputs в Реакте.
Ну т.е. в целом вы к сожалению не разбираетесь в Реакте так что ничего конкретного про Реакт. Но Ангуляр хорошо защищаете.
> В итоге, у каждой команды получается свой фреймворк, который нужно самим поддерживать в актуальном состоянии.
Это беспорно, но зато легко апдейтить отдельные части, не будет таких проблем как апдейт с angular 1.3 на 1.4.
> Новичкам труднее вникнуть в новый проект, так как никакого более-менее единого набора нет.
Новичкам чего? Js? Это очень спорно, порог вхождения в ангуляр между тем огромен, и позновать его можно долго.
> Однако, если приложение намечается крупным, то лучше сразу взять готовый фреймворк.
Моё мнение нужно взять то, что более предсказуемое и лучше масштабируется. Это явно не про ангуляр.
Не то, чтобы в angular он был сделан идеально (вовсе нет, там самая примитивная реализация из возможных), но он там хотя бы есть.
Это пока единственное, что меня останавливает. Завязываться на конкретные реализации в виде явных импортов для меня неприемлемо.
Service locator-ы не подойдут, нужна инъекция. Варианты с кодогенерацей/метаданными/препроцессингом — годятся.
Я сам из мира JVM и весь DI который я видел в JS(angular 1, angular 2) видится мне убогим. У меня есть идеи как сделать правильный DI, но там нужен TypeScript, чтобы иметь интерфейсы и не писать лишний код.
Но можно сделать без TS, просто придется писать токены сервисов самому (аля angular1). Я вижу DI в реакте так: у нас есть Injector, которому мы регистрируем имена сервисов + реализация, мы можем создать несколько инжекторов и дать им имя, это удобно для создания разных контекстов (например http сервис для обращения к своему бекенду и отдельная конфигурация сервиса для обращения к бекенду site.com.
Далее инжектор строит «контекст» и мы можем прокинуть его через провайдер во все реактовские компоненты.
Остается написать свой HOC который будет брать инжектор и прокидывать желаемые сервисы в пропсы:
inject('myCustomInjector', ['http', 'base64'])(Сomponent)
// injector — myCustomInjector
// сервисы — http, base64
inject(['http', 'base64'])(Сomponent)
// injector — default (root для всех инжекторов)
// сервисы — http, base64
использование:
let Сomponent = (props) => {
const {http, base64} = props;
…
}
есть много проектов для DI, краткое гугление даже выдает нечто подобное описанное мной:
https://github.com/michael-shattuck/react-injector
но почему-то в целом DI не популярен в React, я не буду защищать эту позицию, просто скажу что тестирование компонентов на порядок удобнее чем в ангуляр, даже без DI
Вопрос в том, как прицепиться к внутренней реактовской фабрике компонентов. Понятно, что constructor injection вряд ли реализуем, но хотя бы в приватные поля бы, а-ля autowired…
Все эти проекты, которые я видел, вроде умеют инжектить только в корневой компонент, это неинтересно :)
Пример с редакс-стором
https://github.com/reactjs/react-redux/blob/master/src/components/Provider.js#L23
В аурелии есть четкие импорты(в ES2015 нету же интерфейсов), или это не тот DI?: http://aurelia.io/hub.html#/doc/article/aurelia/dependency-injection/latest/dependency-injection-basics/1
В крайнем случае можно генерировать из интерфейсов эмуляцию pure abstract classes.
Надо тут подумать, да.
А контекст — ну не знаю, это какой-то сервис-локатор получается. Не люблю неявные зависимости, которые можно использовать в любом месте иерархии — так легко получить компонент, который зависит от всего, что там в контейнере валяется.
то используется специально предназначенная для этого штука — HTML templates
Могли бы показать где описана эта штука? Нет, в гугле не забанили, просто нету такого понятия в документации
Конечно могу. Только это не ангуляр-специфичная штука, а стандарт HTML: https://developer.mozilla.org/ru/docs/Web/HTML/Element/template
И, кстати, пример использования и применения этого тега и технологии в реакте я нагуглить не смог.
Я видел пример из статьи про порталы, и то что на ангуляр 2 это просто ужасно. А подобные задачи часто встречаются у меня в проектах.
Плохой пример из старой статьи. Работать с template во втором ангуляре довольно удобно. Пример приводить не буду, можно посмотреть в доках или англоязычных статьях. Если будет время, постараюсь написать статью, в которой эту тему тоже затрону.
Прочитайте пожалуйста документацию еще раз, ничего такого там не написано.
Да, тут я был не прав.
ух, это классный валидатор будет, особенно доставляет разбираться в то что где когда дернется, а если несколько директив повесить, самый сок, не забываем про formatters и parses на ngmodel.
Во втором ангуляре нет больше ни formatters, ни parsers. Работа с контролами и NgModel в частности (как одна из 2-х доступных реализаций работы с контролами) стала куда проще и удобнее.
Директивы же теперь "избавились" от view в том смысле, что у них, в отличие от компонентов, не может быть шаблона. Т.е. теперь директивы по-хорошему, лишь добавляют некоторый функционал в компонент, эдакий миксин к компоненту. Если писать грамотно, то порядок вызова кода в директивах не будет влиять ни на что. А непредсказуемый код и не реакте ваять можно.
А вот это выглядит отлично, после двух лет разработки на ангуляре как глокот свежего воздуха: http://redux-form.com/6.0.5/examples/simple/
Всё равно, для меня это выглядит большущим оверхэдом. Второй ангуляр позволяет работать с формами и валидаторами как из кода в императивном стиле (как в этом примере), так и декларативно, через шаблоны. Что крайне удобно, так как позволяет вообще всю валидацию и обработку форм описывать декларативно в шаблоне, снизив количество js-кода почти до нуля. И я нигде не видел, чтобы в реакте всё было бы так же просто и кратко.
Окей, как мне сделать два инстанса Http сервиса с разным списком интерсепторов? Если и есть способ из коробки, придется лезть в доки и разбираться. Но вообще речь шла про View, выше обсудили достоинства JSX.
Не барское это дело, доки читать. А ведь во втором ангуляре это сделать не то что просто, а очень просто. Я, кстати, писал статью про DI в ангуляре, и там этот момент присутствует. Да и в доках это не так уж далеко спрятано.
Двухсторониий биндинг битч первого ангуляра
Бичом он там был по причине его повсеместности. Однако, во втором ангуляре его можно не использовать вообще. Однако, именно в формах он удобен (по-крайней мере, для меня и многих других разработчиков, раз его оставили), так как позволяет уменьшить код. Если применять грамотно, то проблем не будет.
Ну т.е. в целом вы к сожалению не разбираетесь в Реакте так что ничего конкретного про Реакт.
Да, скрывать не буду, я его знаю только в теории из чтения доков. И этого для меня вполне достаточно, чтобы не пробовать его в деле, так как я везде вижу только костыли, странные практики и другие отрицательные моменты. Плюсы я тоже вижу, но для меня их слишком мало, чтобы начать использовать реакт.
Новичкам чего? Js? Это очень спорно, порог вхождения в ангуляр между тем огромен, и позновать его можно долго.
Новичкам в проекте. Когда новый человек приходит в команду, где используется ангуляр, он быстро сможет разобраться в проекте, ведь архитектура проекта и бОльшая часть используемых технологий заранее известна. Если проект на реакте, то из-за большого количества различных решений для одних и тех же вещей шанс, что ты будешь знаком со всеми технологиями в проекте намного ниже. Например, кто-то из реактовцев писал, что они используют аналог ангуляровского DI для построения архитектуры, кто-то берёт redux, кто-то использует flux и его реализации. Вот простенький пример: что в реакте обычно используется в качестве http-клиента? В доках берут jQuery, кто-то возьмёт fetch, кто-то городит свои решения. В ангуляре же этот частоиспользуемая часть входит в состав фреймворка, и либо используется напрямую, либо через парочку распространённых решений на базе оного.
PS. Не в обиду вам и другим реактовцам, но я заметил такую деталь. В статьях (особенно, в статьях-сравнениях) про реакт одним из плюсов ему приписывают то, что, реакт — это только лишь js. Т.е., мол, когда ты учишь реакт — ты учишь JS и эти знания тебе пригодятся. А вот если учишь ангуляр — то учишь только его и знания будут бесполезны вне ангуляров. Однако, при использовании и изучении ангуляра (особенно второго), я стал лучше понимать принципы построения архитектуры приложений, больше узнал про DI, где и как его применять, как он устроен и т.д., узнал про всякие новые стандарты как ES (декораторы, новые методы из стандартной библиотеки, и прочие штуки), так и Web-технологий в целом: Web animations API, File API, html template, shadow dom и т.п.
А вот реактовцы часто не знают, что такое тот же DI и зачем он нужен, "ведь есть же import/require", говорили они. Вы спрашиваете про template, хотя это стандарт. Плюс, если в ангуляре класс-компонент — это просто обычный класс, без своих полей и методов, то в реакте компоненты наследуются от какого-то класса, в котором полно "зарезервированных" методов и полей: все эти this.props, this.state (и куча методов, относящихся к манипуляциям со state), render(), управление жизненным циклом компоненита и другие. Да, во втором ангуляре тоже есть методы для, например, управления жизненным циклом. Но, во-первых, в доках рекомендуется при их использовании добавлять к классу имплементацию соотв. интерфейса, а, во-вторых, почти все эти методы используют префиксы, что позволяет не засорять "пространство имён" и уменьшить вероятность конфликта с другими библиотеками. Т.е. сам фреймворк прививает хорошие практики написания кода.
Складывается ощущение, что реакт навязывает больше своих решений, поощряет некоторые сомнительные практики (вроде принудительных инлайновых стилей, логики в шаблонах, невозможности отделить представление от других частей приложения, разнос разметки и кода по разным файлам).
Не холивара ради это всё, просто у меня сложилось именно такое мнение про реакт и многих его пользователей. Так что прошу простить, если кого обидел.
Не нашел в доках как template помогает делать те самые порталы о которых идет речь, можно хотя бы ссылку на ту самые доки?
> И, кстати, пример использования и применения этого тега и технологии в реакте я нагуглить не смог.
Очевидно, потому что он там не имеет смысла и не нужен.
> Во втором ангуляре нет больше ни formatters, ни parsers.
Ура, что еще можно сказать.
> Всё равно, для меня это выглядит большущим оверхэдом. Второй ангуляр позволяет работать с формами и валидаторами как из кода в императивном стиле (как в этом примере), так и декларативно, через шаблоны. Что крайне удобно, так как позволяет вообще всю валидацию и обработку форм описывать декларативно в шаблоне, снизив количество js-кода почти до нуля. И я нигде не видел, чтобы в реакте всё было бы так же просто и кратко.
Декларативно описывается только синхронная валидация, самый большой геморой всегда это асинхронная валидация, например описание ошибочных полей в ответе на запрос. И в тех же redux-form она выглядит очень понятно и просто. В первом ангуляре это был сущий ад, во втором не видно координальных улучшений.
> Не барское это дело, доки читать. А ведь во втором ангуляре это сделать не то что просто, а очень просто. Я, кстати, писал статью про DI в ангуляре, и там этот момент присутствует. Да и в доках это не так уж далеко спрятано.
Ну я хотел подтолкнуть дискуссию в сторону проблем иеархического инжектора, например когда в одном ветке мы имеем отдельную реализацию (subtree1), и в одном из компоненте этой ветке хотим достать другую (например root) реализацию, а не переопределенную.
> Если применять грамотно, то проблем не будет.
Утопично
> Да, скрывать не буду, я его знаю только в теории из чтения доков. И этого для меня вполне достаточно, чтобы не пробовать его в деле, так как я везде вижу только костыли, странные практики и другие отрицательные моменты. Плюсы я тоже вижу, но для меня их слишком мало, чтобы начать использовать реакт.
Ну как минимум на сегодняшний день для реакта уже есть готовая экосистема (библиотеки, компоненты), а для второго ангуляра — нет. Совсем скоро я пророчу что они где-нибудь что-нибудь переделают, сломая обратную совместимость и усложнив апдейт. Для первого ангуляра кстати за всю его жизнь так и не появилось хорошей, простой библиотеки компонентов: обожглись на angular-ui (вроде так называлась) комонентах, которые были ужасно бажные.
> Новичкам в проекте. Когда новый человек приходит в команду, где используется ангуляр, он быстро сможет разобраться в проекте, ведь архитектура проекта и бОльшая часть используемых технологий заранее известна. Если проект на реакте, то из-за большого количества различных решений для одних и тех же вещей шанс, что ты будешь знаком со всеми технологиями в проекте намного ниже. Например, кто-то из реактовцев писал, что они используют аналог ангуляровского DI для построения архитектуры, кто-то берёт redux, кто-то использует flux и его реализации. Вот простенький пример: что в реакте обычно используется в качестве http-клиента? В доках берут jQuery, кто-то возьмёт fetch, кто-то городит свои решения. В ангуляре же этот частоиспользуемая часть входит в состав фреймворка, и либо используется напрямую, либо через парочку распространённых решений на базе оного.
Redux и есть Flux. Как раз таки на примере http: окей, кто-то взяли jquery — и? Главное знать маленький и понятный React и понимать Flux, а доступ к данным по http плюс-минус выглядит одинаково в любом фреймворке, тем более в проекте будут видны и понятны паттерны использования.
> Т.е., мол, когда ты учишь реакт — ты учишь JS и эти знания тебе пригодятся.
Так и есть, я знаю весь первый ангуляр вдоль и поперек, перечитывал сорцы десять раз и знаю что и как внутри устроенно. С выходом ангуляр 2 — 80% этих знаний — бесполезный мусор, хоть в целом подход не поменялся нужно всё учить заново.
> Однако, при использовании и изучении ангуляра (особенно второго), я стал лучше понимать принципы построения архитектуры приложений, больше узнал про DI, где и как его применять, как он устроен и т.д., узнал про всякие новые стандарты как ES (декораторы, новые методы из стандартной библиотеки, и прочие штуки), так и Web-технологий в целом: Web animations API, File API, html template, shadow dom и т.п.
Это не заслуга ангуляра, это недостаток вашего образования и познаний.
> А вот реактовцы часто не знают, что такое тот же DI и зачем он нужен, «ведь есть же import/require», говорили они.
Ну если вы поняли зачем нужен DI то вы должны понимать что не в import дело, делать тестируемые компоненты можно многими способами, и способ ангуляря не лучший.
> Вы спрашиваете про template, хотя это стандарт.
Потому что я ожидал что это будет какой-то ангуляровкий темплейт, и опять же, вы не показали каким боком он поможет сделать динамику и как в нем будут интерпретироваться компоненты и директивы.
> Плюс, если в ангуляре класс-компонент — это просто обычный класс, без своих полей и методов, то в реакте компоненты наследуются от какого-то класса, в котором полно «зарезервированных» методов и полей: все эти this.props, this.state (и куча методов, относящихся к манипуляциям со state), render(), управление жизненным циклом компоненита и другие. Да, во втором ангуляре тоже есть методы для, например, управления жизненным циклом. Но, во-первых, в доках рекомендуется при их использовании добавлять к классу имплементацию соотв. интерфейса, а, во-вторых, почти все эти методы используют префиксы, что позволяет не засорять «пространство имён» и уменьшить вероятность конфликта с другими библиотеками. Т.е. сам фреймворк прививает хорошие практики написания кода.
Притянуто за уши, в Реакте как-раз таки явно видно что есть ваш компонент — какие у него есть методы жизненего цикла, а в ангуляре всё это неявно.
Плюс в Реакте компонентом может быть просто функция, что позволяет делать очень маленькие и удобные реюзабальные компоненты и у них вообще не будет методов жизненного цикла, просто чистая функция (лучшее что можно пожелать для тестирования).
> Складывается ощущение, что реакт навязывает больше своих решений, поощряет некоторые сомнительные практики (вроде принудительных инлайновых стилей, логики в шаблонах, невозможности отделить представление от других частей приложения, разнос разметки и кода по разным файлам).
Ух ты, принудительные inline стили, логика в шаблонах. Всё таки вам стоит написать to-do app на реакте, а еще лучше посмотреть видео-лекции Данила Абрамова на egghead прежде чем делать неправильные выводы.
Если вы в 2016 не поняли что руками DOM лучше не трогать, то мне вас искренне жаль.
И тем более делать селекторы в JS.
Если вы в 2016 не поняли что руками DOM лучше не трогать, то мне вас искренне жаль.
Вы снова излишне категоричны. Все эти бубны и пляски с реактивностью действительно экономят время и деньги, но если речь заходит об какой-нибудь узкой, но требовательной к производительности, вещи, то ничего быстрее, чем прямая работа с DOM, вам не придумать.
К сожалению специалистов которые понимают как правильно и прямо работать с DOM исчезающее малое колличество
Это куда проще, чем правильно выстроить тот же Redux. Да и вообще следовать методологиям из ФП.
можно назвать преждевременной оптимизацией
А я не спроста указал use case как "узкую, но требовательную к производительности вещь". Не стоит быть столь категоричным.
Да и вообще, прежде чем использовать тот или иной фреймворк, нужно понять почему и как он работает. А не наоборот.
Проще выучить особенности API всех брайзеров? Нет, React учится за день и работает сносно на большинстве задач. Есть готовые заоптимайзенные компоненты (например для больших гридов).
Есть виртуальный дом.
Если будуте писать всё это руками погрязнете в знаниях которые необходомы для этого и в итоге напишете свою библиотеку.
> Да и вообще, прежде чем использовать тот или иной фреймворк, нужно понять почему и как он работает. А не наоборот.
React настолько маленький и простой что можно это понять за день чтения документации и статей. Узнать какие есть баги и особенности работы разных браузеров… наверно только с опытом.
Проще выучить особенно API всех брайзеров?
Хм… Речь идёт об IE7?
Нет, React учится за день и работает сносно на большинстве задач.
React настолько маленький и простой
Лично у меня не получается рассматривать React обособленно от какой-либо лихой архитектуры, вроде Redux-а. Потому, что в сухом остатке это jsx, чистые функции, односторонний data-binding, работа с component-и через props-ы и пр.
Отвечаю про то что реакт вьюха и мол без Flux или чего-то еще на нем нельзя выстроить архитектуру.
Можно, тут всё что нужно есть, для этого. Если что даже Данил Абрамов не советует брать редакс пока вам хватает просто реакта.
И, кстати говоря, ещё 1 use case, где не нужны никакие Angular-ы и React-ы: преимущественно статичная страница, которой потребовалась небольшая толика интерактивности. Если вы потащите туда современных монстрфреймворков, то сделаете ошибку. Правда jQuery я бы тоже к ним отнёс, как никак 84 KiB. Чаще всего для DOM-удобства хватит нативных методов или небольшой 5 KiB обёртки.
Но если судить по Хабру, да и вообще, повсеместному react-angular-хайпу, все вокруг только и делают, что огромные SPA.
Vanilla js конечно нужна и важна, но всё таки у нас скоуп — SPA. Обсуждение React, Angular и т.п.
Кстати jquery может дружить и с ангуляром и с реактом, но писать на нем большие приложения себе дороже.
Странички где вот тут чуть-чуть добавить интерактивности и там чуть-чуть добавить интерактивности обычно превращаются в монстров
Не соглашусь. Довольно редко.
Там я бы все же делал SPA + серверный рендеринг.
Правда? о_О. Вы бы стали делать обычный бложег на React Flux-ах? Это уже какой-то фанатизм.
Вы полагаете, что человек, который вот так вот заваливает гхм… модный блогодвижок wordpress десятками плагинов, не смог настроить frontend-сборку, прилепил на скорую руку корзину и пр. к своему монстру… ну и т.д… Вы действительно полагаете, что этому человек для полного счастья не хватает View на основе virtualDOM-а?
jQuery это набор инструментов для работы с DOM и не только. А React это вьюха. Причём вьюха такого толка, что по-хорошему к ней требуется грамотная инфраструктура, жел-но на ФП-основе.
Может я чего-то недопонимаю? Да даже KnockoutJS внедрить туда для обеспечения такой функциональности будет значительно резоннее (как минимум меньше крови выпьет).
Я считаю что для этого счатья есть SPA. Но оно требует больше эффортов. Мир не идеален к сожалению.
> jQuery это набор инструментов для работы с DOM и не только. А React это вьюха. Причём вьюха такого толка, что по-хорошему к ней требуется грамотная инфраструктура, жел-но на ФП-основе.
Да из которых чаще всего используются только селекты, ajax и хелперы типо show/hide. В React не нужны селекторы и show/hide, а ajax добавляется любой библитекой. На Реакте очень просто выстроить архитектуру, а вот jQuery и архитектура вещи как правило не совместимые: вездущий coupling и отсутвие тестируемости.
Нет, мы серьезно обсуждаем плюсы и минусы Реакта и Джеквери?
Давай-те я выражу свою мысль по другому и думаю вы согласитесь: сегодня jQuery это отличная подпорка, до тех пор пока в проекте их не становится слишком много. И мой консерн был в том, что так происходит в реальном мире. Не всегда, не в каждом случае. Но происходит.
На Реакте очень просто выстроить архитектуру
Взять, пардон, вьюху… и строить по ней архитектуру? оО. По вьюхе?
Я считаю что для этого счатья есть SPA
Пожалуй этого мне не понять. Наверное я слишком консервативен. Стрелять из пушки по воробьям…
Да и снова у вас какая-то путаница с терминами: хит и есть посещение))))
facepalm.
В рамках одного посещения (сессии) может быть 100500 хитов, минимум будет 1 в выродженном случае. :)
P.S.: о, увидел прогресс! Значит не все веб-проекты являются «сайтами», есть все-таки приложения?!)))))
Все веб-проекты — сайты, если смотреть широко, так как они на HTML и их смотрят через браузер.
Если смотреть узко, то ресурс, используемый в частной сети предприятия, или предоставляющий доступ ограниченному числу лиц (к API), где главное не рюшечки, а функционал.
Это сайт, реализующий ф-и приложения.
цитата
Сайтики — это действительно не моя парафия уже года 4 как. Распределенные web системы — это то, чем я занимаюсь.
Распределенным может быть как «сайтик», так и «приложение», также как и не быть :)
Высокопосещаемый новостной ресурс или ИМ — это всего лишь сайт.
Да, там может быть куча интеграций.
Ну и что?
Сейчас на всех сайтиках куча интеграций. :)
А также приложениями в широком смысле могут называться все готовые программные продукты, в т.ч. все сайтики :)
Если мы говорим о классическом определении «хит» — вы правы. Если говорим в пределах счетчиков — нет. Или у вас счетчик и на статике стоит?)
Так у вас счетчики на статику стоят, из-за этого вы начали выеживатся? :)
Только в этом случае тем более больше хитов будет на посещение…
Вы же говорили, что посещение — это и есть хит.
Ну да, ну да… Гугл — сайтик. Оок.
Пользователь к нему относится как к сайтику.
Фейсбук тоже сайтик.
Когда по вашему сайтик перестает быть сайтиком и стает приложением? Когда он распределенный? :)
Серьезно?)) Ну значит windows xp — это сайт.
Зачем было так ухищрятся.
Сказали бы, в XP есть браузер, значит он сайт :)
Любые электронные деньги — тоже сайты, т.к. большинство работы с ними идет через браузер и отображаются они через html.
А разве они перестали быть сайтом? :)
Или любая вещь, где есть баланс, автоматически становится приложением? :)
П.С.
Этот ответ не успел отправить вчера.
Дальнейший ваш бред и выдумки комментировать желания нет.
Вот два примера, которые приходят сразу в голову:
— wysiwig-редактор на contentEditable/execCommand
— галереи а-ля masonry
Не понял почему какая-то галерея не может быть реализована
Есть простой массив строк. Надо срендерить горизонтальное меню в одну линию, без переносов (фиг с ними со ссылками, обойдемся просто строками с названиями пунктов для этого примера). При этом если в одну линию все не помещается, сделать последним пунктом в горизонтальном меню dropdown (а-ля бутстраповский), в который будет помещено минимально возможное количество таких строк с хвоста. Разумеется, полная резина, обработка resize event и все такое.
Сделайте-ка без обращений к DOM.
Сделайте-ка без обращений к DOM.
А почему, собственно, таким дорогим стал DOM? :)
Это ж не большие данные/таблицы.
Хотя вот у меня новая Опера на 5 вкладках (2 из них одинаковые) съедает 1.3GB :)
Хотя, возможно, это из-за этих оптимизаций все :)
Но вот такие сопляки никогда в своей жизни приличных размеров SPA не писали, просто по той причине что не нужно миру пока столько SPA, сколько развелось реактоебов. Обычно все и заканчивается бложиком на вордпресс, с парой наоверинджениреных компонентов типа какой-нибудь говноформы или более-менее функционального автофила.
А мне жалко горе-фронтэндеров не умеющих в DOM, не знающих про template, DocumentFragment и верящих в магию.
А двусторонний биндинг чем помешал?
— в старых проектах в которых он «уже есть»
— в новых, если команда не знает ничего кроме angular
Появилось чувство что с ней приложения становятся «более полноценными».
По поводу производительности, согласен с комментарием выше (стоит учесть, что никто не обезопасит от написания кривого кода на любой кодовой базе):
https://habrahabr.ru/post/310142/?reply_to=9810878#comment_9810618
Мне всё это напоминает smarty в мире php, когда брали шаблонизатор и строили архитектуру вокруг него. Реакт это такой же тупой шаблонизатор, хватит на него молиться, в нормальной архитектуре это звено, которое вообще должно быть легко заменяемым.
если смотреть в этом ключе — то ваша точка зрения понятна.
Но 21 веке — рассматривать ShadowDOM как «плюс» а не «стандарт», уж извените, звучит печально.
Если отвечать по делу:
возможно вы не заметили, я не упоминал React, и да многие частенько (в том числе и я) используют архитектуру Flux без React-а (потому что она что-то больше чем биндинги).
А на счет «подлагивания» вы приложения на Ангуляре видели? Вот там лаги так лаги. (Смотреть тот же Google Trends)
Shadow DOM (теневой дом) — https://www.w3.org/TR/shadow-dom/
Virtual DOM — https://habrahabr.ru/post/256965/
И каким боком тут вообще view layer? или react?
А view layer очень даже прямым боком, Shadow DOM это изоляция компонентов (один из возможных на сегодняшни день способов), А Virtual DOM способ увеличить перформанс View Layer, которым React и является.
Ведь есть кейс «без angular/react» (без view слоя, то есть со своим) и c flux.
Но 21 веке — рассматривать ShadowDOM как «плюс» а не «стандарт», уж извените, звучит печально.
Почему? Вы не видите frontend разработки без shadowDOM-а?
Eсли написания лапши на ____ (подставьте свое название, в формате jquery, «свой каркас», etc.) — это я наблюдаю каждый день.
Если long running app, где утечки памяти критичны, где нужно использовать любую возможность (я имею ввиду техническую), если она есть — то не вижу.
Вот только не надо на основании этого записывать меня в олдфаги, которые боятся «новых» технологий. Сейчас я пишу на react, до этого был проект на vue, до этого на angular 1 и т.д. Есть с чем сравнивать.
p.s. Я спутал теневой дом с виртуальным, но в любом случае, он ещё не стандарт, а лишь черновик.
Теперь безумные hr будут в каждой вакансии требовать react или angular 2?
// Взято из туториала
import { Component } from '@angular/core';
export class Hero {
id: number;
name: string;
}
@Component({
selector: 'my-app',
template: `
<h1>{{title}}</h1>
<h2>{{hero.name}} details!</h2>
<div><label>id: </label>{{hero.id}}</div>
<div>
<label>name: </label>
<input [(ngModel)]="hero.name" placeholder="name">
</div>
`
})
export class AppComponent {
title = 'Tour of Heroes';
hero: Hero = {
id: 1,
name: 'Windstorm'
};
}
Но еще удобнее юзать вместе с webpack, и каким ни будь лоадером, например Jade (Pug):
@Component({
selector: 'my-app',
template: require('./my-app.jade')
})
А чего там должно стыковаться? Просто ты описываешь возвращаемую строку, в удобном тебе синтаксисе, например в jade.
Из require в компонент вернется просто строка html, такая же, какую бы ты написал от руки.
Т.е. исходя из примера внутри ./my-app.jade было бы что то вроде:
h1 {{title}}
h2 {{hero.name}} details!
div
label id:
| {{hero.id}}
div
label name:
input([(ngmodel)]='hero.name', placeholder='name')С внутренним деревом Jade оно никак не стыкуется, если вопрос в этом.
Еще один большой плюс, такого подхода, это то что нормальная IDE например WebStorm, при переименовании файла шаблона автоматически заменит его во всех местах использования, чего не будет с простой строкой в templateUrl:.
Таким же образом можно подключать и .html файлы, без дополнительного процессинга.
На тему простой строки templateUrl. Поиск замену в строках и комментариях можно подключить галочкой, если что)
С require, если у тебя ошибка в названии файла, у тебя упадет на этапе компиляции в Webpack, а не в рантайме, когда ты откроешь этот компонент.
А поиском по строке пользоваться в проектах с TypeScript…
Ну и styleUrls тоже.
AOT компиляции шаблонов
АОТ предполагает компиляцию непосредственно перед исполнением на машине пользователя. Так что это не АОТ.
В этой статье описывается как можно ужать до 20Кб.
Сколько изгаляться приходится-то :-) на самом деле это порочная практика — сначала подключать всё, а потом хитрыми алгоритмами вырезать лишнее. Куда лучше сразу не подключать лишнего. Для сравнения — наваял "Привет мир" на $mol — получилось 10kb с гзипом, но без минификации, GCC, rollup, tree shaking и прочих плясок с бубнами. :-)
они это называют JIT (Just In Time)
они называют AOT (Ahead Of Time).
Однако весь мир понимает под этими терминами что-то другое.
В mol ведь наверняка нет всех возможностей которые предоставляет Angular 2.
Скорее наоборот.
А исключать то что не нужно (или загружать только когда нужно, деля на модули), удобнее чем не иметь этого вовсе ИМХО.
Удобнее, когда ты можешь просто использовать то, что есть в проекте, без необходимости писать 100500 импортов или один импорт тянущий за собой 100500 зависимостей.
Фактически — в github репозитории angular 2 закрыли 64% issues, помеченных флагом «2.0.0 Final». В концу дня milestone «2.0.0 Final» исчез из репозитория.
На самом деле, если учесть как выходили релиз-кандидаты и планы на будущее, то можно с уверенностью сказать, что Angular 2 и Angular 2 в следующем году — это будут немного разные вещи.
Для нее специально подготовлен quickstart-ng2
Пока находится здесь: quickstart-ng2-beta.3-support
Мне кажется, то каких-то глобальных изменений больше не предвидится, только полировка.
Лично мне по душе роутинг, основанный на состояниях, а не на url.
https://ui-router.github.io/ng2/
Состоялся финальный релиз Angular 2