* Изначально, React был нацелен на экспертов и ранних последователей
* Facebook открывает исходный код только тех продуктов, которые использует сам, т. е. не нацеленные на проекты-меньше-чем-Facebook
* Огромное количество гайдов по React совершенно разной сложности
Здесь и далее, я предполагаю, что вы уже знакомы с HTML, CSS и JavaScript.
Существует множество противоречивых советов по React. Зачем слушать меня?
Я работал в команде Facebook, которая разработала и опубликовала React. Теперь я работаю не в Facebook, а в небольшом стартапе, поэтому могу говорить с точки зрения своей текущей позиции, а не Facebook.
Все программное обеспечение строится на определенном стеке технологий, и вам нужно понимать этот стек, чтобы создать приложение. Основная причина того, почему экосистема React'а кажется непреодолимой, это потому что она постоянно объясняется в неправильном порядке.
Вы должны учиться в этом порядке, ничего не пропуская и не изучая две вещи параллельно:
* React
* npm
* JavaScript “bundlers” (сборщики)
* ES6
* Routing
* Flux
Вам не нужно это все, чтобы быть продуктивным с React. Приступайте к следующему шагу, если у вас есть проблема, которую он решает.
Также, в React-сообществе есть несколько тем, которые являются «супер-современными практиками» («bleeding edge»). Эти темы интересны, но разбираться в них сложно и они менее популярны, чем темы выше и не нужны для разработки большей части приложений.
* Инлайновые стили
* Рендер на стороне сервера
* Immutable.js
* Relay, Falcor, и т. д.
Существует заблуждение, что чтобы начать работу с React, нужен огромный инструментарий. Но это не так. В официальной документации вы найдете copy-paste HTML шаблон, который достаточно сохранить в .html файле и сразу же начать работать. Для этого шага не нужен никакой инструментарий, и не стоит приниматься за него, пока вы не будете чувствовать себя комфортно с основами React.
Я также считаю, что самый простой способ выучить React, это официальный туториал.
npm это менеджер пакетов Node.js и самый популярный способ для front-end разработчиков и дизайнеров делиться JavaScript кодом. Он включает модульную систему CommonJS и позволяет устанавливать инструменты командной строки, написанные JavaScript. Прочитайте эту статью, чтобы понять, почему и как используется CommonJS, или CommonJS Spec Wiki для большей информации о CommonJS API.
Большая часть компонентов, библиотек и инструментария в экосистеме React доступны как CommonJS модули и устанавливаются с помощью npm.
По определенному количеству технических причин, использование CommonJS модулей (то есть всего в npm) невозможно нативно в браузере. Вам понадобится JavaScript “bundler” для сборки этих модулей в .js файлы, которые затем можно будет включить в страницу тегом <script>.
Примерами JavaScript сборщиков являются webpack и browserify. Они оба являются хорошим выбором, но я предпочитаю webpack, так как он имеет определенный набор фич, упрощающих разработку крупных приложений. Так как документация может показаться запутанной, у меня есть шаблон для быстрого старта, и я написал how-to гайд по webpack для более сложных кейсов.
Стоит запомнить: CommonJS использует функцию require() для импорта модулей, из-за чего некоторые пользователи начинают думать, что это нечто связанное с библиотекой require.js. По определенному количеству технических причин, я советую избегать require.js. Этот выбор не популярен в среде React.
Кроме JSX (который вы изучили в туториале React), вы могли заметить несколько забавных синтаксических конструкций в примерах. Это называется ES6, самая последняя версия JavaScript, с которой вы еще можете быть не знакомы. Из-за новизны, ES6 еще не полностью доступен в браузерах, но ваш сборщик может транслировать его в поддерживаемый JavaScript после определенной настройки.
Вам не обязательно знать ES6 для разработки на React, вы можете выучить его попутно.
Вы также могли слышать разговоры о том, что ES6-классы являются предпочитаемым способом создания компонентов React. Это не так. Большинство людей (включая Facebook) используют React.createClass().
“Одностраничные приложения” (Single-page applications или SPA) — современная мода. Это веб-странички которые загружаются один раз, и, когда пользователь кликает по ссылке или кнопке, JavaScript, работающий на странице, обновляет адресную строку и контент, не перезагружая страницу целиком. Управление адресной строкой осуществляется router (роутером).
Самый популярный роутер в экосистеме React react-router. Если вы разрабатываете одностраничное приложение, используете его, если только у вас нет хорошей причины не делать этого.
Не используйте роутер, если вы не создаете single-page application. Большинство проектов все равно начинают с маленьких компонентов внутри имеющегося большого приложения.
Скорее всего, вы слышали о Flux. Про него имеется *тонна* дезинформации в сети.
Куча людей пытаются определиться с моделью данных и считают, что для этого им обязательно нужно использовать Flux. Это неправильный путь к внедрению Flux на свой проект. Flux должн быть добавлен только после того, как большинство компонентов уже будут созданы.
Компоненты React'а собраны в иерархию. В большинстве случаев, ваша модель данных также будет следовать этой иерархии. В этих ситуациях Flux не приносит особого выигрыша. Иногда, тем не менее, ваша модель данных не иерархична. Если ваши React компоненты получают props, которые кажутся «внешними», или у вас есть некоторое количество компонентов, которые начинают становиться сильно сложными, возможно вам стоит присмотреться к Flux.
Вы поймете, когда вам понадобится Flux. Если вы не уверены, что он вам нужен, то он вам не нужен.
Если вы решили использовать Flux, самой популярной и документированной Flux-библиотекой является Redux. Также есть *множество* альтернатив, возможно вы соблазнитесь попробовать их, но мой совет — использовать самую популярную.
Пре-React, большинство людей использовали CSS-препроцессоры типа SASS для переиспользования стилей. React делает написание переиспользуемых компонентов простым, также упрощая и написание стилей. Многие из сообщества (включая меня) экспериментируют над тем, чтобы совсем избавиться от CSS.
В силу ряда причин, это относительно безумная идея. Она усложняет написание media queries, и, возможно, есть определенные ограничния по производительности. Если вы только что начали работать с React, пишите css-стили так как вы привыкли.
Как только вы почувствуете то, как React работает, обратите внимание на альтернативные техники. Одна из популярных, это BEM. Я бы порекомендовал избавляться от CSS-препроцессора, так как React предоставляет более гибкий путь переиспользования стилей (через переиспользование компонентов) и ваш JavaScript-сборщик может генерировать гораздо более эффективные таблицы стилей для вас (доклад на эту тему на OSCON). Вместе с тем, React, как и любая другая JavaScript библиотека, сможет работать также хорошо с любым CSS-препроцессором.
Серверный рендеринг часто называется «универсальным» или «изоморфным» JS. Это означает что вы можете взять ваши React-компоненты и отрендерить их в статический HTML на сервере. Это ускоряет первоначальную загрузку страницы, так как пользователю не нужно ждать, пока скачается весь JS, чтобы увидеть UI, а React, в свою очередь, может переиспользовать HTML, сгенерированный на сервере, не рендеря ничего на клиенте повторно.
Серверный рендеринг вам понадобится, если вы посчитаете, что первичный рендер страницы слишком медленный, или чтобы улучшить ранжирование в поисковиках. Да, Google индексирует контент, рендеренный на клиенте, но по состоянию на январь 2016 каждое измерение показывало, что это негативно влияет на ранжирование, потенциально из-за производительности рендера.
Также серверный рендеринг требует большого количества инструментария для «правильной» реализации. Так как поддержка React-компонентов написанных без мысли о серверном рендеринге, в целом прозрачна, рекомендуется сначала писать приложение, а потом задумываться о нем. Вам не прийдется переписывать все ваши компоненты в случае решения о переходе.
Immutable.js предоставляет набор структур данных, которые помогают решать определенные проблемы с производительностью в React-приложениях. Это отличная библиотека, и, скорее всего, вы будете часто использовать ее с ростом вашего приложения, но она абсолютно не является требованием, пока вы не столкнетесь с проблемами производительности.
Эти технологию помогают уменьшить количество AJAX-запросов. Они все еще являются относительно экспериментальными, так что если у вас нет проблем со слишком большим количеством AJAX запросов, вам не нужны Relay или Falcor.
UPD. Немного почищен перевод первых абзацев, спасибо Benjamin Tambourine за правки
UPD2. Много мелких грамматических исправлений, спасибо wiygn
This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Комментариев нет:
Отправить комментарий