По каким-то причинам Вы считаете, что View — это не JS? React представляет собой идею функционального подхода к програмимрованию пользовательских интерфейсов, соответственно не имеет ничего общего с MVC и стараться «подбить» его к знакомой терминологии не имеет смысла.

Если IDE не поддерживает JSX то все совсем не удобно.

Ну, во-первых, уже, наверное, не осталось IDE, которые не поддерживают JSX, а во-вторых Вы всегда можете писать без JSX через React.DOM.div и т.п.

Timmmm 22 окт 2015 в 17:46

Что бы вы не говорили, но единственная задача view это отрисовка. Нельзя мешать представление с моделью.

xamd 22 окт 2015 в 17:53

Конечно, React вообще не должен ничего знать о данных, которые поступают в его компоненты! Поэтому и появился flux — чтобы решить проблему работы с данными и коммуникацией между компонентами. Довольно тяжело сейчас говорить о React без упоминания Flux.

batmandarkside 23 окт 2015 в 10:20

Раньше как и вы мыслил. Пришло время адаптироваться. И я понял что так намного удобнее. Нет больше трёх разных сущностей как html css js. Есть одна — веб компонент. Для этого мы и держим все в одной папке, составляющие компонента. Держать разметку в js отличная идея, удобно. Как правило разметка не большая. Если у вас вёрстки в компоненте на целую страницу, значит что то пошло не так !)

Timmmm 23 окт 2015 в 10:43

Не буду с вами спорить, если вам удобно… Но архитектурно это не правильно, вас поставили в рамки которые противоречат здравому смыслу. Все это выглядит как костыль. Напоминает сервлеты от которых отказались, в плане верстки, уже очень давно.

batmandarkside 23 окт 2015 в 11:25

Яснопонятно

НЛО прилетело и опубликовало эту надпись здесь

kambur 22 окт 2015 в 14:37

Я не уверен, что в случае с React есть необходимость разделять код от от представления.
Но тут все зависит от индивидуальных предпочтений.
Если разработчик создает много компонентов и помещает все это в один файл, получается каша. Тогда есть смысл как-то навести порядок и разделить js от html
Но я сторонник модульного подхода к разработке. Один компонент — один маленький блок html + код реализации логики.

kambur 22 окт 2015 в 14:40

По большому счету можно вобще отказаться от html в компонентах и писать все на чистом React.
В таком случае ваши компоненты будут универсальными.

kambur 22 окт 2015 в 12:05

Я думаю, что разработчикам в будущем не помешает
1. Добавить поддержку темплейтов
2. Улучшить работу со свойствами (скажем придумать объект parent через который потомок может изменять состояние родителя)

xamd 22 окт 2015 в 13:45

1. О каких темплейтах Вы говорите?
2. Никакого two-way data-binding. Все свойства передаются от родителя к потомку и никак иначе. А вообще, для работы с данными в React существует множество библиотек (например, redux)

DeLaVega 23 окт 2015 в 11:41

По второму пункту, так на секундочку — https://www.npmjs.com/package/react-binding

xamd 25 окт 2015 в 21:59

«Так на секундочку» — 115 скачек за последний месяц + 14 звёзд на GH и 2 issue за 5 месяцев. Я бы не полагался на подобную библиотеку при проектировании приложения, особенно если она идёт вразрез оф. идеологии.

Видимо, я не совсем ясно выразился: разумеется, сделать можно всё что угодно — это js, в конце концов. Вы так же можете использовать родной хак: facebook.github.io/react/docs/two-way-binding-helpers.html, однако даже на этой странице написано, что React спроектирован как one-way data flow система.

i360u 22 окт 2015 в 16:30

Шаблоны вполне можно делать в виде методов, получающих данные и возвращающих верстку, например.

xamd 25 окт 2015 в 22:01

Это называется «dumb components» и в React 0.14 реализуется с помощью обычных функций:

// A functional component using an ES2015 (ES6) arrow function:
var Aquarium = (props) => {
  var fish = getFish(props.species);
  return <Tank>{fish}</Tank>;
};

// Or with destructuring and an implicit return, simply:
var Aquarium = ({species}) => (
  <Tank>
    {getFish(species)}
  </Tank>
);

// Then use: <Aquarium species="rainbowfish" />

Взято из пресс-релиза 0.14

i360u 26 окт 2015 в 08:52

Dumb component, насколько я понимаю, это просто обертка в виде кастомного тега, содержащая верстку и не содержащая внутренней логики. Что-то типа:

<div>{this.props.children}</div>

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

xamd 26 окт 2015 в 11:12

Основная идея, «пропитывающая» реакт — композиция элементов. Т.е. «шаблон вывода» в Вашем понимании составляется из маленьких dumb components, которые при аггрегации образуют то, что Вам нужно.

Разумеется, где-то вверху будет находится smart component, который будет оркестрировать весь процесс: забирать данные из какого-нибудь хранилища (будь то что-то самописное, redux store или что либо ещё) и передавать эти данные в ваши dumb components и, возможно, содержать логику а-ля «если количество записей больше нуля, показывать dumb component со списком записей, в противном случае показывать заглушку с сообщением об отсутствии записей». По факту весь реакт — это один большой шаблон, если так посмотреть :)

DmitryOlkhovoi 26 окт 2015 в 11:17

Я поддерживаю, в реакте есть ровно все, что необходимо и следует придерживаться композитных компонентов и чистых функций

prog666 22 окт 2015 в 12:06

Это такая «фишка» реакта, мне вначале казалось неудобным, но быстро привыкаешь и начинаешь даже любить эту схему. А вообще можно использовать jade шаблоны. Посмотрите на react-jade.

НЛО прилетело и опубликовало эту надпись здесь

prog666 22 окт 2015 в 12:11

Выходит что код разделен на маленькие модули всегда, и очень часто нужно менять разметку вместе с JS, в данном случае проще ничего не забыть ибо все на виду

НЛО прилетело и опубликовало эту надпись здесь

CJay 22 окт 2015 в 13:06

На мой взгляд, вычленять разметку из JSX не стоит. Почему?
1) Метод render у меня ещё ни разу не оказывался больше высоты экрана (обычно вообще строк 12-20).
2) В шаблоне логики вообще нет, никаких условных конструкций или циклов. Вся логика реализована выше в самом JS.
3) Желательно видеть, какие ноды какими ref я подписал, или какой метод вызвать при каком-то событии. Значит всё должно быть под рукой, а не переключаться между двумя файлами.

Причины за «выделение шаблона в отдельный файл» мне в голову не приходят. Станет хуже.

P.S.
По началу тоже думал, что html в JS — это какая-то дикость. Но изменил свою точку зрения. По поводу поддержки IDE — работал с jsx в Sublime без какой либо поддержки React, подсветки синтаксиса JS вполне хватало.

НЛО прилетело и опубликовало эту надпись здесь

JCHouse 22 окт 2015 в 23:50

Согласен, то что с первого взгляда кажется дикостью, после месяца подсаживает на именно такой стиль написания кода. Все что можно вынести в другой компонент выносится и html не выглядит грамоздко.

serf 22 окт 2015 в 18:19

Может быть человек давно начинал с PHP и с тех пор полюбил подход мешать код и разметку вместе. Фейсбук вот тоже с PHP дружит, вот и сделали в своем родном стиле.

arvitaly 22 окт 2015 в 12:12

Выносить можно, так как по сути в итоге там обычное JS-выражение. Т.е. его можно записывать в переменную, экспортировать из модуля и т.д. На практике, это обычно не нужно, так как если HTML-кода становится очень много, значит компонент плохой, а небольшое количество HTML-кода в методе render не мешает.

Так же в TypeScript запилили поддержку JSX (TSX) с проверкой типов, компиляцией и подсветкой. Пока сыровато, но обещает быть очень вкусно.

В целом, другого пути, кроме смешения JS и HTML, особо и нет, выдумывать тонны селекторов и писать отдельно обработчики событий больше нет желания, спрашивается, с чего начинали…

Igogo2012 22 окт 2015 в 12:14

Во перых это не JS, а JSX
И по сути react это и есть умный темплейтовый движок, так что любые файлы с расширением .jsx в проекте написанном на реакте по своей сути являются темплейтами, а уже как фреймворк отвечающий за логику можно брать до пустим backbone.

НЛО прилетело и опубликовало эту надпись здесь

Igogo2012 22 окт 2015 в 12:26

JUST THE UI
Lots of people use React as the V in MVC. Since React makes no assumptions about the rest of your technology stack, it's easy to try it out on a small feature in an existing project.

Из офф сайта реакта, даже разработчики утверждают что большенство людей используют его как View в MVС.
По всей своей сути react это как бы описание UI объекта.
И для того что бы не смешивать реальный JS и не тулить туда еще и разметку, разработчиками был выбран альтернативный формат .jsx который и решает данную задачу.
То есть в любом случае в Ваших jsx файлах будет как минимум не много js-подобного кода и xml-разметка (по тому что это точно не html).
Но логику и обработку данных все же лучше выносить в контроллеры и модельки Вашего приложения, дабы View оставался максимально чистым.

xamd 22 окт 2015 в 13:41

JSX используется в качестве препроцессора для улучшения «читабельности» кода. «Под капотом» оно транслируется в ES5-совместимый формат, т.е.

render() {
  return <div>hello</div>;
}

будет транслирован в

render() {
  return React.DOM.div(null, 'hello');
}

Разумеется, вы можете использовать вторую версию без каких-либо препроцессоров. Об это подробнее на оф. сайте. Так же, в версии 0.14 работа с DOM вынесена в отдельную библиотеку react-dom.

Delphinum 22 окт 2015 в 14:07

Попробуйте RequireJS с плагином text.

Sunify 22 окт 2015 в 14:11

По факту, это не то чтобы разметка. Это язык описания дерева UI, т.е. он включает в себя, помимо тегов, вызовы компонент. А в случае с каким-нибудь React Native, там вообще нет привычных тегов.

timramone 22 окт 2015 в 23:11

Не нужно выносить разметку. Она связана с логикой приложения, и это не coupling, это cohesion. Компонент — это логика и представление. Тут SRP не по принципу «ты определяешь представление (как будет выглядеть какой-то элемент)» и «ты определяешь логику (как взаимодействовать с конкретным элементом)», а по принципу «ты инкапсулированный компонент, в тебе представление и логика его отображения».
Тут правда есть нюанс с тем, как верстальщика с этим работать заставить. У нас процесс построен, что верстальщик концептуально верстает элементы управления, а мы уже из этой вёрстки создаём компоненты, так что у нас нет проблемы.
На эту тему есть совершенно прекрасный доклад Александра Соловьева Как писать UI без боли. Вообще у него совершенно потрясающие видео на YouTube, очень советую и другие посмотреть :)

prog666 22 окт 2015 в 12:00

Если уж все равно приходится использовать browserify или webpack то можно было бы писать на es2015/es6, babel (babelify) отлично понимает jsx и в самой документации реакта есть примеры как можно использовать нативные классы в создании компонентов. Если интересно могу показать примеры gulpfile для сборки.

kambur 22 окт 2015 в 12:06

Это было бы здорово

prog666 22 окт 2015 в 12:31

Вот пример JS таска

VasilioRuzanni 22 окт 2015 в 14:36

Добавлю, что Babel не только понимает JSX, но и сама команда React'а даже отказалась от своих наработок и рекомендует использовать Babel для трансформации.

timramone 22 окт 2015 в 23:12

Или txs ;)

aTwice 22 окт 2015 в 12:53

Как потомок может влиять на данные своего родителя? Очень просто:

и далее простыня кода без комментариев.
Вы бы хоть полужирным выделили изменения по отношению к предыдущей простыне.

kambur 22 окт 2015 в 15:03

Вы абсолютно правы. Приношу свои извинения и бегу писать коменты.

andreysmind 22 окт 2015 в 13:16

Вот вам задачка: как организовать двунаправленный обмен данными между компонентами?

Может лучше сразу к Flux привыкать?
Вроде даже в Angular 2 от двунаправленного обменами данных решили отказаться?

VasilioRuzanni 22 окт 2015 в 14:55

И в Angular 2, и в Ember 2 тоже (и там, и там — плотно советуясь с командой React), и на Angular 1 тоже в итоге для больших приложений получается удобнее писать (субъективно), когда есть явная передача данных «туда» и «обратно».

Однако, часто бывает удобен и 2-way-binding, но надо понимать, когда его лучше использовать (в Aurelia он хорошо сделан и лишен недостатков оного в Angular 1) — тут создатели разных фреймворков вроде как сошлись во мнении, что правильный 2-way-binding — это сахар над one-way-binding для отдельных случаев (именно такой подход используется в ng2 с его жуткими "([...])" скобками в шаблонах и похожий в Aurelia с его «адаптивными байндингами»).

kambur 22 окт 2015 в 20:20

Flux — я за!!!

НЛО прилетело и опубликовало эту надпись здесь

kambur 22 окт 2015 в 15:51

Тут я с вами абсолютно не согласен. Для вас, как опытного программиста, статья действительно может показаться убожеством. Просто она предназначена не для вас. Я не преследовал цель создать первоклассный туториал, их и так как листьев на деревьях. А что делать человеку, который только, только делает первые шаги по пути фронт-енд разработки? Кто ему подскажет, кто направит?
Меня сильно раздражают напыщенные индюки вроде вас, которые только и умеют критиковать. Нет чтобы помочь, подсказать и сделать статью лучше. Ведь конечная цель — помощь людям!

НЛО прилетело и опубликовало эту надпись здесь

kambur 22 окт 2015 в 16:51

Поживем — увидим.
Как говорил Максим Горький:
… Мудрость жизни всегда глубже и обширнее мудрости людей.

ua9msn 22 окт 2015 в 17:11

Миксины все.

n0ne 23 окт 2015 в 12:46

Может кто-то посоветует приличные компаненты для работы с формами? Валидация, локализация, кастомизация и т.п.
А так же кучу-кучу всяких компонентов для этих форм.
Может кому-то удалось локализировать DatePicker из Material UI?