Интеграция React on Rails

Я ищу, чтобы реализовать ReactJS как вид моего приложения Rails с камень реагирует-рельсы. До сих пор я использовал только стандартный .erb чтобы отобразить мои взгляды в моем приложении RoR, и мне интересно, как это сделать с React.

например, когда вы хотите создать форму для модели в RoR, вы" просто " создаете форму, используя:

<%= form_for(@product) do |f| %>
  <%= f.text_field :name %>
  ...
  <%= f.submit %>
<% end %>

и это автоматически использует правильный маршрут, генерирует токен CSRF, использует правильно CSS id & class, etc...

теперь, если я использую React, я должен позаботиться обо всем этом ? И создать форму в JSX в рендере, по старинке ?

# My view .html.erb
<%= react_component 'Form', {} %>

# My js.jsx file
var Form = React.createClass({
render: function () {
  return (
    <form className="new_my_model" onSubmit={this.handleSubmit}>
      <input style={inputStyle} type="text" className="my_model_name" />
      ...
      <input type="submit" value="Post" />
    </form>
  );
}
});

нет "автогенерирующей функции", такой как Ruby для React ?

Я нашел некоторые ресурсы в интернете о учебнике для React & Rails (1, 2, 3), но большую часть времени они говорят разные вещи. Некоторые используют JSX, некоторые кофе, пока the официальный сайт React рекомендует использовать JSX. Некоторые используют refs, другие -states и так со всем!

есть ли отличный учебник, который можно использовать в качестве ссылки для создания основы моего приложения с React ?

8
javascript react-rails reactjs ruby-on-rails

1 ответов

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

рискуя, что я не отвечаю на то, что ты хочешь узнать, вот несколько мыслей, которые могут помочь:

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

  • У вас есть, вероятно, три основных подхода:

    • minimal JS (используя RoR классическим способом, когда JS увеличивает представление,
    • перемещение основной части ваших представлений в ReactJS с минимальным видом RoR строительство, и
    • отдельные уровни обслуживания (используя RoR для предоставления API для использования AJAX с отдельной веб-службой, которая представляет написанный пользовательский интерфейс в ReactJS (и поэтому не интегрировать ReactJS непосредственно в Rails)

  • есть, несомненно, много вариаций на эти темы, но это, вероятно, основные из них.

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

Минимальный ReactJS

в классических представлениях Rails мы склонны использовать JS только для увеличения представления с поведением на стороне клиента: большая часть расчета представления выполняется на стороне сервера, а затем мы позволяем JS просто манипулировать различными аспектами DOM для некоторых целевых целей. Это может быть сложно реагировать, потому что React берет на себя ответственность за свои элементы DOM для обновления состояния. Но вы все равно можете использовать ReactJS для элементов вашей страницы, как и частичный просмотр в Rails, если этот "частичный" хорошо ограничен.

используя драгоценный камень React-Rails, просто позвольте вашему виду отобразить компонент React, как если бы вы собирались использовать частичный, а затем позволить этому компоненту обрабатывать его составные элементы напрямую, используя AJAX-вызовы, если вам нужно больше от сервера во время использование клиентом. Это создает ограниченное, сфокусированное разделение проблем в вашем представлении, и вы можете использовать обычные методы JS для сбора другой информации о page DOM, которая окружает ваш компонент (хотя это может стать сложным и хаотичным, если вы делаете что-то большее, чем очень ограниченные формы этого-вероятно, следует пересмотреть, если вы делаете многое из этого).

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

ReactJS просмотров из Rails

в этом подходе мы могли бы использовать Rails для рендеринга макетов представлений (т. е. HTML-оболочки, но без содержимого), а затем позволить конкретным представлениям быть только ReactJS или более обычными представлениями ERB/Haml/Slim. В этом подходе представление Rails просто установит основной компонент React для страницы, а затем сделает все остальное в ReactJS для управления этой частью (обычно всей панелью содержимого) в своем собственном JSX. Таким образом, ваш JSX по-прежнему обслуживается из вашего конвейера активов, но на самом деле вы рассматривали основную презентацию страницы из React и просто использовали Rails для самых минимальных целей макетов и позволяли некоторым представлениям быть ReactJS-based с другими как Rails-based.

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

тем не менее, есть некоторые преимущества:

  • опять же, вы можете смешивать и сопоставлять методы для разных страниц, чтобы постепенно вводить ReactJS в приложение; скажем, как способ конвертировать некоторые представления, пока все представления не будут основаны на реакции. Тогда проще перейти к подходу на уровне отдельного сервиса если хочешь.
  • вы все еще можете использовать представления для предоставления некоторой информации от контроллера компонентам ReactJS при первом отображении, потому что ваше представление все равно инициирует компонент React. Для любой дополнительной информации, как только React обрабатывает свои субкомпоненты, вам все равно нужно будет использовать AJAX (на самом деле не отличается от любой другой функциональности JS).
  • как вы указываете, Rails по-прежнему помогает вам с CSRF и этими приложениями беспокойства.

отдельные слои служба

этот подход полностью отделяет представления от серверной службы. Напишите приложение Rails, чтобы оно полностью отображало JSON на сервере API. Вся логика ядра все еще отрегулирована в регуляторах и моделях так, что часть дизайна в большинстве неповреждена. На самом деле, вам не нужны классические рельсы этого. Другие рамки, такие как Grape или rails-api gem, могут быть более подходящими, потому что они легче поскольку вы не будете делать никаких представлений или нуждаться в этих помощниках.

затем вы пишете отдельное приложение на основе ReactJS (помните, что ReactJS также может быть на стороне сервера), которое фокусируется только на презентации и просто использует вашу службу RoR API для получения и публикации информации.

соображения к этому подходу:

  • вы получаете очень четкое разделение проблем: ваше приложение Rails (или что-то еще) фокусируется на уровне данных / логики в качестве сервиса, а ваше приложение ReactJS фокусируется на демонстрация. Существует тенденция использовать Rails больше таким образом, и вы получаете другой способ горизонтального масштабирования приложения.
  • tooling гораздо легке в виду того что оба более однородны (автоматизированное испытание самостоятельно гораздо легке). Существует установленная экосистема вокруг RoR и одна вокруг приложений JS и ReactJS, но пересечение этих экосистем намного реже, поэтому вы оказываетесь в борьбе с инструментами больше в двух других методах. С отдельными слоями, это не вопрос.
  • хорошо работает для новых приложений, но, вероятно, гораздо сложнее преобразовать существующий (вам нужно одновременно конвертировать ваши контроллеры и ваши представления).

удачи!

обновление (9/2/2015) Вы можете найти это сообщение в блоге освещающим: http://www.openmindedinnovations.com/blogs/3-ways-to-integrate-ruby-on-rails-react-flux by Blaine Hatab (3/2015). Эта должность описывает три подхода, которые являются несколько подобно высокоуровневому наброску, который я предложил выше, но предназначены для более полной картины того, как действовать. Три подхода, которые они перечисляют, являются

  • метод 1: Используйте React внутри рельсов с react-rails
  • Метод 2: React / Flux front end app в Rails
  • Метод 3: разделенные Rails API и React / Flux front end app

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

24