Pull to refresh

Comments 140

Какие-то подозрительные стати от того автора, как будь-то всеми силами вытягивает react и vdom. Не знаю что-он подкрутил в тестах, но на оригинальном dbmonster, ангуляры рвут реакт.
UFO just landed and posted this here

Но там на текущий момент ангуляр 2 в версии RC5. А к релизу они обещали повысить скорость.


Плюс, в свежих версиях появилась возможность скомпилировать шаблоны заранее и бутстрапить всё уже из модуля @angular/platform-browser (а не из @angular/platform-browser-dynamic), что ускорит первоначальную загрузку приложения, см. https://angular.io/docs/ts/latest/guide/ngmodule.html#bootstrap

Ого! Отличные новости!
Думаю теперь можно и в продакшен проекты выводить на нём, а то эти бесконечные правки в API уже начали пугать.
Сделали улучшенную версию AngularJS =\ Недо-компонентный подход.
Мир будет дальше гавно кодить. Только конечно TypeScript завели, самый большой плюс наверное.
Чтобы в ангуляре переиспользовать часть шаблона — нужно городить компонент либо делать $compile, так было в первом так и осталось во втором. Всё еще директивы, так же убого выглядит template. Всё ещё остался двух-сторонний биндиг в лице NgModel, будем дальше городить странные компоненты форм. Это всё еще лапша из компонентов а не лаконичное f(state) = DOM. Travel Debugging без плясок невозможен. Появился какой-то АОТ компилятор, но он не поможет если я хочу делать темплейты в рантайме, когда нельзя просто сделать For и нельзя завязываться на конкретный компонент.

React как библиотека дает надежный фундамент, да в каждой команде есть свой набор обвязок, но это не минус приложений на реакте, а плюс. Плюс который показывает всю гибкость подхода и неограниченное число возможностей.
Ну как же не вспомнить React)
Я особо не следил за развитием ангуляра, но надеялся что они всё-же сделают нормальные компоненты. Это моя основная претензия к первому ангуляру. Хочется пропсов из React, хочется jsx like шаблоны. Но нет, к сожалению angular 2 не альтернатива React'у.

А чем jsx лучше html для шаблонов?

Практически всем. Выше написал про реюз части шаблона без бойлерплейта компонента (и минусов компонента/директивы). Пропсы которые легко прокидывать, оверрайдить. В реакте компоненты на голову выше.
Ну т.е. хочется чтобы Angular стал React`ом? А зачем, если реакт уже есть и он вас всем устраивает?
Не так, Angular фрэймворк, а React библиотека. Хочется чтобы ангуляр был фреймворком поверх идей в React. Чтобы можно было просто взять Angular а там всё из коробки, сделали за тебя решение. Чтобы легко и быстро стартануть свой первый проект на React. Кстати как раз для этого появился оффициальный create-react-app (https://github.com/facebookincubator/create-react-app)
UFO just landed and posted this here
Можно только порадоваться за Meteor, получается они ушли с Ангуляр на Реакт?
UFO just landed and posted this here
Такие желания нужно не ангулару предьявлять, а реакту)
UFO just landed and posted this here
переиспользовать часть шаблона — нужно городить компонент либо делать $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.
И вообще, каждый выбирает то что ему нравится.
UFO just landed and posted this here

В официальной документации немного иное имелось в виду:


Если у вас список элементов со сложной структурой (внутри нечто большее, чем один <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? Это очень спорно, порог вхождения в ангуляр между тем огромен, и позновать его можно долго.

> Однако, если приложение намечается крупным, то лучше сразу взять готовый фреймворк.

Моё мнение нужно взять то, что более предсказуемое и лучше масштабируется. Это явно не про ангуляр.

А вот расскажите мне, как в реакте использовать полноценный dependency injection.
Не то, чтобы в angular он был сделан идеально (вовсе нет, там самая примитивная реализация из возможных), но он там хотя бы есть.
Это пока единственное, что меня останавливает. Завязываться на конкретные реализации в виде явных импортов для меня неприемлемо.
Service locator-ы не подойдут, нужна инъекция. Варианты с кодогенерацей/метаданными/препроцессингом — годятся.
По сути сейчас весь DI в react делается через HOC, тот же connect, который делает инжекшен стейта и экшен крейторов в компоненты.

Я сам из мира 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
Я согласен на TS (это даже предпочтительно). Вязаться на интерфейсы — это вообще идеально. Мне нравится, как сделано тут: https://github.com/aurelia/dependency-injection

Вопрос в том, как прицепиться к внутренней реактовской фабрике компонентов. Понятно, что constructor injection вряд ли реализуем, но хотя бы в приватные поля бы, а-ля autowired…

Все эти проекты, которые я видел, вроде умеют инжектить только в корневой компонент, это неинтересно :)
Можно всё что угодно прокинуть корневому компоненту и детям через context https://facebook.github.io/react/docs/context.html

Пример с редакс-стором
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
В babel/flow есть import/export types. С тайпскрипт-интерфейсами наверняка можно что-то подобное, надо погуглить.

В крайнем случае можно генерировать из интерфейсов эмуляцию 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 во втором ангуляре довольно удобно. Пример приводить не буду, можно посмотреть в доках или англоязычных статьях.

Не нашел в доках как 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 прежде чем делать неправильные выводы.

UFO just landed and posted this here
Надежный фундамент для лапши и проблем с производительностью.

Если вы в 2016 не поняли что руками DOM лучше не трогать, то мне вас искренне жаль.
И тем более делать селекторы в JS.
Если вы в 2016 не поняли что руками DOM лучше не трогать, то мне вас искренне жаль.

Вы снова излишне категоричны. Все эти бубны и пляски с реактивностью действительно экономят время и деньги, но если речь заходит об какой-нибудь узкой, но требовательной к производительности, вещи, то ничего быстрее, чем прямая работа с DOM, вам не придумать.

К сожалению специалистов которые понимают как правильно и прямо работать с DOM исчезающее малое колличество. Поэтому для продукта стоит в первую очередь взять фрэймворк/библиотеку, а потом уже пытаться быть оптимизатором. В общем случае попытка написать большой продукт «правильной, прямой работой с DOM» можно назвать преждевременной оптимизацией.
К сожалению специалистов которые понимают как правильно и прямо работать с DOM исчезающее малое колличество

Это куда проще, чем правильно выстроить тот же Redux. Да и вообще следовать методологиям из ФП.


можно назвать преждевременной оптимизацией

А я не спроста указал use case как "узкую, но требовательную к производительности вещь". Не стоит быть столь категоричным.


Да и вообще, прежде чем использовать тот или иной фреймворк, нужно понять почему и как он работает. А не наоборот.

> Это куда проще, чем правильно выстроить тот же Redux. Да и вообще следовать методологиям из ФП.

Проще выучить особенности API всех брайзеров? Нет, React учится за день и работает сносно на большинстве задач. Есть готовые заоптимайзенные компоненты (например для больших гридов).
Есть виртуальный дом.

Если будуте писать всё это руками погрязнете в знаниях которые необходомы для этого и в итоге напишете свою библиотеку.

> Да и вообще, прежде чем использовать тот или иной фреймворк, нужно понять почему и как он работает. А не наоборот.

React настолько маленький и простой что можно это понять за день чтения документации и статей. Узнать какие есть баги и особенности работы разных браузеров… наверно только с опытом.
Проще выучить особенно API всех брайзеров?

Хм… Речь идёт об IE7?


Нет, React учится за день и работает сносно на большинстве задач.
React настолько маленький и простой

Лично у меня не получается рассматривать React обособленно от какой-либо лихой архитектуры, вроде Redux-а. Потому, что в сухом остатке это jsx, чистые функции, односторонний data-binding, работа с component-и через props-ы и пр.

Да нет, вот например баги в firefox https://bugzilla.mozilla.org/buglist.cgi?quicksearch=dom

Отвечаю про то что реакт вьюха и мол без Flux или чего-то еще на нем нельзя выстроить архитектуру.

Можно, тут всё что нужно есть, для этого. Если что даже Данил Абрамов не советует брать редакс пока вам хватает просто реакта.

И, кстати говоря, ещё 1 use case, где не нужны никакие Angular-ы и React-ы: преимущественно статичная страница, которой потребовалась небольшая толика интерактивности. Если вы потащите туда современных монстрфреймворков, то сделаете ошибку. Правда jQuery я бы тоже к ним отнёс, как никак 84 KiB. Чаще всего для DOM-удобства хватит нативных методов или небольшой 5 KiB обёртки.


Но если судить по Хабру, да и вообще, повсеместному react-angular-хайпу, все вокруг только и делают, что огромные SPA.

Реакт займет примерно те же кб что и jquery. Странички где вот тут чуть-чуть добавить интерактивности и там чуть-чуть добавить интерактивности обычно превращаются в монстров (примеры блоги на wordpress). Там я бы все же делал SPA + серверный рендеринг.

Vanilla js конечно нужна и важна, но всё таки у нас скоуп — SPA. Обсуждение React, Angular и т.п.

Кстати jquery может дружить и с ангуляром и с реактом, но писать на нем большие приложения себе дороже.
Странички где вот тут чуть-чуть добавить интерактивности и там чуть-чуть добавить интерактивности обычно превращаются в монстров

Не соглашусь. Довольно редко.


Там я бы все же делал SPA + серверный рендеринг.

Правда? о_О. Вы бы стали делать обычный бложег на React Flux-ах? Это уже какой-то фанатизм.

К сожалению часто на wordpress делают вещи сложнее чем обычный бложек, где сначала подпилят формочки, потом менюшечку, потом анимацию, добавят ленту твиттера, фейсбука, вк. Добавят корзину, чекаут. Видел сайты на wp с 30+ js скриптами. Конечно нельзя сравнивать плагинную систему предназначенную для простых пользователей и фреймворк для написания веб приложений. Я вообще говорил о том, что места где подключают jquery можно часто заменить на react и получить тот же эффект.

Вы полагаете, что человек, который вот так вот заваливает гхм… модный блогодвижок wordpress десятками плагинов, не смог настроить frontend-сборку, прилепил на скорую руку корзину и пр. к своему монстру… ну и т.д… Вы действительно полагаете, что этому человек для полного счастья не хватает View на основе virtualDOM-а?


jQuery это набор инструментов для работы с DOM и не только. А React это вьюха. Причём вьюха такого толка, что по-хорошему к ней требуется грамотная инфраструктура, жел-но на ФП-основе.


Может я чего-то недопонимаю? Да даже KnockoutJS внедрить туда для обеспечения такой функциональности будет значительно резоннее (как минимум меньше крови выпьет).

> Вы полагаете, что человек, который вот так вот заваливает гхм… модный блогодвижок wordpress десятками плагинов, не смог настроить frontend-сборку, прилепил на скорую руку корзину и пр. к своему монстру… ну и т.д… Вы действительно полагаете, что этому человек для полного счастья не хватает View на основе virtualDOM-а?

Я считаю что для этого счатья есть SPA. Но оно требует больше эффортов. Мир не идеален к сожалению.

> jQuery это набор инструментов для работы с DOM и не только. А React это вьюха. Причём вьюха такого толка, что по-хорошему к ней требуется грамотная инфраструктура, жел-но на ФП-основе.

Да из которых чаще всего используются только селекты, ajax и хелперы типо show/hide. В React не нужны селекторы и show/hide, а ajax добавляется любой библитекой. На Реакте очень просто выстроить архитектуру, а вот jQuery и архитектура вещи как правило не совместимые: вездущий coupling и отсутвие тестируемости.

Нет, мы серьезно обсуждаем плюсы и минусы Реакта и Джеквери?

Давай-те я выражу свою мысль по другому и думаю вы согласитесь: сегодня jQuery это отличная подпорка, до тех пор пока в проекте их не становится слишком много. И мой консерн был в том, что так происходит в реальном мире. Не всегда, не в каждом случае. Но происходит.
На Реакте очень просто выстроить архитектуру

Взять, пардон, вьюху… и строить по ней архитектуру? оО. По вьюхе?


Я считаю что для этого счатья есть SPA

Пожалуй этого мне не понять. Наверное я слишком консервативен. Стрелять из пушки по воробьям…

UFO just landed and posted this here
Сразу после того как вы напишите мне на чистом jquery тоже самое. Очень нужно, так нужно что даже в гугле забанили https://github.com/enaqx/awesome-react#forms
UFO just landed and posted this here
В SPA есть смысл тогда, когда много хитов за посещение (по сути это не сайт, а приложение/админка)…
UFO just landed and posted this here
Да и снова у вас какая-то путаница с терминами: хит и есть посещение))))

facepalm.
В рамках одного посещения (сессии) может быть 100500 хитов, минимум будет 1 в выродженном случае. :)

P.S.: о, увидел прогресс! Значит не все веб-проекты являются «сайтами», есть все-таки приложения?!)))))

Все веб-проекты — сайты, если смотреть широко, так как они на HTML и их смотрят через браузер.
Если смотреть узко, то ресурс, используемый в частной сети предприятия, или предоставляющий доступ ограниченному числу лиц (к API), где главное не рюшечки, а функционал.
Это сайт, реализующий ф-и приложения.

цитата
Сайтики — это действительно не моя парафия уже года 4 как. Распределенные web системы — это то, чем я занимаюсь.

Распределенным может быть как «сайтик», так и «приложение», также как и не быть :)

Высокопосещаемый новостной ресурс или ИМ — это всего лишь сайт.
Да, там может быть куча интеграций.
Ну и что?
Сейчас на всех сайтиках куча интеграций. :)

А также приложениями в широком смысле могут называться все готовые программные продукты, в т.ч. все сайтики :)
UFO just landed and posted this here
Это у вас каша. :)

Если мы говорим о классическом определении «хит» — вы правы. Если говорим в пределах счетчиков — нет. Или у вас счетчик и на статике стоит?)

Так у вас счетчики на статику стоят, из-за этого вы начали выеживатся? :)
Только в этом случае тем более больше хитов будет на посещение…
Вы же говорили, что посещение — это и есть хит.

Ну да, ну да… Гугл — сайтик. Оок.

Пользователь к нему относится как к сайтику.
Фейсбук тоже сайтик.

Когда по вашему сайтик перестает быть сайтиком и стает приложением? Когда он распределенный? :)

Серьезно?)) Ну значит windows xp — это сайт.

Зачем было так ухищрятся.
Сказали бы, в XP есть браузер, значит он сайт :)

Любые электронные деньги — тоже сайты, т.к. большинство работы с ними идет через браузер и отображаются они через html.

А разве они перестали быть сайтом? :)

Или любая вещь, где есть баланс, автоматически становится приложением? :)

П.С.
Этот ответ не успел отправить вчера.
Дальнейший ваш бред и выдумки комментировать желания нет.
UFO just landed and posted this here
Есть вещи, которые без трогания DOM просто-напросто нереализуемы.

Вот два примера, которые приходят сразу в голову:
— wysiwig-редактор на contentEditable/execCommand
— галереи а-ля masonry
Afaik тут полная абстракция над DOM https://github.com/facebook/draft-js
Не понял почему какая-то галерея не может быть реализована
Давайте я вам попроще задачку дам.
Есть простой массив строк. Надо срендерить горизонтальное меню в одну линию, без переносов (фиг с ними со ссылками, обойдемся просто строками с названиями пунктов для этого примера). При этом если в одну линию все не помещается, сделать последним пунктом в горизонтальном меню dropdown (а-ля бутстраповский), в который будет помещено минимально возможное количество таких строк с хвоста. Разумеется, полная резина, обработка resize event и все такое.
Сделайте-ка без обращений к DOM.
Сделайте-ка без обращений к DOM.

А почему, собственно, таким дорогим стал DOM? :)
Это ж не большие данные/таблицы.

Хотя вот у меня новая Опера на 5 вкладках (2 из них одинаковые) съедает 1.3GB :)
Хотя, возможно, это из-за этих оптимизаций все :)
Ух ты, прикольно!

Но, конечно, это чит — я просил dropdown :)
А вы в этом плане. Нет, обращение к нему конечно придется сделать, но манипулировать DOM'ом — нет. Самое главное что после мониторвания реакт в каком-то месте, больше не понадобится иметь не единого селектора в коде.
ахаха. код то читался? в таком то охуеннейшем примере. реакт редактор…
Да штука еще и в том, что некоторые вещи удобнее и логичнее реализовать нативно взаимодействуя с DOM.
Но вот такие сопляки никогда в своей жизни приличных размеров SPA не писали, просто по той причине что не нужно миру пока столько SPA, сколько развелось реактоебов. Обычно все и заканчивается бложиком на вордпресс, с парой наоверинджениреных компонентов типа какой-нибудь говноформы или более-менее функционального автофила.

А мне жалко горе-фронтэндеров не умеющих в DOM, не знающих про template, DocumentFragment и верящих в магию.

Сорри, но template и DocumentFragment не как не помогут вам с производительностью. Вы все равно придете или к идеям idom или vdom, либо в процессе разработки приложения напишите свой велосипед.

Угу, угу. Никак. Да, действительно, я написал уже кучу велосипедов на эту тему, и они мне помогают благополучно объезжать реактовские огороды стороной, и не плакать над производительностью в задачах, связанных со всякими риал-тайм редакторами (как вам тут писали уже).

А двусторонний биндинг чем помешал?

Ничего не имею против Angular2, но во многом использовать его в дальнейшем можно:
— в старых проектах в которых он «уже есть»
— в новых, если команда не знает ничего кроме angular
Какую вы предлагаете полноценную альтернативу, если команда сферически может знать не только Angular?

Aurelia, мне кажется, лучшая из возможных альтернатив.

UFO just landed and posted this here
Ваши предложения по вариантам для нового проекта?в комментарии выше спросили быстрее
На абсолютную истину не претендую, но на данный момент я склоняюсь к архитектуре flux.
Появилось чувство что с ней приложения становятся «более полноценными».
По поводу производительности, согласен с комментарием выше (стоит учесть, что никто не обезопасит от написания кривого кода на любой кодовой базе):
https://habrahabr.ru/post/310142/?reply_to=9810878#comment_9810618
У меня более десяти лет опыта писания на javascript, по моим ощущениям связка react + flux это худшее с чем мне приходилось работать. Не понимаю откуда такой хайп. Единственный плюс это теневой дом, который в теории должен обеспечить лучшую производительность, но на практике постоянно встречаю подлагивание реакт приложений начиная с самого facebook.

Мне всё это напоминает smarty в мире php, когда брали шаблонизатор и строили архитектуру вокруг него. Реакт это такой же тупой шаблонизатор, хватит на него молиться, в нормальной архитектуре это звено, которое вообще должно быть легко заменяемым.
Могу предположить что если вы начали 10 лет назад, то писали код для популярного в те времена IE 6.0,
если смотреть в этом ключе — то ваша точка зрения понятна.
Но 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?
Выше сказали что Реакт использует внутри Shadow DOM. А вы даже не заметили. Вот я и возмутился.

А view layer очень даже прямым боком, Shadow DOM это изоляция компонентов (один из возможных на сегодняшни день способов), А Virtual DOM способ увеличить перформанс View Layer, которым React и является.
по большей части с вами согласен, но есть одно но — как только оговорил Flux все вспомнили react. ))
Ведь есть кейс «без angular/react» (без view слоя, то есть со своим) и c flux.
Да, понятно что flux и redux в частности это просто принцип, архитектура. Я пробовал ng-redux. И могу сказать что лучше всего сегодня flux всё-таки работает с React. Но и в ангуляре он неплох, просто производительность начинает страдать, нужно разбивать очень гранулярно компоненты, а это не всегда удобно.
Но 21 веке — рассматривать ShadowDOM как «плюс» а не «стандарт», уж извените, звучит печально.

Почему? Вы не видите frontend разработки без shadowDOM-а?

смотря что вы имеете ввиду.
Eсли написания лапши на ____ (подставьте свое название, в формате jquery, «свой каркас», etc.) — это я наблюдаю каждый день.
Если long running app, где утечки памяти критичны, где нужно использовать любую возможность (я имею ввиду техническую), если она есть — то не вижу.
Всё печальнее, я писал даже под IE 5.5, а ajax реализовывали через тег img и не боялись xslt в браузере.
Вот только не надо на основании этого записывать меня в олдфаги, которые боятся «новых» технологий. Сейчас я пишу на react, до этого был проект на vue, до этого на angular 1 и т.д. Есть с чем сравнивать.

p.s. Я спутал теневой дом с виртуальным, но в любом случае, он ещё не стандарт, а лишь черновик.
«Желательно знание jquery, backbone, react, angular»
Они и так уже требуют. И еще делают круглые глазёнки когда им говоришь «только голый jquery» и «никаких реактов в продакшене»
А потом к тебе подходит тимлид, делает круглые глазенки и говорит: «Никакого jquery, только чистый JS»
А потом выясняется, что они и браузер свой пишут.
Когда ты при этом сам тимлид диаметр глазёнок увеличивается еще на n
UFO just landed and posted this here
Опыт разработки на angular2 от трех лет
hr ведь не сами это придумывают, требования к кандидатам передают те кто формирует команду (менеджеры, тимлиды, итд).
Я правильно понимаю что шаблоны компонентов пишутся в строках при объявлении компонента? Что-то вроде:
// Взято из туториала
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'
  };
}
Как уже заметили есть еще templateUrl.
Но еще удобнее юзать вместе с webpack, и каким ни будь лоадером, например Jade (Pug):

@Component({
  selector: 'my-app',
  template: require('./my-app.jade')
})
Интересная мысль (я про Jade). А как оно стыкуется с компонентами и директивами Angular'а?

А чего там должно стыковаться? Просто ты описываешь возвращаемую строку, в удобном тебе синтаксисе, например в 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…

Я уверен, что имелась в виду эта галочка:


Скриншот интерфейса переименования файла в PyCharm

image


Если ее включить, то "нормальная IDE например WebStorm" будет файл искать в строках и комментариях, вне зависимости от того, является ли строка аргументом функции require или нет.

с find usages так же попробуй. Галочкой не включишь.

Отлично стыкуется. Вот только актуальная версия jade переименована в pug.
Ребята из AngularClass — написали лоадеры, которые умеют это делать через templateUrl.
Ну и styleUrls тоже.
А размер минифицированного файла фреймворка так и остался в районе 600кб?
При сборке анализируются компоненты которые необходимо включить в продакшен билд, простенькое приложение с одним компонентом и самым базовым биндингом, у меня занимало порядка 2кб
UFO just landed and posted this here
AOT компиляции шаблонов

АОТ предполагает компиляцию непосредственно перед исполнением на машине пользователя. Так что это не АОТ.


В этой статье описывается как можно ужать до 20Кб.

Сколько изгаляться приходится-то :-) на самом деле это порочная практика — сначала подключать всё, а потом хитрыми алгоритмами вырезать лишнее. Куда лучше сразу не подключать лишнего. Для сравнения — наваял "Привет мир" на $mol — получилось 10kb с гзипом, но без минификации, GCC, rollup, tree shaking и прочих плясок с бубнами. :-)

UFO just landed and posted this here

Появится до конца месяца.

UFO just landed and posted this here
они это называют JIT (Just In Time)
они называют AOT (Ahead Of Time).

Однако весь мир понимает под этими терминами что-то другое.


В mol ведь наверняка нет всех возможностей которые предоставляет Angular 2.

Скорее наоборот.


А исключать то что не нужно (или загружать только когда нужно, деля на модули), удобнее чем не иметь этого вовсе ИМХО.

Удобнее, когда ты можешь просто использовать то, что есть в проекте, без необходимости писать 100500 импортов или один импорт тянущий за собой 100500 зависимостей.

UFO just landed and posted this here
А правда были люди, которые его всего еще ждали до последнего? У меня возникло ощущение, что где-то в конце прошлого года Angular 2 просто исчез из обсуждений во всех сообществах, за которыми я слежу, и никому до него больше нет дела. Вчера, когда он таки вышел, его как-то по инерции помянули незлым тихим словом и пошли дальше использовать React/Vue/…

Не только ждали, а ещё и вполне себе активно использовали (даже в проде).

Angular 2 Final вышел лишь формально и был приурочен к митапу от Google.
Фактически — в github репозитории angular 2 закрыли 64% issues, помеченных флагом «2.0.0 Final». В концу дня milestone «2.0.0 Final» исчез из репозитория.
А можно немного объяснить, что это значит?
Это значит, Angular 2.0.0 чуть более сырой, чем хотелось бы быть, а фиксы, которые изначально планировалось внести в 2.0.0 final, будут внесены в версии 2.0.1
Главная фишка 2.0.0 — обратная совместимость в течении 6 месяцев.
Очевидно, автор комментария предостерегает вас от использования Angular 2 в продакшене :)
На самом деле, если учесть как выходили релиз-кандидаты и планы на будущее, то можно с уверенностью сказать, что Angular 2 и Angular 2 в следующем году — это будут немного разные вещи.
Теперь нужно новое ожидание праздника — Angular 3?
Кстати, уже вполне можно использовать наш любимый ui-router начиная с версии 1.0.0-beta.3, которая выходит на днях.
Для нее специально подготовлен quickstart-ng2
Пока находится здесь: quickstart-ng2-beta.3-support
Мне кажется, то каких-то глобальных изменений больше не предвидится, только полировка.
Т.е. стандартный роутинг убог и ангуляру срочно нужен новый роутер? История повторяется, или просто парням с angular.ui очень хочется чтобы пользовались их роутером?
Я бы так не сказал… скорее он просто другой.
Лично мне по душе роутинг, основанный на состояниях, а не на url.

На состояниях — это о чём речь?

Ну как бы состояния приложения задаются стейтами: public, public.home, public.about, private, private.home и т.д.
В итоге состояние приложения может изменяться даже тогда, когда url в строке не меняется.

А, так это вообще антипаттерн. Нарушение инварианта — типичная ошибка при императивном программировании.

Думаю, важно было бы также отметить, что Ангулар перешел на Семантическое Версионирование http://semver.org/ и что третья версия Ангулара ожидается уже в феврале след. года.
https://toddmotto.com/angular-3-alpha
Sign up to leave a comment.

Articles