Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 59
Вопрос хороший. Честно говоря, я пока над этим не задумывался.
Пока пробую JSX
Можно использовать SublimeText или Atom.io
Т.е. проблема разделения вьюхи и Js остается
По каким-то причинам Вы считаете, что View — это не JS? React представляет собой идею функционального подхода к програмимрованию пользовательских интерфейсов, соответственно не имеет ничего общего с MVC и стараться «подбить» его к знакомой терминологии не имеет смысла.
Если IDE не поддерживает JSX то все совсем не удобно.
Ну, во-первых, уже, наверное, не осталось IDE, которые не поддерживают JSX, а во-вторых Вы всегда можете писать без JSX через React.DOM.div и т.п.
Что бы вы не говорили, но единственная задача view это отрисовка. Нельзя мешать представление с моделью.
Конечно, React вообще не должен ничего знать о данных, которые поступают в его компоненты! Поэтому и появился flux — чтобы решить проблему работы с данными и коммуникацией между компонентами. Довольно тяжело сейчас говорить о React без упоминания Flux.
Раньше как и вы мыслил. Пришло время адаптироваться. И я понял что так намного удобнее. Нет больше трёх разных сущностей как html css js. Есть одна — веб компонент. Для этого мы и держим все в одной папке, составляющие компонента. Держать разметку в js отличная идея, удобно. Как правило разметка не большая. Если у вас вёрстки в компоненте на целую страницу, значит что то пошло не так !)
Я не уверен, что в случае с React есть необходимость разделять код от от представления.
Но тут все зависит от индивидуальных предпочтений.
Если разработчик создает много компонентов и помещает все это в один файл, получается каша. Тогда есть смысл как-то навести порядок и разделить js от html
Но я сторонник модульного подхода к разработке. Один компонент — один маленький блок html + код реализации логики.
Но тут все зависит от индивидуальных предпочтений.
Если разработчик создает много компонентов и помещает все это в один файл, получается каша. Тогда есть смысл как-то навести порядок и разделить js от html
Но я сторонник модульного подхода к разработке. Один компонент — один маленький блок html + код реализации логики.
По большому счету можно вобще отказаться от html в компонентах и писать все на чистом React.
В таком случае ваши компоненты будут универсальными.
В таком случае ваши компоненты будут универсальными.
Я думаю, что разработчикам в будущем не помешает
1. Добавить поддержку темплейтов
2. Улучшить работу со свойствами (скажем придумать объект parent через который потомок может изменять состояние родителя)
1. Добавить поддержку темплейтов
2. Улучшить работу со свойствами (скажем придумать объект parent через который потомок может изменять состояние родителя)
1. О каких темплейтах Вы говорите?
2. Никакого two-way data-binding. Все свойства передаются от родителя к потомку и никак иначе. А вообще, для работы с данными в React существует множество библиотек (например, redux)
2. Никакого two-way data-binding. Все свойства передаются от родителя к потомку и никак иначе. А вообще, для работы с данными в React существует множество библиотек (например, redux)
По второму пункту, так на секундочку — https://www.npmjs.com/package/react-binding
«Так на секундочку» — 115 скачек за последний месяц + 14 звёзд на GH и 2 issue за 5 месяцев. Я бы не полагался на подобную библиотеку при проектировании приложения, особенно если она идёт вразрез оф. идеологии.
Видимо, я не совсем ясно выразился: разумеется, сделать можно всё что угодно — это js, в конце концов. Вы так же можете использовать родной хак: facebook.github.io/react/docs/two-way-binding-helpers.html, однако даже на этой странице написано, что React спроектирован как one-way data flow система.
Видимо, я не совсем ясно выразился: разумеется, сделать можно всё что угодно — это js, в конце концов. Вы так же можете использовать родной хак: facebook.github.io/react/docs/two-way-binding-helpers.html, однако даже на этой странице написано, что React спроектирован как one-way data flow система.
Шаблоны вполне можно делать в виде методов, получающих данные и возвращающих верстку, например.
Это называется «dumb components» и в React 0.14 реализуется с помощью обычных функций:
Взято из пресс-релиза 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
Dumb component, насколько я понимаю, это просто обертка в виде кастомного тега, содержащая верстку и не содержащая внутренней логики. Что-то типа:
<div>{this.props.children}</div>
Основная идея, «пропитывающая» реакт — композиция элементов. Т.е. «шаблон вывода» в Вашем понимании составляется из маленьких dumb components, которые при аггрегации образуют то, что Вам нужно.
Разумеется, где-то вверху будет находится smart component, который будет оркестрировать весь процесс: забирать данные из какого-нибудь хранилища (будь то что-то самописное, redux store или что либо ещё) и передавать эти данные в ваши dumb components и, возможно, содержать логику а-ля «если количество записей больше нуля, показывать dumb component со списком записей, в противном случае показывать заглушку с сообщением об отсутствии записей». По факту весь реакт — это один большой шаблон, если так посмотреть :)
Разумеется, где-то вверху будет находится smart component, который будет оркестрировать весь процесс: забирать данные из какого-нибудь хранилища (будь то что-то самописное, redux store или что либо ещё) и передавать эти данные в ваши dumb components и, возможно, содержать логику а-ля «если количество записей больше нуля, показывать dumb component со списком записей, в противном случае показывать заглушку с сообщением об отсутствии записей». По факту весь реакт — это один большой шаблон, если так посмотреть :)
Это такая «фишка» реакта, мне вначале казалось неудобным, но быстро привыкаешь и начинаешь даже любить эту схему. А вообще можно использовать jade шаблоны. Посмотрите на react-jade.
Выходит что код разделен на маленькие модули всегда, и очень часто нужно менять разметку вместе с JS, в данном случае проще ничего не забыть ибо все на виду
На мой взгляд, вычленять разметку из JSX не стоит. Почему?
1) Метод render у меня ещё ни разу не оказывался больше высоты экрана (обычно вообще строк 12-20).
2) В шаблоне логики вообще нет, никаких условных конструкций или циклов. Вся логика реализована выше в самом JS.
3) Желательно видеть, какие ноды какими ref я подписал, или какой метод вызвать при каком-то событии. Значит всё должно быть под рукой, а не переключаться между двумя файлами.
Причины за «выделение шаблона в отдельный файл» мне в голову не приходят. Станет хуже.
P.S.
По началу тоже думал, что html в JS — это какая-то дикость. Но изменил свою точку зрения. По поводу поддержки IDE — работал с jsx в Sublime без какой либо поддержки React, подсветки синтаксиса JS вполне хватало.
1) Метод render у меня ещё ни разу не оказывался больше высоты экрана (обычно вообще строк 12-20).
2) В шаблоне логики вообще нет, никаких условных конструкций или циклов. Вся логика реализована выше в самом JS.
3) Желательно видеть, какие ноды какими ref я подписал, или какой метод вызвать при каком-то событии. Значит всё должно быть под рукой, а не переключаться между двумя файлами.
Причины за «выделение шаблона в отдельный файл» мне в голову не приходят. Станет хуже.
P.S.
По началу тоже думал, что html в JS — это какая-то дикость. Но изменил свою точку зрения. По поводу поддержки IDE — работал с jsx в Sublime без какой либо поддержки React, подсветки синтаксиса JS вполне хватало.
Может быть человек давно начинал с PHP и с тех пор полюбил подход мешать код и разметку вместе. Фейсбук вот тоже с PHP дружит, вот и сделали в своем родном стиле.
Выносить можно, так как по сути в итоге там обычное JS-выражение. Т.е. его можно записывать в переменную, экспортировать из модуля и т.д. На практике, это обычно не нужно, так как если HTML-кода становится очень много, значит компонент плохой, а небольшое количество HTML-кода в методе render не мешает.
Так же в TypeScript запилили поддержку JSX (TSX) с проверкой типов, компиляцией и подсветкой. Пока сыровато, но обещает быть очень вкусно.
В целом, другого пути, кроме смешения JS и HTML, особо и нет, выдумывать тонны селекторов и писать отдельно обработчики событий больше нет желания, спрашивается, с чего начинали…
Так же в TypeScript запилили поддержку JSX (TSX) с проверкой типов, компиляцией и подсветкой. Пока сыровато, но обещает быть очень вкусно.
В целом, другого пути, кроме смешения JS и HTML, особо и нет, выдумывать тонны селекторов и писать отдельно обработчики событий больше нет желания, спрашивается, с чего начинали…
Во перых это не JS, а JSX
И по сути react это и есть умный темплейтовый движок, так что любые файлы с расширением .jsx в проекте написанном на реакте по своей сути являются темплейтами, а уже как фреймворк отвечающий за логику можно брать до пустим backbone.
И по сути react это и есть умный темплейтовый движок, так что любые файлы с расширением .jsx в проекте написанном на реакте по своей сути являются темплейтами, а уже как фреймворк отвечающий за логику можно брать до пустим backbone.
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 оставался максимально чистым.
JSX используется в качестве препроцессора для улучшения «читабельности» кода. «Под капотом» оно транслируется в ES5-совместимый формат, т.е.
будет транслирован в
Разумеется, вы можете использовать вторую версию без каких-либо препроцессоров. Об это подробнее на оф. сайте. Так же, в версии 0.14 работа с DOM вынесена в отдельную библиотеку
render() {
return <div>hello</div>;
}
будет транслирован в
render() {
return React.DOM.div(null, 'hello');
}
Разумеется, вы можете использовать вторую версию без каких-либо препроцессоров. Об это подробнее на оф. сайте. Так же, в версии 0.14 работа с DOM вынесена в отдельную библиотеку
react-dom.
Попробуйте RequireJS с плагином text.
По факту, это не то чтобы разметка. Это язык описания дерева UI, т.е. он включает в себя, помимо тегов, вызовы компонент. А в случае с каким-нибудь React Native, там вообще нет привычных тегов.
Не нужно выносить разметку. Она связана с логикой приложения, и это не coupling, это cohesion. Компонент — это логика и представление. Тут SRP не по принципу «ты определяешь представление (как будет выглядеть какой-то элемент)» и «ты определяешь логику (как взаимодействовать с конкретным элементом)», а по принципу «ты инкапсулированный компонент, в тебе представление и логика его отображения».
Тут правда есть нюанс с тем, как верстальщика с этим работать заставить. У нас процесс построен, что верстальщик концептуально верстает элементы управления, а мы уже из этой вёрстки создаём компоненты, так что у нас нет проблемы.
На эту тему есть совершенно прекрасный доклад Александра Соловьева Как писать UI без боли. Вообще у него совершенно потрясающие видео на YouTube, очень советую и другие посмотреть :)
Тут правда есть нюанс с тем, как верстальщика с этим работать заставить. У нас процесс построен, что верстальщик концептуально верстает элементы управления, а мы уже из этой вёрстки создаём компоненты, так что у нас нет проблемы.
На эту тему есть совершенно прекрасный доклад Александра Соловьева Как писать UI без боли. Вообще у него совершенно потрясающие видео на YouTube, очень советую и другие посмотреть :)
Если уж все равно приходится использовать browserify или webpack то можно было бы писать на es2015/es6, babel (babelify) отлично понимает jsx и в самой документации реакта есть примеры как можно использовать нативные классы в создании компонентов. Если интересно могу показать примеры gulpfile для сборки.
Это было бы здорово
Добавлю, что Babel не только понимает JSX, но и сама команда React'а даже отказалась от своих наработок и рекомендует использовать Babel для трансформации.
Или txs ;)
Как потомок может влиять на данные своего родителя? Очень просто:
и далее простыня кода без комментариев.
Вы бы хоть полужирным выделили изменения по отношению к предыдущей простыне.
Вот вам задачка: как организовать двунаправленный обмен данными между компонентами?
Может лучше сразу к Flux привыкать?
Вроде даже в Angular 2 от двунаправленного обменами данных решили отказаться?
И в Angular 2, и в Ember 2 тоже (и там, и там — плотно советуясь с командой React), и на Angular 1 тоже в итоге для больших приложений получается удобнее писать (субъективно), когда есть явная передача данных «туда» и «обратно».
Однако, часто бывает удобен и 2-way-binding, но надо понимать, когда его лучше использовать (в Aurelia он хорошо сделан и лишен недостатков оного в Angular 1) — тут создатели разных фреймворков вроде как сошлись во мнении, что правильный 2-way-binding — это сахар над one-way-binding для отдельных случаев (именно такой подход используется в ng2 с его жуткими "([...])" скобками в шаблонах и похожий в Aurelia с его «адаптивными байндингами»).
Однако, часто бывает удобен и 2-way-binding, но надо понимать, когда его лучше использовать (в Aurelia он хорошо сделан и лишен недостатков оного в Angular 1) — тут создатели разных фреймворков вроде как сошлись во мнении, что правильный 2-way-binding — это сахар над one-way-binding для отдельных случаев (именно такой подход используется в ng2 с его жуткими "([...])" скобками в шаблонах и похожий в Aurelia с его «адаптивными байндингами»).
Flux — я за!!!
Тут я с вами абсолютно не согласен. Для вас, как опытного программиста, статья действительно может показаться убожеством. Просто она предназначена не для вас. Я не преследовал цель создать первоклассный туториал, их и так как листьев на деревьях. А что делать человеку, который только, только делает первые шаги по пути фронт-енд разработки? Кто ему подскажет, кто направит?
Меня сильно раздражают напыщенные индюки вроде вас, которые только и умеют критиковать. Нет чтобы помочь, подсказать и сделать статью лучше. Ведь конечная цель — помощь людям!
Меня сильно раздражают напыщенные индюки вроде вас, которые только и умеют критиковать. Нет чтобы помочь, подсказать и сделать статью лучше. Ведь конечная цель — помощь людям!
Может кто-то посоветует приличные компаненты для работы с формами? Валидация, локализация, кастомизация и т.п.
А так же кучу-кучу всяких компонентов для этих форм.
Может кому-то удалось локализировать DatePicker из Material UI?
А так же кучу-кучу всяких компонентов для этих форм.
Может кому-то удалось локализировать DatePicker из Material UI?
Все что есть все тут github.com/enaqx/awesome-react
Обзор двух-летней давности )
На реакте сейчас пишут как-то вот так teropa.info/blog/2015/09/10/full-stack-redux-tutorial.html
На реакте сейчас пишут как-то вот так teropa.info/blog/2015/09/10/full-stack-redux-tutorial.html
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Изучение React — для чего, откуда, как?