feed.xml

<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title>Blog Name</title>
  <subtitle>Blog subtitle</subtitle>
  <id>http://blog.url.com/</id>
  <link href="http://blog.url.com/"/>
  <link href="http://blog.url.com/feed.xml" rel="self"/>
  <updated>2017-02-28T00:00:00+00:00</updated>
  <author>
    <name>Blog Author</name>
  </author>
  <entry>
    <title>Spring 2017 COMPS Release</title>
    <link rel="alternate" href="http://blog.url.com/blog/2017/02/28/spring-2017-comps-release/"/>
    <id>http://blog.url.com/blog/2017/02/28/spring-2017-comps-release/</id>
    <published>2017-02-28T00:00:00+00:00</published>
    <updated>2017-04-13T10:46:52+01:00</updated>
    <author>
      <name>Article Author</name>
    </author>
    <content type="html">&lt;p&gt;Spring 2017 heralds a major Hyperloop release. This release will be the first where we have introduced the 5 architectural constructs focused on making it easier to write Isomorphic applications.&lt;/p&gt;

&lt;p&gt;This release includes a new version and renaming of all of the Hyperloop gems as well as several new concepts and gems.&lt;/p&gt;

&lt;p&gt;These release notes cover the following topics:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;&lt;a href="#release-overview"&gt;Release Overview&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="#gem-changes"&gt;Gem changes&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="#new-folder-layout"&gt;New folder layout&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="#base-class-names"&gt;Base class names&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;

&lt;h2 id="release-overview"&gt;Release Overview&lt;/h2&gt;

&lt;p&gt;This release consists of:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Introduction of COMPS (Components, Operations, Models, Policies and Stores) architectural concepts&lt;/li&gt;
&lt;li&gt;Introduction of Hyper-Operation gem&lt;/li&gt;
&lt;li&gt;Introduction of Hyper-Store gem&lt;/li&gt;
&lt;li&gt;Introduction of Hyper-Spec gem&lt;/li&gt;
&lt;li&gt;Introduction of a centralized Hyperloop configuration gem&lt;/li&gt;
&lt;li&gt;Renaming of HyperMesh gem to Hyper-Model&lt;/li&gt;
&lt;li&gt;Renaming of Express gem to Hyperloop-JS&lt;/li&gt;
&lt;li&gt;Changes to state syntax from bang(!) notation to mutate method&lt;/li&gt;
&lt;li&gt;Changes to all base class names (Hyperloop::Component, Hyperloop::Model, etc) for consistency&lt;/li&gt;
&lt;li&gt;Changes to the location of files in a Rails project&lt;/li&gt;
&lt;li&gt;New Hyperloop JS based on latest gems&lt;/li&gt;
&lt;li&gt;New HyperRails gem&lt;/li&gt;
&lt;li&gt;New website documentation, lived-code editing, new styling and new branding&lt;/li&gt;
&lt;/ul&gt;

&lt;h2 id="gem-changes"&gt;Gem changes&lt;/h2&gt;

&lt;h4 id="version-numbers-and-content"&gt;Version Numbers and Content&lt;/h4&gt;

&lt;table&gt;&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;gem&lt;/th&gt;
&lt;th&gt;version&lt;/th&gt;
&lt;th&gt;notes&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;hyper-loop&lt;/td&gt;
&lt;td&gt;0.8&lt;/td&gt;
&lt;td&gt;initial release&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;hyper-store&lt;/td&gt;
&lt;td&gt;0.2.2&lt;/td&gt;
&lt;td&gt;initial release&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;hyper-operation&lt;/td&gt;
&lt;td&gt;0.5.4&lt;/td&gt;
&lt;td&gt;initial release&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;hyper-component&lt;/td&gt;
&lt;td&gt;0.12.5&lt;/td&gt;
&lt;td&gt;latest hyper-react + pending fixes + compatibility &lt;code&gt;requires&lt;/code&gt; (see below)&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;hyper-model&lt;/td&gt;
&lt;td&gt;0.6.0&lt;/td&gt;
&lt;td&gt;hyper-mesh 0.5.x + fixes + dependence on hyper-store and hyper-operation gems&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;hyperloop-js&lt;/td&gt;
&lt;td&gt;0.1&lt;/td&gt;
&lt;td&gt;latest gems + decoupling of Hyperloop and Opal&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;&lt;/table&gt;

&lt;h4 id="hyper-component-compatibility"&gt;Hyper-Component compatibility&lt;/h4&gt;

&lt;p&gt;The hyper-component gem will include 3 compatibility modes, determined by which file you require in &lt;code&gt;components.rb.&lt;/code&gt;&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;Hyperloop Standard&lt;/strong&gt;: (&lt;code&gt;require &amp;#39;hyper-component&amp;#39;&lt;/code&gt;) In this mode you will use the new hyperloop syntax for all names, macros etc.  I.e. components are defined as subclasses of &lt;code&gt;Hyperloop::Component&lt;/code&gt; or using &lt;code&gt;Hyperloop::Component::Mixin&lt;/code&gt;.   States are changed using the &lt;code&gt;mutate&lt;/code&gt; objectrather than the exclamation notation.  States are declared using the &lt;code&gt;state&lt;/code&gt; macro.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;HyperReact Compatibility&lt;/strong&gt;: (&lt;code&gt;require &amp;#39;hyper-react&amp;#39;&lt;/code&gt;) In this mode you can use either syntax, but you will get deprecation warnings, as this mode &lt;em&gt;will&lt;/em&gt; go away.  This mode will be provided as a bridge so developers can use Operations and Stores without having to make changes to existing components.&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;DSL Only&lt;/strong&gt; (&lt;code&gt;require &amp;#39;hyper-react-dsl&amp;#39;&lt;/code&gt;)  In this mode you will use the new syntax, however, the DSL will be limited to the base feature set provided by react.js.  This mainly applies to states acting as stores.  The advantage will be smaller payload size.  Initially, this mode not exist but the code will be set up to support it easily in the future&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;In addition, we will make one more release to the hyper-react and hyper-mesh gems that simply provides the hyper-component and hyper-model functionality, plus a deprecation warning.  The intent is that the next time you update these gems, you will get the warning, and will know to change to the new gem names.&lt;/p&gt;

&lt;h4 id="store-and-operation-interoperability"&gt;Store and Operation interoperability&lt;/h4&gt;

&lt;p&gt;Stores depend on &lt;code&gt;Hyperloop::Application::Boot&lt;/code&gt;, which is an operation defined in the Operation gem.  So that you can use stores without operations, the store gem will define a very basic boot operation &lt;em&gt;unless&lt;/em&gt; Hyperloop::Application::Boot is already defined.&lt;/p&gt;

&lt;h4 id="hyperloop-js"&gt;Hyperloop.JS&lt;/h4&gt;

&lt;p&gt;Hyperloop.JS now supports Compoennts, Operations and Stores.&lt;/p&gt;

&lt;p&gt;There is no gem here, just JavaScript files.  We will have two: hyperloop.js which includes Components, Operations and Stores and opal-compiler.js which includes Opal and Opal Compiler.&lt;/p&gt;

&lt;h2 id="new-folder-layout"&gt;New folder layout&lt;/h2&gt;

&lt;p&gt;There is a folder layout within a Rails project.&lt;/p&gt;

&lt;p&gt;Old folder layout:&lt;/p&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;/app/views/components          &amp;lt;-- HyperReact components
/app/models/public             &amp;lt;-- HyperMesh models
/app/models                    &amp;lt;-- server-only models
/app/views/components.rb       &amp;lt;-- component manifest
/app/policies                  &amp;lt;-- HyperMesh policies
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;New folder layout:&lt;/p&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;/app/hyperloop/components      &amp;lt;-- components
/app/hyperloop/models          &amp;lt;-- isomorphic models
/app/models                    &amp;lt;-- server-only models
/app/hyperloop/operations      &amp;lt;-- isomorphic operations
/app/operations                &amp;lt;-- server-only operations
/app/hyperloop/stores          &amp;lt;-- stores
/app/hyperloop/hyperloop.rb    &amp;lt;-- hyperloop manifest
/app/policies                  &amp;lt;-- policies
&lt;/code&gt;&lt;/pre&gt;
&lt;h2 id="base-classes-and-mixins"&gt;Base classes and Mixins&lt;/h2&gt;

&lt;p&gt;Hyperloop base classes follow a consistent naming convention:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;&lt;code&gt;Hyperloop::Operation&lt;/code&gt;&lt;/li&gt;
&lt;li&gt;&lt;code&gt;Hyperloop::Store&lt;/code&gt;&lt;/li&gt;
&lt;li&gt;&lt;code&gt;Hyperloop::Policy&lt;/code&gt;&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;You can inherit from the class:&lt;/p&gt;
&lt;pre class="highlight ruby"&gt;&lt;code&gt;&lt;span class="k"&gt;class&lt;/span&gt; &lt;span class="nc"&gt;Cart&lt;/span&gt; &lt;span class="o"&gt;&amp;lt;&lt;/span&gt; &lt;span class="no"&gt;Hyperloop&lt;/span&gt;&lt;span class="o"&gt;::&lt;/span&gt;&lt;span class="no"&gt;Store&lt;/span&gt;
  &lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nf"&gt;.&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;
&lt;span class="nf"&gt;end&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Or mixin the module:&lt;/p&gt;
&lt;pre class="highlight ruby"&gt;&lt;code&gt;&lt;span class="k"&gt;class&lt;/span&gt; &lt;span class="nc"&gt;Cart&lt;/span&gt;
  &lt;span class="kp"&gt;include&lt;/span&gt; &lt;span class="no"&gt;Hyperloop&lt;/span&gt;&lt;span class="o"&gt;::&lt;/span&gt;&lt;span class="no"&gt;Store&lt;/span&gt;&lt;span class="o"&gt;::&lt;/span&gt;&lt;span class="no"&gt;Mixin&lt;/span&gt;
  &lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nf"&gt;.&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;
&lt;span class="nf"&gt;end&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Mixins available:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;&lt;code&gt;Hyperloop::Store::Mixin&lt;/code&gt;&lt;/li&gt;
&lt;li&gt;&lt;code&gt;Hyperloop::Policy::Mixin&lt;/code&gt;&lt;/li&gt;
&lt;/ul&gt;
</content>
  </entry>
  <entry>
    <title>Editing Flux Loop verses Decoupling</title>
    <link rel="alternate" href="http://blog.url.com/blog/2017/01/28/editing-flux-loop-verses-decoupling/"/>
    <id>http://blog.url.com/blog/2017/01/28/editing-flux-loop-verses-decoupling/</id>
    <published>2017-01-28T00:00:00+00:00</published>
    <updated>2017-04-11T18:41:54+01:00</updated>
    <author>
      <name>Article Author</name>
    </author>
    <content type="html">&lt;p&gt;@catmando&lt;/p&gt;

&lt;p&gt;This started as some thoughts about when to use notation like&lt;/p&gt;
&lt;pre class="highlight ruby"&gt;&lt;code&gt;&lt;span class="no"&gt;AddItemToCart&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="ss"&gt;item: &lt;/span&gt;&lt;span class="n"&gt;sku&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="ss"&gt;qty: &lt;/span&gt;&lt;span class="mi"&gt;1&lt;/span&gt;&lt;span class="p"&gt;)&lt;/span&gt; &lt;span class="c1"&gt;# Use an operation&lt;/span&gt;
&lt;span class="c1"&gt;# vs&lt;/span&gt;
&lt;span class="no"&gt;Cart&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nf"&gt;addItem&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="ss"&gt;item: &lt;/span&gt;&lt;span class="n"&gt;sku&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="ss"&gt;qty: &lt;/span&gt;&lt;span class="mi"&gt;1&lt;/span&gt;&lt;span class="p"&gt;)&lt;/span&gt; &lt;span class="c1"&gt;# Use a method on the Store&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Which in thinking it through (the answer is &amp;#39;always use the Operation&amp;#39;, read on for details) led me to understand what I think is the real truth about the &amp;quot;flux loop.&amp;quot;  And the answer to that is, it is nothing really to do with the &amp;quot;data flow&amp;quot; but with the coupling between parts of the system.&lt;/p&gt;

&lt;p&gt;Actions (and Operations, Mutations, and to some extent decorators - maybe) provide a way to decouple elements of the system.&lt;/p&gt;

&lt;p&gt;In the above example, why is the Operation better?  Sometime in the future, you may want to note that the current user showed interest in an SKU whenever that SKU gets added to the cart.  Where does this additional code go?  If you have gone down the path of directly calling &lt;code&gt;Cart.addItem&lt;/code&gt; you have no place to logically add this code.  You can add it the Cart, but this now couples the Cart to some other model like UserInterests.  The two are pretty unrelated.  So you would end up moving the logic upwards and that puts it where it belonged in the first place: the AddItemToCart Operation.&lt;/p&gt;

&lt;p&gt;Having Operations (which are basically the same as Actions + Action Creators + the Dispatcher) and using them &lt;em&gt;whenever data is mutated&lt;/em&gt;  is a really good rule of thumb which is simple to understand, helps structure the code in a way that leaves it more maintainable, less brittle, and more reusable.&lt;/p&gt;

&lt;p&gt;It also creates a &amp;quot;one-way data flow&amp;quot; but the problem is that I can create a system with one-way data flow that does not provide me with good decoupling between parts of the system.  I can also in perfectly good flux architecture still make dumb design decisions.&lt;/p&gt;

&lt;p&gt;Here are three good things that having a central point like the Dispatcher or Operations solves:&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;&lt;strong&gt;Decoupling Interface from Implementation&lt;/strong&gt;
The flux Action paradigm decouples the Action protocol from the implementation completely.  An Action is a separate object from the Store receiving the action.  Some event handler calls the action, and the Store registers with the action.  In fact, you can have multiple Stores respond to the same Action.  Cool!&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;But even without a Dispatcher you get all the biggest benefit which is the decoupling.  So I think its important to understand the first goal is to give a separate name to the Action (or Operation) and which can then be associated whatever Stores need to be updated.&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;Debuggability&lt;/strong&gt;*
Running everything through the Action-Dispatcher (or an Operation base class) means that you can easily trace all actions/operations.  If you are using immutable data you can have even more fun.  This is good!&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;Keeping Store Concerns Clean&lt;/strong&gt;
Without some entity such as Actions to decouple Stores from &lt;em&gt;each other&lt;/em&gt; you end up with Store A, knowing too much about Store B. So to emphasize the earlier example: we have a cart, we want to add an item.  Great.  But now you also want to update a &amp;quot;User Interest List&amp;quot; with any item a user has added to a cart.  So the naive implementation would probably have the Cart &amp;quot;add item&amp;quot; mechanism call some method on the UserInterestList Store.  Now the Cart which seems like the more &amp;quot;fundamental&amp;quot; class, is linked to the UserInterestList, and the spagetti begins to tangle.  &lt;/p&gt;&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;This is a huge problem everywhere.  The &amp;quot;Action&amp;quot; solution is a simplified version of the TrailBlazer Operation, which itself is derived from the Mutation gem.  So the problem has been around for a while, and the solutions that work are similiar.&lt;/p&gt;

&lt;p&gt;And here is and example of something Actions or Operations and having a central dispatcher does not solve:&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;Bad class protocol design&lt;/strong&gt;&lt;br&gt;
We can describe how to &amp;quot;kill&amp;quot; a role playing character many ways.   &lt;/p&gt;
&lt;pre class="highlight ruby"&gt;&lt;code&gt;&lt;span class="no"&gt;Person&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nf"&gt;set_is_alive&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="nb"&gt;id&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="n"&gt;boolean&lt;/span&gt;&lt;span class="p"&gt;)&lt;/span&gt; &lt;span class="c1"&gt;# normal method call&lt;/span&gt;
&lt;span class="p"&gt;{&lt;/span&gt;&lt;span class="ss"&gt;type: :set_is_alive&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="ss"&gt;payload: &lt;/span&gt;&lt;span class="p"&gt;{&lt;/span&gt;&lt;span class="ss"&gt;id: &lt;/span&gt;&lt;span class="nb"&gt;id&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="ss"&gt;boolean: &lt;/span&gt;&lt;span class="n"&gt;boolean&lt;/span&gt;&lt;span class="p"&gt;}}&lt;/span&gt; &lt;span class="c1"&gt;# flux action&lt;/span&gt;
&lt;span class="no"&gt;SetIsAlive&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="nb"&gt;id&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="n"&gt;boolean&lt;/span&gt;&lt;span class="p"&gt;)&lt;/span&gt; &lt;span class="c1"&gt;# Operation / Action Creator&lt;/span&gt;
&lt;span class="c1"&gt;# BAD! what if u change "alive-ness" to be a scale instead of yes/no?&lt;/span&gt;
&lt;span class="no"&gt;Person&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nf"&gt;set_life_level&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="nb"&gt;id&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="n"&gt;integer&lt;/span&gt;&lt;span class="p"&gt;)&lt;/span&gt; &lt;span class="c1"&gt;# normal method call&lt;/span&gt;
&lt;span class="p"&gt;{&lt;/span&gt;&lt;span class="ss"&gt;type: :set_life_level&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="ss"&gt;payload: &lt;/span&gt;&lt;span class="p"&gt;{&lt;/span&gt;&lt;span class="ss"&gt;id: &lt;/span&gt;&lt;span class="nb"&gt;id&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="ss"&gt;level: &lt;/span&gt;&lt;span class="n"&gt;level&lt;/span&gt;&lt;span class="p"&gt;}}&lt;/span&gt; &lt;span class="c1"&gt;# flux action&lt;/span&gt;
&lt;span class="no"&gt;SetLifeLevel&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="nb"&gt;id&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="n"&gt;level&lt;/span&gt;&lt;span class="p"&gt;)&lt;/span&gt; &lt;span class="c1"&gt;# Operation / Action Creator&lt;/span&gt;
&lt;span class="c1"&gt;# STILL BAD! Its less brittle but it still reveals too much implemenation&lt;/span&gt;
&lt;span class="no"&gt;Person&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nf"&gt;kill&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="nb"&gt;id&lt;/span&gt;&lt;span class="p"&gt;)&lt;/span&gt;
&lt;span class="p"&gt;{&lt;/span&gt;&lt;span class="ss"&gt;type: :kill&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="ss"&gt;data: &lt;/span&gt;&lt;span class="p"&gt;{&lt;/span&gt;&lt;span class="ss"&gt;id: &lt;/span&gt;&lt;span class="nb"&gt;id&lt;/span&gt;&lt;span class="p"&gt;}}&lt;/span&gt;
&lt;span class="no"&gt;Kill&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="nb"&gt;id&lt;/span&gt;&lt;span class="p"&gt;)&lt;/span&gt; &lt;span class="c1"&gt;# Operation / Action Creator&lt;/span&gt;
&lt;span class="c1"&gt;# This is a much better protocol!!!&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Regardless of whether I think of my system in terms of Classes and methods, actions, or operations, I can build good protocols or bad protocols.  Just declaring that I use &amp;quot;actions&amp;quot; to define my system does not solve this problem.  People must realize that &amp;quot;Actions&amp;quot; are just another way to describe messages to move data between elements of the system.  Just changing terminology from methods, classes or procedure calls to &amp;#39;Actions&amp;#39; and &amp;#39;Stores&amp;#39; solves nothing.&lt;/p&gt;

&lt;p&gt;So there are three good reasons to use an architecture that centralizes the mutation of stores to a single point (or a single class) plus one thing such an architecture does not solve.  &lt;strong&gt;But note:  No place in that discussion did we say anything about one-way data flow.&lt;/strong&gt;  That is a side effect and frankly a distraction I think.  There are going to be times where its best to violate the &amp;quot;one-way data flow&amp;quot; but that does not mean you have to in any way give up good design principles.&lt;/p&gt;

&lt;p&gt;I think its much easier and clearer to think in terms of who mutates the stores.  Providing an answer like &amp;quot;in general it should be the Operations&amp;quot;, is a good starting point to discovering the best way to decouple the system.  I don&amp;#39;t think saying &amp;quot;make the data flow one way&amp;quot; is as helpful.&lt;/p&gt;

&lt;h4 id="how-is-this-going-to-work-in-hyperloop"&gt;How is this going to work in Hyperloop&lt;/h4&gt;

&lt;p&gt;Here is the basic approach:&lt;/p&gt;
&lt;pre class="highlight ruby"&gt;&lt;code&gt;&lt;span class="k"&gt;class&lt;/span&gt; &lt;span class="nc"&gt;AddItemToCart&lt;/span&gt; &lt;span class="o"&gt;&amp;lt;&lt;/span&gt; &lt;span class="no"&gt;HyperOperation&lt;/span&gt;
  &lt;span class="n"&gt;param&lt;/span&gt; &lt;span class="ss"&gt;:sku&lt;/span&gt;
  &lt;span class="n"&gt;param&lt;/span&gt; &lt;span class="ss"&gt;qty: &lt;/span&gt;&lt;span class="mi"&gt;1&lt;/span&gt;
&lt;span class="k"&gt;end&lt;/span&gt;

&lt;span class="k"&gt;class&lt;/span&gt; &lt;span class="nc"&gt;Cart&lt;/span&gt; &lt;span class="o"&gt;&amp;lt;&lt;/span&gt; &lt;span class="no"&gt;HyperStore&lt;/span&gt;
  &lt;span class="n"&gt;state_reader&lt;/span&gt; &lt;span class="ss"&gt;items: &lt;/span&gt;&lt;span class="no"&gt;Hash&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nf"&gt;new&lt;/span&gt; &lt;span class="p"&gt;{&lt;/span&gt; &lt;span class="o"&gt;|&lt;/span&gt;&lt;span class="n"&gt;h&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="n"&gt;k&lt;/span&gt;&lt;span class="o"&gt;|&lt;/span&gt; &lt;span class="n"&gt;h&lt;/span&gt;&lt;span class="p"&gt;[&lt;/span&gt;&lt;span class="n"&gt;k&lt;/span&gt;&lt;span class="p"&gt;]&lt;/span&gt; &lt;span class="o"&gt;=&lt;/span&gt; &lt;span class="mi"&gt;0&lt;/span&gt; &lt;span class="p"&gt;},&lt;/span&gt; &lt;span class="ss"&gt;scope: :class&lt;/span&gt;

  &lt;span class="n"&gt;receives&lt;/span&gt; &lt;span class="no"&gt;AddItemToCart&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="ss"&gt;scope: :class&lt;/span&gt; &lt;span class="k"&gt;do&lt;/span&gt;
    &lt;span class="n"&gt;state&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nf"&gt;items!&lt;/span&gt;&lt;span class="p"&gt;[&lt;/span&gt;&lt;span class="n"&gt;params&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nf"&gt;sku&lt;/span&gt;&lt;span class="p"&gt;]&lt;/span&gt; &lt;span class="o"&gt;+=&lt;/span&gt; &lt;span class="n"&gt;params&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nf"&gt;qty&lt;/span&gt;
  &lt;span class="k"&gt;end&lt;/span&gt;
&lt;span class="k"&gt;end&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;(+) Nice and easy&lt;br&gt;
  (-) Adds (maybe) 2 lines to every mutator (&lt;code&gt;class ... end&lt;/code&gt;)&lt;br&gt;
  (+) Allows for other stores to participate in the Operation&lt;br&gt;
  (+) Clearly corresponds to the Flux model (i.e. Operation == Action + Action Creator + Dispatcher)  &lt;/p&gt;

&lt;h3 id="improving-on-the-above"&gt;Improving on the above&lt;/h3&gt;

&lt;p&gt;In many cases there is a &amp;quot;default&amp;quot; association between the Operation and the Store.  You can see this in the names &lt;code&gt;Cart&lt;/code&gt; and &lt;code&gt;AddItemToCart&lt;/code&gt;. This is very common in real world examples.  Given this it makes sense to namespace the actions with the store:&lt;/p&gt;
&lt;pre class="highlight ruby"&gt;&lt;code&gt;&lt;span class="k"&gt;class&lt;/span&gt; &lt;span class="nc"&gt;Cart&lt;/span&gt; &lt;span class="o"&gt;&amp;lt;&lt;/span&gt; &lt;span class="no"&gt;HyperStore&lt;/span&gt;
  &lt;span class="k"&gt;class&lt;/span&gt; &lt;span class="nc"&gt;AddItem&lt;/span&gt; &lt;span class="o"&gt;&amp;lt;&lt;/span&gt; &lt;span class="no"&gt;HyperOperation&lt;/span&gt;
    &lt;span class="n"&gt;param&lt;/span&gt; &lt;span class="ss"&gt;:sku&lt;/span&gt;
    &lt;span class="n"&gt;param&lt;/span&gt; &lt;span class="ss"&gt;qty: &lt;/span&gt;&lt;span class="mi"&gt;1&lt;/span&gt;
  &lt;span class="k"&gt;end&lt;/span&gt;
  &lt;span class="n"&gt;state_reader&lt;/span&gt; &lt;span class="ss"&gt;items: &lt;/span&gt;&lt;span class="no"&gt;Hash&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nf"&gt;new&lt;/span&gt; &lt;span class="p"&gt;{&lt;/span&gt; &lt;span class="o"&gt;|&lt;/span&gt;&lt;span class="n"&gt;h&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="n"&gt;k&lt;/span&gt;&lt;span class="o"&gt;|&lt;/span&gt; &lt;span class="n"&gt;h&lt;/span&gt;&lt;span class="p"&gt;[&lt;/span&gt;&lt;span class="n"&gt;k&lt;/span&gt;&lt;span class="p"&gt;]&lt;/span&gt; &lt;span class="o"&gt;=&lt;/span&gt; &lt;span class="mi"&gt;0&lt;/span&gt; &lt;span class="p"&gt;},&lt;/span&gt; &lt;span class="ss"&gt;scope: :class&lt;/span&gt;
  &lt;span class="n"&gt;receives&lt;/span&gt; &lt;span class="no"&gt;AddItem&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="ss"&gt;scope: :class&lt;/span&gt; &lt;span class="k"&gt;do&lt;/span&gt;
    &lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nf"&gt;.&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;
  &lt;span class="nf"&gt;end&lt;/span&gt;

&lt;span class="k"&gt;end&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;We have not changed much, but things look much logical.  You would say:&lt;/p&gt;
&lt;pre class="highlight ruby"&gt;&lt;code&gt;  &lt;span class="no"&gt;Cart&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nf"&gt;items&lt;/span&gt; &lt;span class="c1"&gt;# works just like a scope&lt;/span&gt;
  &lt;span class="no"&gt;Cart&lt;/span&gt;&lt;span class="o"&gt;::&lt;/span&gt;&lt;span class="no"&gt;AddItem&lt;/span&gt;&lt;span class="p"&gt;(.&lt;/span&gt;&lt;span class="nf"&gt;.&lt;/span&gt;&lt;span class="o"&gt;.&lt;/span&gt;&lt;span class="p"&gt;)&lt;/span&gt;  &lt;span class="c1"&gt;# stands out!!! must be a mutator&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;You can still have other unrelated Stores receive AddItem:&lt;/p&gt;
&lt;pre class="highlight ruby"&gt;&lt;code&gt;&lt;span class="k"&gt;class&lt;/span&gt; &lt;span class="nc"&gt;UserInterestList&lt;/span&gt; &lt;span class="o"&gt;&amp;lt;&lt;/span&gt; &lt;span class="no"&gt;HyperStore&lt;/span&gt;
  &lt;span class="n"&gt;receives&lt;/span&gt; &lt;span class="no"&gt;Cart&lt;/span&gt;&lt;span class="o"&gt;::&lt;/span&gt;&lt;span class="no"&gt;AddItem&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="ss"&gt;scope: :class&lt;/span&gt; &lt;span class="k"&gt;do&lt;/span&gt;
    &lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nf"&gt;.&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;
  &lt;span class="nf"&gt;end&lt;/span&gt;
&lt;span class="k"&gt;end&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;And because we know that Cart is by default related to AddItem, we can make sure that Cart always receives AddItem first, thus doing away with a common reason for needing to explicitly specify the order that Stores should receive an action.&lt;/p&gt;

&lt;p&gt;If it&amp;#39;s not obvious which class the Operation belongs (you can probably see it right in the name) to then it really is its own thing and should be placed in its own namespace.  So for example:
&lt;code&gt;ruby
class ResetToDefaults &amp;lt; HyperOperation
end
&lt;/code&gt;
Clearly there is no associated Store, so ResetToDefaults stands alone.&lt;/p&gt;

&lt;p&gt;While it&amp;#39;s a little more typing (2 lines) you now can give a robust specification to the parameters coming into the Operation.  This seems important if the rule of thumb is that Operations are controlling mutations of our Stores&lt;/p&gt;
&lt;pre class="highlight ruby"&gt;&lt;code&gt;&lt;span class="k"&gt;class&lt;/span&gt; &lt;span class="nc"&gt;Cart&lt;/span&gt; &lt;span class="o"&gt;&amp;lt;&lt;/span&gt; &lt;span class="no"&gt;HyperStore&lt;/span&gt;  
  &lt;span class="k"&gt;class&lt;/span&gt; &lt;span class="nc"&gt;AddItem&lt;/span&gt; &lt;span class="o"&gt;&amp;lt;&lt;/span&gt; &lt;span class="no"&gt;HyperOperation&lt;/span&gt;
    &lt;span class="n"&gt;param&lt;/span&gt; &lt;span class="ss"&gt;:sku&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="ss"&gt;type: &lt;/span&gt;&lt;span class="no"&gt;String&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="ss"&gt;matches: &lt;/span&gt;&lt;span class="no"&gt;SKU_PATTERN&lt;/span&gt;    
    &lt;span class="n"&gt;param&lt;/span&gt; &lt;span class="ss"&gt;qty: &lt;/span&gt;&lt;span class="mi"&gt;1&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="ss"&gt;type: &lt;/span&gt;&lt;span class="no"&gt;Numeric&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="ss"&gt;minimum: &lt;/span&gt;&lt;span class="mi"&gt;1&lt;/span&gt;
  &lt;span class="k"&gt;end&lt;/span&gt;   
  &lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nf"&gt;.&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;
&lt;span class="nf"&gt;end&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Finally note that nesting the declaration of the Operation inside a Store, does not prevent you from adding special logic not related to the Store elsewhere:&lt;/p&gt;
&lt;pre class="highlight ruby"&gt;&lt;code&gt;&lt;span class="c1"&gt;# some where else in the code:&lt;/span&gt;
&lt;span class="k"&gt;class&lt;/span&gt; &lt;span class="nc"&gt;Cart&lt;/span&gt;&lt;span class="o"&gt;::&lt;/span&gt;&lt;span class="no"&gt;AddItem&lt;/span&gt; &lt;span class="o"&gt;&amp;lt;&lt;/span&gt; &lt;span class="no"&gt;HyperOperation&lt;/span&gt;
  &lt;span class="k"&gt;def&lt;/span&gt; &lt;span class="nf"&gt;execute&lt;/span&gt;
    &lt;span class="no"&gt;ConfirmItemAvailability&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="ss"&gt;sku: &lt;/span&gt;&lt;span class="n"&gt;sku&lt;/span&gt;&lt;span class="p"&gt;).&lt;/span&gt;&lt;span class="nf"&gt;then&lt;/span&gt; &lt;span class="p"&gt;{&lt;/span&gt; &lt;span class="k"&gt;super&lt;/span&gt; &lt;span class="p"&gt;}&lt;/span&gt;
  &lt;span class="k"&gt;end&lt;/span&gt;
&lt;span class="k"&gt;end&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Other questions:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;Can Stores Invoke Operations&lt;/strong&gt;
In general no.  Stores should be kept as simple as possible.  If possible move invocation of the Operation upwards into another Operation&amp;#39;s execute method.  The obvious exception would be if the Store is providing a stream of data from an asynchronous source.  In this case, a Store&amp;#39;s &amp;#39;getter&amp;#39; is going to detect the Data has run out, and can invoke an Operation to get more.  The Operation will be asynchronous and when it resolves can inform the Store that it can update its state with new data.  The way Operations, states, and promises work together make this straight forward to do.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;Can Operations Read From Stores&lt;/strong&gt;
Yes.  Often an Operation will read from one Store to determine if it should update another store.  &lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;Can Operations Invoke Other Operations&lt;/strong&gt;
Yes.  Note that Operations return promises, so asynchronous operation is assumed, Operations can be easily chained.&lt;/p&gt;&lt;/li&gt;
&lt;/ul&gt;
</content>
  </entry>
  <entry>
    <title>Comparing Redux with Hyperloop</title>
    <link rel="alternate" href="http://blog.url.com/blog/2017/01/17/comparing-redux-with-hyperloop/"/>
    <id>http://blog.url.com/blog/2017/01/17/comparing-redux-with-hyperloop/</id>
    <published>2017-01-17T00:00:00+00:00</published>
    <updated>2017-04-11T18:41:54+01:00</updated>
    <author>
      <name>Article Author</name>
    </author>
    <content type="html">&lt;p&gt;@catmando&lt;/p&gt;

&lt;p&gt;In trying to find how Hyperloop models and flux-stores relate, I was rereading the Redux tutorials.  After having been away from that for a while I was amazed how clean Hyperloop&amp;#39;s HyperReact DSL is compared to the typical JSX code.&lt;/p&gt;

&lt;p&gt;For example here is a comparison of &lt;a href="https://github.com/reactjs/redux/tree/master/examples/todomvc"&gt;Redux TodoMVC&lt;/a&gt; and &lt;a href="https://github.com/ruby-hyperloop/todo-tutorial"&gt;Hyperloop TodoMVC&lt;/a&gt; which provide the same Todo UI and function.  (* &lt;em&gt;note that the code presented is slightly different from the linked Hyperloop tutorial as it uses the most recent version of the DSL.&lt;/em&gt;)&lt;/p&gt;

&lt;p&gt;Here are the component code files, which are roughly divided the same way between the two apps.&lt;/p&gt;

&lt;table&gt;&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;JS files&lt;/th&gt;
&lt;th&gt;React/Redux size&lt;/th&gt;
&lt;th&gt;Hyperloop size&lt;/th&gt;
&lt;th&gt;Ruby Files&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;Footer.js&lt;/td&gt;
&lt;td&gt;71&lt;/td&gt;
&lt;td&gt;29&lt;/td&gt;
&lt;td&gt;footer_link.rb, footer.rb&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Header.js, MainSection.js&lt;/td&gt;
&lt;td&gt;103&lt;/td&gt;
&lt;td&gt;25&lt;/td&gt;
&lt;td&gt;index.rb&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;TodoItem.js&lt;/td&gt;
&lt;td&gt;65&lt;/td&gt;
&lt;td&gt;21&lt;/td&gt;
&lt;td&gt;todo_item.rb&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;TodoTextInput.js&lt;/td&gt;
&lt;td&gt;53&lt;/td&gt;
&lt;td&gt;20&lt;/td&gt;
&lt;td&gt;edit_item.rb&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Total&lt;/td&gt;
&lt;td&gt;292&lt;/td&gt;
&lt;td&gt;95&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;&lt;/table&gt;

&lt;p&gt;In addition there are the following &amp;quot;store/action/model&amp;quot; definition files.&lt;/p&gt;

&lt;table&gt;&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;JS files&lt;/th&gt;
&lt;th&gt;React/Redux size&lt;/th&gt;
&lt;th&gt;Hyperloop size&lt;/th&gt;
&lt;th&gt;Ruby Files&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;action/index.js&lt;/td&gt;
&lt;td&gt;8&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;constants/...&lt;/td&gt;
&lt;td&gt;9&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;reducers/todos.js&lt;/td&gt;
&lt;td&gt;55&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;4&lt;/td&gt;
&lt;td&gt;models/public/todo.rb&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;total&lt;/td&gt;
&lt;td&gt;72&lt;/td&gt;
&lt;td&gt;4&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;&lt;/table&gt;

&lt;table&gt;&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;&lt;/th&gt;
&lt;th&gt;React/Redux&lt;/th&gt;
&lt;th&gt;Hyperloop&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;Total&lt;/td&gt;
&lt;td&gt;364&lt;/td&gt;
&lt;td&gt;99&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;&lt;/table&gt;

&lt;p&gt;Note that not only is the Hyperloop version less than 1/3 the size, it is persisting and synchronizing the todo list across multiple browsers!  &lt;/p&gt;

&lt;p&gt;There is nothing wrong with more lines of code, as long as the extra code is adding extra comprehension and making the code easier to maintain.  Unfortunately, I would say this is not the case!&lt;/p&gt;

&lt;p&gt;I looked specifically at the TodoItem.js (65 SLOC) file and compared it to todo_item.rb (21 SLOC) file.&lt;/p&gt;

&lt;p&gt;First, there is a preamble in the JS file (4 lines) which does not exist in the ruby file.&lt;/p&gt;
&lt;pre class="highlight javascript"&gt;&lt;code&gt;&lt;span class="kr"&gt;import&lt;/span&gt; &lt;span class="nx"&gt;React&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="p"&gt;{&lt;/span&gt; &lt;span class="nx"&gt;Component&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="nx"&gt;PropTypes&lt;/span&gt; &lt;span class="p"&gt;}&lt;/span&gt; &lt;span class="nx"&gt;from&lt;/span&gt; &lt;span class="s1"&gt;'react'&lt;/span&gt;
&lt;span class="kr"&gt;import&lt;/span&gt; &lt;span class="nx"&gt;classnames&lt;/span&gt; &lt;span class="nx"&gt;from&lt;/span&gt; &lt;span class="s1"&gt;'classnames'&lt;/span&gt;
&lt;span class="kr"&gt;import&lt;/span&gt; &lt;span class="nx"&gt;TodoTextInput&lt;/span&gt; &lt;span class="nx"&gt;from&lt;/span&gt; &lt;span class="s1"&gt;'./TodoTextInput'&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Then we have the class wrapper which is essentially the same 2 lines in JS vs Ruby:&lt;/p&gt;
&lt;pre class="highlight javascript"&gt;&lt;code&gt;&lt;span class="kr"&gt;export&lt;/span&gt; &lt;span class="k"&gt;default&lt;/span&gt; &lt;span class="kr"&gt;class&lt;/span&gt; &lt;span class="nx"&gt;TodoItem&lt;/span&gt; &lt;span class="kr"&gt;extends&lt;/span&gt; &lt;span class="nx"&gt;Component&lt;/span&gt; &lt;span class="p"&gt;{&lt;/span&gt;
&lt;span class="p"&gt;...&lt;/span&gt;
&lt;span class="p"&gt;}&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;&lt;pre class="highlight ruby"&gt;&lt;code&gt;&lt;span class="k"&gt;class&lt;/span&gt; &lt;span class="nc"&gt;TodoItem&lt;/span&gt; &lt;span class="o"&gt;&amp;lt;&lt;/span&gt; &lt;span class="no"&gt;React&lt;/span&gt;&lt;span class="o"&gt;::&lt;/span&gt;&lt;span class="no"&gt;Component&lt;/span&gt;&lt;span class="o"&gt;::&lt;/span&gt;&lt;span class="no"&gt;Base&lt;/span&gt;
&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nf"&gt;.&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;
&lt;span class="nf"&gt;end&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Then we define the properties, and state (11 lines in JSX vs 3 in Ruby)&lt;/p&gt;
&lt;pre class="highlight javascript"&gt;&lt;code&gt;  &lt;span class="kr"&gt;static&lt;/span&gt; &lt;span class="nx"&gt;propTypes&lt;/span&gt; &lt;span class="o"&gt;=&lt;/span&gt; &lt;span class="p"&gt;{&lt;/span&gt;
    &lt;span class="na"&gt;todo&lt;/span&gt;&lt;span class="p"&gt;:&lt;/span&gt; &lt;span class="nx"&gt;PropTypes&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nx"&gt;object&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nx"&gt;isRequired&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt;
    &lt;span class="na"&gt;editTodo&lt;/span&gt;&lt;span class="p"&gt;:&lt;/span&gt; &lt;span class="nx"&gt;PropTypes&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nx"&gt;func&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nx"&gt;isRequired&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt;
    &lt;span class="na"&gt;deleteTodo&lt;/span&gt;&lt;span class="p"&gt;:&lt;/span&gt; &lt;span class="nx"&gt;PropTypes&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nx"&gt;func&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nx"&gt;isRequired&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt;
    &lt;span class="na"&gt;completeTodo&lt;/span&gt;&lt;span class="p"&gt;:&lt;/span&gt; &lt;span class="nx"&gt;PropTypes&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nx"&gt;func&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nx"&gt;isRequired&lt;/span&gt;
  &lt;span class="p"&gt;}&lt;/span&gt;

  &lt;span class="nx"&gt;state&lt;/span&gt; &lt;span class="o"&gt;=&lt;/span&gt; &lt;span class="p"&gt;{&lt;/span&gt;
    &lt;span class="na"&gt;editing&lt;/span&gt;&lt;span class="p"&gt;:&lt;/span&gt; &lt;span class="kc"&gt;false&lt;/span&gt;
  &lt;span class="p"&gt;}&lt;/span&gt;

&lt;/code&gt;&lt;/pre&gt;&lt;pre class="highlight ruby"&gt;&lt;code&gt;    &lt;span class="n"&gt;param&lt;/span&gt; &lt;span class="ss"&gt;:todo&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="ss"&gt;type: &lt;/span&gt;&lt;span class="no"&gt;Todo&lt;/span&gt;
    &lt;span class="n"&gt;define_state&lt;/span&gt; &lt;span class="ss"&gt;editing: &lt;/span&gt;&lt;span class="kp"&gt;false&lt;/span&gt;

&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;The JS version is simply more verbose.  In addition the JS code has an additional 3 declarations for the &lt;code&gt;deleteTodo&lt;/code&gt;, &lt;code&gt;editTodo&lt;/code&gt; and &lt;code&gt;completeTodo&lt;/code&gt; params.  Because Hyperloop uses ActiveRecord,  reactive (read flux) methods like &lt;code&gt;delete&lt;/code&gt; and the &lt;code&gt;complete&lt;/code&gt; accessor are built into the &lt;code&gt;Todo&lt;/code&gt; model - no extra charge!  &lt;/p&gt;

&lt;p&gt;In the JS file we now have 2 helper methods (13 SLOC) which don&amp;#39;t exist in the Ruby version:&lt;/p&gt;
&lt;pre class="highlight javascript"&gt;&lt;code&gt;  &lt;span class="nx"&gt;handleDoubleClick&lt;/span&gt; &lt;span class="o"&gt;=&lt;/span&gt; &lt;span class="p"&gt;()&lt;/span&gt; &lt;span class="o"&gt;=&amp;gt;&lt;/span&gt; &lt;span class="p"&gt;{&lt;/span&gt;
    &lt;span class="k"&gt;this&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nx"&gt;setState&lt;/span&gt;&lt;span class="p"&gt;({&lt;/span&gt; &lt;span class="na"&gt;editing&lt;/span&gt;&lt;span class="p"&gt;:&lt;/span&gt; &lt;span class="kc"&gt;true&lt;/span&gt; &lt;span class="p"&gt;})&lt;/span&gt;
  &lt;span class="p"&gt;}&lt;/span&gt;

  &lt;span class="nx"&gt;handleSave&lt;/span&gt; &lt;span class="o"&gt;=&lt;/span&gt; &lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="nx"&gt;id&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="nx"&gt;text&lt;/span&gt;&lt;span class="p"&gt;)&lt;/span&gt; &lt;span class="o"&gt;=&amp;gt;&lt;/span&gt; &lt;span class="p"&gt;{&lt;/span&gt;
    &lt;span class="k"&gt;if&lt;/span&gt; &lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="nx"&gt;text&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nx"&gt;length&lt;/span&gt; &lt;span class="o"&gt;===&lt;/span&gt; &lt;span class="mi"&gt;0&lt;/span&gt;&lt;span class="p"&gt;)&lt;/span&gt; &lt;span class="p"&gt;{&lt;/span&gt;
      &lt;span class="k"&gt;this&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nx"&gt;props&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nx"&gt;deleteTodo&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="nx"&gt;id&lt;/span&gt;&lt;span class="p"&gt;)&lt;/span&gt;
    &lt;span class="p"&gt;}&lt;/span&gt; &lt;span class="k"&gt;else&lt;/span&gt; &lt;span class="p"&gt;{&lt;/span&gt;
      &lt;span class="k"&gt;this&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nx"&gt;props&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nx"&gt;editTodo&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="nx"&gt;id&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="nx"&gt;text&lt;/span&gt;&lt;span class="p"&gt;)&lt;/span&gt;
    &lt;span class="p"&gt;}&lt;/span&gt;
    &lt;span class="k"&gt;this&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nx"&gt;setState&lt;/span&gt;&lt;span class="p"&gt;({&lt;/span&gt; &lt;span class="na"&gt;editing&lt;/span&gt;&lt;span class="p"&gt;:&lt;/span&gt; &lt;span class="kc"&gt;false&lt;/span&gt; &lt;span class="p"&gt;})&lt;/span&gt;
  &lt;span class="p"&gt;}&lt;/span&gt;

&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;These methods are defined in blocks directly in the Ruby render method, so there is a bit of a stylistic choice here.  If we had pulled them out as methods &lt;code&gt;handleDoubleClick&lt;/code&gt; would also be three lines long, but &lt;code&gt;handleSave&lt;/code&gt; would only be four lines, as once again ActiveRecord is going to make handling the Todo&amp;#39;s internal state easier.&lt;/p&gt;

&lt;p&gt;Finally we get to the &lt;code&gt;render&lt;/code&gt; method.  In React/Redux it looks like this:
```javascript
  render() {
    const { todo, completeTodo, deleteTodo } = this.props&lt;/p&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;let element
if (this.state.editing) {
  element = (
    &amp;lt;TodoTextInput text={todo.text}
                   editing={this.state.editing}
                   onSave={(text) =&amp;gt; this.handleSave(todo.id, text)} /&amp;gt;
  )
} else {
  element = (
    &amp;lt;div className="view"&amp;gt;
      &amp;lt;input className="toggle"
             type="checkbox"
             checked={todo.completed}
             onChange={() =&amp;gt; completeTodo(todo.id)} /&amp;gt;
      &amp;lt;label onDoubleClick={this.handleDoubleClick}&amp;gt;
        {todo.text}
      &amp;lt;/label&amp;gt;
      &amp;lt;button className="destroy"
              onClick={() =&amp;gt; deleteTodo(todo.id)} /&amp;gt;
    &amp;lt;/div&amp;gt;
  )
}

return (
  &amp;lt;li className={classnames({
    completed: todo.completed,
    editing: this.state.editing
  })}&amp;gt;
    {element}
  &amp;lt;/li&amp;gt;
)
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;}
```&lt;/p&gt;

&lt;p&gt;Before we look at the details of these 34 lines (vs 15 in Ruby) there are some JS statements which are simply not needed in Ruby, and which really clutter up reading the code.  These are:&lt;/p&gt;
&lt;pre class="highlight javascript"&gt;&lt;code&gt;    &lt;span class="kr"&gt;const&lt;/span&gt; &lt;span class="p"&gt;{&lt;/span&gt; &lt;span class="nx"&gt;todo&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="nx"&gt;completeTodo&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="nx"&gt;deleteTodo&lt;/span&gt; &lt;span class="p"&gt;}&lt;/span&gt; &lt;span class="o"&gt;=&lt;/span&gt; &lt;span class="k"&gt;this&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nx"&gt;props&lt;/span&gt;

    &lt;span class="kd"&gt;let&lt;/span&gt; &lt;span class="nx"&gt;element&lt;/span&gt;
    &lt;span class="p"&gt;...&lt;/span&gt;
      &lt;span class="nx"&gt;element&lt;/span&gt; &lt;span class="o"&gt;=&lt;/span&gt; &lt;span class="p"&gt;(&lt;/span&gt;
      &lt;span class="p"&gt;...&lt;/span&gt;
      &lt;span class="p"&gt;)&lt;/span&gt;
      &lt;span class="p"&gt;...&lt;/span&gt;
      &lt;span class="nx"&gt;element&lt;/span&gt; &lt;span class="o"&gt;=&lt;/span&gt; &lt;span class="p"&gt;(&lt;/span&gt;
      &lt;span class="p"&gt;...&lt;/span&gt;
      &lt;span class="p"&gt;)&lt;/span&gt;
    &lt;span class="p"&gt;...&lt;/span&gt;
    &lt;span class="k"&gt;return&lt;/span&gt; &lt;span class="p"&gt;(&lt;/span&gt;
      &lt;span class="p"&gt;...&lt;/span&gt;
    &lt;span class="p"&gt;)&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;These 8 lines which are almost 25% of the JS render method, and add very little clarity to the method.  What do these 8 lines do?&lt;/p&gt;

&lt;p&gt;First we reassign the props to intermediate constants presumably to save a little time, and to make it so we can shorten &lt;code&gt;this.props[:todo]&lt;/code&gt; to just &lt;code&gt;todo&lt;/code&gt;.  In Hyperloop you access props more directly using the &lt;code&gt;params&lt;/code&gt; object which takes care of accessing and caching the property, so you would say &lt;code&gt;params.todo&lt;/code&gt;.  &lt;em&gt;A note:  originally you could just say &lt;code&gt;todo&lt;/code&gt; without the &lt;code&gt;params.&lt;/code&gt; prefix, but it was determined that made the code harder to read.  So this behavior is being deprecated.  A case where more typing is helpful.&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;Then (for stylistic reasons I assume) we compute the child of the &lt;code&gt;li&lt;/code&gt; element before actually generating the element.  Perhaps the mix of JSX and JS code would quickly get confusing if nested too deeply?&lt;/p&gt;

&lt;p&gt;Finally, you have to wrap the whole thing in a return statement, which is just an artifact of JS.&lt;/p&gt;

&lt;p&gt;Basically what I see happening here is that JS/JSX is more verbose, so in order to add comprehension, the flow of the code is broken up, methods are added, and intermediate values are introduced.  The result is a snowball effect.&lt;/p&gt;

&lt;p&gt;Here is complete ruby class for comparison.
```ruby
class TodoItem &amp;lt; React::Component::Base&lt;/p&gt;

&lt;p&gt;param :todo, type: Todo
  define_state editing: false&lt;/p&gt;

&lt;p&gt;render(LI, class: &amp;#39;todo-item&amp;#39;) do
    if state.editing
      EditItem(todo: todo).
      on(:save) do
        todo.delete if todo.text.blank?
        state.editing! false
      end.
      on(:cancel) { state.editing! false }
    else
      INPUT(class: :toggle, type: :checkbox, checked: params.todo.completed).
      on(:click) { params.todo.update(completed: !params.todo.completed }
      LABEL { params.todo.title }.on(:doubleClick) { state.editing! true }
      A(class: :destroy).on(:click) { params.todo.destroy }
    end
  end
end
```&lt;/p&gt;

&lt;p&gt;and here is the complete JSX class:
```jsx
import React, { Component, PropTypes } from &amp;#39;react&amp;#39;
import classnames from &amp;#39;classnames&amp;#39;
import TodoTextInput from &amp;#39;./TodoTextInput&amp;#39;&lt;/p&gt;

&lt;p&gt;export default class TodoItem extends Component {
  static propTypes = {
    todo: PropTypes.object.isRequired,
    editTodo: PropTypes.func.isRequired,
    deleteTodo: PropTypes.func.isRequired,
    completeTodo: PropTypes.func.isRequired
  }&lt;/p&gt;

&lt;p&gt;state = {
    editing: false
  }&lt;/p&gt;

&lt;p&gt;handleDoubleClick = () =&amp;gt; {
    this.setState({ editing: true })
  }&lt;/p&gt;

&lt;p&gt;handleSave = (id, text) =&amp;gt; {
    if (text.length === 0) {
      this.props.deleteTodo(id)
    } else {
      this.props.editTodo(id, text)
    }
    this.setState({ editing: false })
  }&lt;/p&gt;

&lt;p&gt;render() {
    const { todo, completeTodo, deleteTodo } = this.props&lt;/p&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;let element
if (this.state.editing) {
  element = (
    &amp;lt;TodoTextInput text={todo.text}
                   editing={this.state.editing}
                   onSave={(text) =&amp;gt; this.handleSave(todo.id, text)} /&amp;gt;
  )
} else {
  element = (
    &amp;lt;div className="view"&amp;gt;
      &amp;lt;input className="toggle"
             type="checkbox"
             checked={todo.completed}
             onChange={() =&amp;gt; completeTodo(todo.id)} /&amp;gt;
      &amp;lt;label onDoubleClick={this.handleDoubleClick}&amp;gt;
        {todo.text}
      &amp;lt;/label&amp;gt;
      &amp;lt;button className="destroy"
              onClick={() =&amp;gt; deleteTodo(todo.id)} /&amp;gt;
    &amp;lt;/div&amp;gt;
  )
}

return (
  &amp;lt;li className={classnames({
    completed: todo.completed,
    editing: this.state.editing
  })}&amp;gt;
    {element}
  &amp;lt;/li&amp;gt;
)
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;}
}
```&lt;/p&gt;

&lt;p&gt;I didn&amp;#39;t intend this to be such a rant, and it probably sounds more negative than I intend this to be.&lt;/p&gt;

&lt;p&gt;Hyperloop is built on top of React, which is a great library.  The problem is that JS just doesn&amp;#39;t have the expressive power especially when it comes to meta-programming and creating DSLs that Ruby does.  Instead of a nice clean syntax the mix of HTML and JS presented by JSX is confusing, and to de-confuse things you add more code.  Furthermore, because Hyperloop is also built on tried and true of ActiveRecord, again you have an increase in comprehension with a reduction in code.&lt;/p&gt;
</content>
  </entry>
  <entry>
    <title>Hyperloop is born</title>
    <link rel="alternate" href="http://blog.url.com/blog/2016/09/08/Hyperloop-is-born/"/>
    <id>http://blog.url.com/blog/2016/09/08/Hyperloop-is-born/</id>
    <published>2016-09-08T06:50:00+01:00</published>
    <updated>2017-04-11T18:41:54+01:00</updated>
    <author>
      <name>Article Author</name>
    </author>
    <content type="html">&lt;p&gt;Reactrb is being renamed Ruby Hyperloop to reflect the change in emphasis of the project. We have chosen Hyperloop as an umbrella name for the project as it is more expansive and allows us to build out Hyperloop as a web application framework.&lt;/p&gt;

&lt;p&gt;React and Reactrb (being renamed HyperReact) remain fundamental parts of this project.&lt;/p&gt;

&lt;h2 id="gems"&gt;Gems&lt;/h2&gt;

&lt;p&gt;All of the Hyperloop core gems will take on a Hyper-name. The naming convention will be HyperReact when discussion the gem and the actual gem will be &lt;code&gt;hyper-rect&lt;/code&gt;. All of the gems will follow this convention.&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Reactrb becomes &lt;strong&gt;HyperReact&lt;/strong&gt;&lt;/li&gt;
&lt;li&gt;Reactrb Router becomes &lt;strong&gt;HyperRouter&lt;/strong&gt;&lt;/li&gt;
&lt;li&gt;Reactive Record and Synchromesh will be merged to become one gem, &lt;strong&gt;HyperMesh&lt;/strong&gt;&lt;/li&gt;
&lt;li&gt;Reactrb Rails Generator becomes &lt;strong&gt;HyperRails&lt;/strong&gt;&lt;/li&gt;
&lt;li&gt;Reactrb Express becomes &lt;strong&gt;Hyperloop Express&lt;/strong&gt;&lt;/li&gt;
&lt;/ul&gt;

&lt;h2 id="website"&gt;Website&lt;/h2&gt;

&lt;ul&gt;
&lt;li&gt;Reactrb.org is changing to &lt;strong&gt;ruby-hyperloop.io&lt;/strong&gt;&lt;/li&gt;
&lt;li&gt;The goal of this refactor is to reposition Reactrb as an umbrella project for Reactrb and associated Isomorphic ruby technologies&lt;/li&gt;
&lt;li&gt;The emphasis of the site will be to show how simple Reactrb is to use and also to show best practice for taking it further (Stores, etc). There will be a few tutorials.&lt;/li&gt;
&lt;li&gt;The new Reactrb.org will not try to mirroring the React(JS) site – but will have its own identity and structure but it will use as much of the existing Reactrb content as possible&lt;/li&gt;
&lt;li&gt;Remove all the original React(JS) text and structure (basically remove everything that comes from the original React site and does not pertain to Reactrb)&lt;/li&gt;
&lt;li&gt;New fresh looking design&lt;/li&gt;
&lt;li&gt;The new site documentation will include Architectural and + Pattern discussions, describing best practice when working with React like components and stores&lt;/li&gt;
&lt;li&gt;There will be a section on Reactrb development tools (Opal Console) and techniques&lt;/li&gt;
&lt;li&gt;All of the above Gem’s documentation should be on reactrb.org. The individual Gem’s Read-me’s should be minimal and refer to each Gem’s page on reactrb.org so we can emphasize that these gems are a part of the same family and explain how they work together include installation, usage and best practice instructions for use with:

&lt;ul&gt;
&lt;li&gt;Rails&lt;/li&gt;
&lt;li&gt;Sinatra&lt;/li&gt;
&lt;li&gt;Webpack &amp;amp; NPM&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;li&gt;Will still include Live Ruby examples through Opal Playground&lt;/li&gt;
&lt;li&gt;The site will continue to be hosted on Github pages but the underlying technology will change to:

&lt;ul&gt;
&lt;li&gt;Reactrb Express&lt;/li&gt;
&lt;li&gt;Middleman&lt;/li&gt;
&lt;/ul&gt;&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;The changes will be made over time so some Gems, Docs and Tutorials might reference Reactrb or their previous names.&lt;/p&gt;
</content>
  </entry>
  <entry>
    <title>Reactrb v0.8.5</title>
    <link rel="alternate" href="http://blog.url.com/blog/2016/06/29/reactrb-v0-8-5/"/>
    <id>http://blog.url.com/blog/2016/06/29/reactrb-v0-8-5/</id>
    <published>2016-06-29T01:00:00+01:00</published>
    <updated>2017-04-11T18:41:54+01:00</updated>
    <author>
      <name>Article Author</name>
    </author>
    <content type="html">&lt;p&gt;Wow - its already been a hot sweaty summer around here in Reactrb land.  First off after a lot of discussion and thinking we have decided to consistently rename everything &lt;strong&gt;Reactrb&lt;/strong&gt;.  We are sad to see the &amp;quot;dot&amp;quot; go, but this way the name is consistent everywhere, twitter handle, domain name, github org name, etc.&lt;/p&gt;

&lt;p&gt;Within the &lt;a href="https://github.com/reactrb"&gt;github org&lt;/a&gt; we will use the reactb prefix for all gems and repos unless it really doesn&amp;#39;t make sense.  So you will find in the repo:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;reactrb-express (formerly inline-reactive-ruby)&lt;/li&gt;
&lt;li&gt;reactrb-examples (looking help here to clean these up...)&lt;/li&gt;
&lt;li&gt;reactrb-router (formerly reactive-router)&lt;/li&gt;
&lt;li&gt;reactrb-rails-generator (formerly reactive&lt;em&gt;rails&lt;/em&gt;generator)&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;For the moment reactive-record is going to keep its name, just because its so much fun.  There is a concept to make a gem called reactrb-model that would be the base for reactive-record, but would be agnostic to the persistence mechanism.&lt;/p&gt;

&lt;p&gt;This name change and reorganization should help make finding out about Reactrb easier, but its not going to help anybody write code faster or better.  So we wanted to at least get in a few improvements as well:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;&lt;a href="#you-pick-your-react-version"&gt;You Pick Your React Version&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="#better-native-imports"&gt;Better Native Imports&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="#render-call-back"&gt;Render Call Back&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="#caps-tag-names"&gt;CAPS Tag Names&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;

&lt;h2 id="you-pick-your-react-version"&gt;You Pick Your React Version&lt;/h2&gt;

&lt;p&gt;We really needed this one... With every gem and javascript component bundle pulling for a different version of react, Reactrb needed to step out of the way!&lt;/p&gt;

&lt;p&gt;Reactrb is now tested with React V13-V15, and by default does &lt;em&gt;not&lt;/em&gt; include any version when you &lt;code&gt;require &amp;#39;reactrb&amp;#39;&lt;/code&gt;.  &lt;/p&gt;

&lt;p&gt;This gives you at least three ways to include React source into your assets:&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;&lt;p&gt;If you are using Webpack or another Javascript dependency manager, then let the Javascript tool chain work out which version to use.  &lt;/p&gt;

&lt;p&gt;Just make sure that you include both &lt;code&gt;react&lt;/code&gt; and &lt;code&gt;react-dom&lt;/code&gt; as Reactrb needs both.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;If you are using the react-rails gem then do a &lt;code&gt;require &amp;#39;react&amp;#39;&lt;/code&gt; just before you do a &lt;code&gt;require &amp;#39;reactrb&amp;#39;&lt;/code&gt; in your &lt;code&gt;components.rb&lt;/code&gt; file.  &lt;/p&gt;

&lt;p&gt;This will load the version compatible with react-rails.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;If you are using react-rails &lt;em&gt;and&lt;/em&gt; a Javascript dependency manager, then check &lt;a href="https://github.com/reactjs/react-rails/blob/master/VERSIONS.md"&gt;here&lt;/a&gt; for the version that react-rails wants, and include that version explicitly with &lt;code&gt;npm&lt;/code&gt; or whatever tool you are using on the JS side.&lt;/p&gt;

&lt;p&gt;This will let the JS tool chain manage the dependencies, but insure you have a compatible version for react-rails.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;Otherwise Reactrb includes (but does not require) several versions of react source.   Just add &lt;code&gt;require &amp;#39;react-latest&amp;#39;&lt;/code&gt; right above wherever you do a &lt;code&gt;require &amp;#39;hyper-react&amp;#39;&lt;/code&gt;.  &lt;/p&gt;

&lt;p&gt;If you want another version do &lt;code&gt;require &amp;#39;react-v14&amp;#39;&lt;/code&gt; or &lt;code&gt;require &amp;#39;react-v13&amp;#39;&lt;/code&gt;&lt;/p&gt;&lt;/li&gt;
&lt;/ol&gt;

&lt;h2 id="better-native-imports"&gt;Better Native Imports&lt;/h2&gt;

&lt;p&gt;Previously you could not import single javascript components into the Reactrb namespace.  They had to be wrapped is some kind of library structure for the &lt;code&gt;NativeLibrary&lt;/code&gt; class to work.  &lt;/p&gt;

&lt;p&gt;We wanted to keep &lt;code&gt;NativeLibrary&lt;/code&gt; as strictly the mechanism that imports libraries of components, and so we added the &lt;code&gt;imports&lt;/code&gt; directive to &lt;code&gt;React::Component&lt;/code&gt;.&lt;/p&gt;

&lt;p&gt;So now you can say:&lt;/p&gt;
&lt;pre class="highlight ruby"&gt;&lt;code&gt;&lt;span class="k"&gt;class&lt;/span&gt; &lt;span class="nc"&gt;Griddle&lt;/span&gt; &lt;span class="o"&gt;&amp;lt;&amp;lt;&lt;/span&gt; &lt;span class="no"&gt;React&lt;/span&gt;&lt;span class="o"&gt;::&lt;/span&gt;&lt;span class="no"&gt;Component&lt;/span&gt;&lt;span class="o"&gt;::&lt;/span&gt;&lt;span class="no"&gt;Base&lt;/span&gt;
  &lt;span class="n"&gt;imports&lt;/span&gt; &lt;span class="s1"&gt;'Griddle'&lt;/span&gt;
&lt;span class="k"&gt;end&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Now once you install the the &lt;a href="http://griddlegriddle.github.io/Griddle/"&gt;Griddle&lt;/a&gt; Javascript component you can use &lt;code&gt;Griddle&lt;/code&gt; like any other HyperReact component.&lt;/p&gt;

&lt;p&gt;&lt;em&gt;But wait there&amp;#39;s more...&lt;/em&gt;&lt;/p&gt;

&lt;p&gt;Importing a ton of libraries this way could get tedious especially if you are using something like Webpack anyway to manage which components to include.&lt;/p&gt;

&lt;p&gt;To keep things easy, you can opt in to &lt;em&gt;auto-import&lt;/em&gt; by simply adding &lt;code&gt;require &amp;#39;hyper-react/auto-import&amp;#39;&lt;/code&gt; after you &lt;code&gt;require hyper-react&lt;/code&gt;.&lt;/p&gt;

&lt;p&gt;With auto-importing enabled a component like &lt;code&gt;Griddle&lt;/code&gt; or a library like &lt;code&gt;ReactBootstrap&lt;/code&gt; will automatically be available to your HyperReact components.&lt;/p&gt;

&lt;p&gt;See &lt;a href="/using-javascript-components.html"&gt;Using Javascript Components&lt;/a&gt; for more details.&lt;/p&gt;

&lt;h2 id="render-call-back"&gt;Render Call back&lt;/h2&gt;

&lt;p&gt;Up till now we have been defining the render method as just that &lt;em&gt;an instance method in your component class.&lt;/em&gt;  That&amp;#39;s cool, and that still works, however for a couple of reasons we felt having a call back to define the render method would be handy.  &lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;Render methods are too large:&lt;/strong&gt; Even using helper methods to keep things small, render methods often exceed the normal 10 line ruby style guide recommendation.  &lt;/p&gt;

&lt;p&gt;That is not a problem in itself - after all recommendations are just that.  However if you are using tools like RuboCop, then it&amp;#39;s sad when every single one of your components has a warning flag.  You can turn off that cop of course, but then lose a very valuable check that most of the times should be followed.  &lt;/p&gt;

&lt;p&gt;By allowing render to be defined as a call back, you get rid of this problem.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;Get Rid of Boiler Plate:&lt;/strong&gt; All components must have a single outer container, and for many components this container and its parameters are static.  So the new render call back lets you specify the container component and its parameters as params to the callback.  This eliminates two unnecessary lines per component, plus an unneeded level of indentation, and I think when used properly it makes things clearer.&lt;/p&gt;&lt;/li&gt;
&lt;li&gt;&lt;p&gt;&lt;strong&gt;Consistency:&lt;/strong&gt; All the other lifecycle methods are defined as callbacks, so its nice to have render fit in.&lt;/p&gt;&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;Meanwhile the &lt;code&gt;Element[...].render&lt;/code&gt; method which can be used to mount a top level component to a DOM element, has been updated to follow the same syntax as well.  So for example to mount a component you can just say &lt;code&gt;Element[&amp;#39;#top-level&amp;#39;].render App&lt;/code&gt;.&lt;/p&gt;

&lt;p&gt;This is not a big deal but I think you should try it out, and see if it doesn&amp;#39;t lead to more readable components.&lt;/p&gt;

&lt;h2 id="caps-tag-names"&gt;CAPS Tag Names&lt;/h2&gt;

&lt;p&gt;Its been suggested that especially for beginners its a little hard to parse the DSL.  You don&amp;#39;t know which method is what, and its hard to tell the difference between tags like &lt;code&gt;select&lt;/code&gt; and other helper methods.  One way to solve this is to write the built-in tag names in all caps, which the DSL now supports.&lt;/p&gt;

&lt;p&gt;It was a small thing, so we went ahead and added it.  Tell us what you think!&lt;/p&gt;
</content>
  </entry>
  <entry>
    <title>Getting Started with Reactrb and Rails</title>
    <link rel="alternate" href="http://blog.url.com/blog/2016/01/26/getting-started-with-reactrb-and-rails/"/>
    <id>http://blog.url.com/blog/2016/01/26/getting-started-with-reactrb-and-rails/</id>
    <published>2016-01-26T16:29:00+00:00</published>
    <updated>2017-04-11T18:41:54+01:00</updated>
    <author>
      <name>Article Author</name>
    </author>
    <content type="html">&lt;p&gt;&lt;a href="//facebook.github.io/react/"&gt;React.js&lt;/a&gt; support for rails is provided
&lt;a href="https://github.com/reactjs/react-rails"&gt;react-rails&lt;/a&gt; gem.&lt;/p&gt;

&lt;p&gt;From its project page, React-rails can:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;  Provide various react builds to your asset bundle&lt;/li&gt;
&lt;li&gt;  Transform .jsx in the asset pipeline&lt;/li&gt;
&lt;li&gt;  Render components into views and mount them via view helper &amp;amp; react_ujs&lt;/li&gt;
&lt;li&gt;  Render components server-side with prerender: true&lt;/li&gt;
&lt;li&gt;  Generate components with a Rails generator&lt;/li&gt;
&lt;li&gt;  Be extended with custom renderers, transformers and view helpers&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;While &lt;code&gt;react-rails&lt;/code&gt; provides easy integration with Rails, a Rails
developer cannot leverage the full benefits of React.js, particularly
isomorphic/&lt;a href="https://medium.com/@mjackson/universal-javascript-4761051b7ae9#.rxrgqe5wb"&gt;universal&lt;/a&gt;
domain logic code and views since different languages are used on
server and client
sides. &lt;a href="https://github.com/zetachang/react.rb"&gt;React.rb/reactive-ruby&lt;/a&gt;
(&lt;strong&gt;react.rb&lt;/strong&gt; from here on) builds on top of &lt;code&gt;react-rails&lt;/code&gt; by allowing
one to write React components in Ruby, courtesy of
&lt;a href="http://opalrb.org"&gt;Opal&lt;/a&gt;.  Now the Rails programmer can also enjoy
universal domain logic and views written in Ruby via react.js.&lt;/p&gt;

&lt;p&gt;The focus of this article will be limited to just getting &lt;code&gt;react.rb&lt;/code&gt;
up and running on Rails from scratch.&lt;/p&gt;

&lt;h1 id="generate-a-rails-project-that-uses-opal"&gt;Generate a rails project that uses Opal&lt;/h1&gt;

&lt;p&gt;The easiest way to create a Rails project that uses &lt;a href="http://opalrb.org"&gt;Opal&lt;/a&gt; is to use the
&lt;code&gt;--javascript=opal&lt;/code&gt; option. Manual instructions on how add Opal
support to an existing Rails project are given on the &lt;a href="https://github.com/opal/opal-rails"&gt;opal-rails&lt;/a&gt;
site. Create a new Rails project with the following command:&lt;/p&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;% rails new getting-started-react-rails --javascript=opal
&lt;/code&gt;&lt;/pre&gt;
&lt;h1 id="add-react-rb-gems-to-gemfile"&gt;Add react.rb gems to Gemfile&lt;/h1&gt;

&lt;p&gt;To use &lt;code&gt;react.rb&lt;/code&gt;, you need to add 3 gems to your Gemfile:
reactive-ruby&lt;sup&gt;&lt;a id="fnr.1" class="footref" href="#fn.1"&gt;1&lt;/a&gt;&lt;/sup&gt;, react-rails and therubyracer&lt;/p&gt;
&lt;pre class="highlight ruby"&gt;&lt;code&gt;    &lt;span class="n"&gt;gem&lt;/span&gt; &lt;span class="s1"&gt;'reactive-ruby'&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="s1"&gt;'0.7.29'&lt;/span&gt; &lt;span class="c1"&gt;# nail down compatible version w/ pre 0.14 react-rails&lt;/span&gt;
    &lt;span class="n"&gt;gem&lt;/span&gt; &lt;span class="s1"&gt;'react-rails'&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="s1"&gt;'1.3.2'&lt;/span&gt; &lt;span class="c1"&gt;# react.rb not compatible ith 1.4.* yet so use this one&lt;/span&gt;
    &lt;span class="n"&gt;gem&lt;/span&gt; &lt;span class="s1"&gt;'opal-rails'&lt;/span&gt; &lt;span class="c1"&gt;# already added w/the --javascript=opal option&lt;/span&gt;
    &lt;span class="n"&gt;gem&lt;/span&gt; &lt;span class="s1"&gt;'therubyracer'&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="ss"&gt;platforms: :ruby&lt;/span&gt; &lt;span class="c1"&gt;# Required for server side prerendering&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Run &lt;code&gt;bundle install&lt;/code&gt; after these have been added to your Gemfile.&lt;/p&gt;

&lt;h3 id="update"&gt;Update&lt;/h3&gt;

&lt;p&gt;Since this article was written there has been Rails generator code
that has been written as a
&lt;a href="https://rubygems.org/gems/reactrb-rails-generator"&gt;standalone gem&lt;/a&gt;
that is pending integration with react.rb gem.  Some of conventions
described in this article, which currently match that of existing
documentation and sample Rails project in react.rb will likely be
changing as part of that.&lt;/p&gt;

&lt;h1 id="convert-application-js-to-application-js-rb"&gt;Convert application.js to application.js.rb&lt;/h1&gt;

&lt;p&gt;When using opal-rails, it is recommented&lt;sup&gt;&lt;a id="fnr.2" class="footref" href="#fn.2"&gt;2&lt;/a&gt;&lt;/sup&gt;
to convert the application.js file to application.js.rb.  Make yours look
like this:&lt;/p&gt;
&lt;pre class="highlight ruby"&gt;&lt;code&gt;    &lt;span class="c1"&gt;# app/assets/javascripts/application.js.rb&lt;/span&gt;
    &lt;span class="nb"&gt;require&lt;/span&gt; &lt;span class="s1"&gt;'opal'&lt;/span&gt;
    &lt;span class="nb"&gt;require&lt;/span&gt; &lt;span class="s1"&gt;'opal_ujs'&lt;/span&gt;
    &lt;span class="nb"&gt;require&lt;/span&gt; &lt;span class="s1"&gt;'turbolinks'&lt;/span&gt;
    &lt;span class="nb"&gt;require&lt;/span&gt; &lt;span class="s1"&gt;'react'&lt;/span&gt;
    &lt;span class="nb"&gt;require&lt;/span&gt; &lt;span class="s1"&gt;'react_ujs'&lt;/span&gt;
    &lt;span class="nb"&gt;require&lt;/span&gt; &lt;span class="s1"&gt;'components'&lt;/span&gt; &lt;span class="c1"&gt;# to include isomorphic react components on the client&lt;/span&gt;
    &lt;span class="n"&gt;require_tree&lt;/span&gt; &lt;span class="s1"&gt;'.'&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;h1 id="setup-for-isomorphic3-react-components"&gt;Setup for isomorphic&lt;sup&gt;&lt;a id="fnr.3" class="footref" href="#fn.3"&gt;3&lt;/a&gt;&lt;/sup&gt; React components&lt;/h1&gt;

&lt;p&gt;A big perk of react.js is isomorphic code (same code on server and
client side), which leads to A united UI layer. As mentioned before
&lt;a href="https://github.com/reactjs/react-rails"&gt;react-rails&lt;/a&gt; provides server rendered react.js components, as well as
other perks as detailed in this &lt;a href="http://bensmithett.com/server-rendered-react-components-in-rails/"&gt;this article&lt;/a&gt;.  This quote from the
aforementioned article gives one a sense of how big a perk this is.&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;The Holy Grail. The united UI layer. Serve up real HTML on first page load, then kick off a client side JS app. All without duplicating a single line of UI code.&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;Those who have struggled with duplicated views on front and back ends,
in different languages should appreciate that sentiment. To support
isomorphic react.rb components you need to setup a structure for these
&lt;strong&gt;shared&lt;/strong&gt; components. The current convention is to make a
&lt;code&gt;app/views/components&lt;/code&gt; directory containing the components and a
&lt;code&gt;components.rb&lt;/code&gt; manifest file that will require all the &lt;code&gt;react.rb&lt;/code&gt;
components, like so:&lt;/p&gt;
&lt;pre class="highlight ruby"&gt;&lt;code&gt;    &lt;span class="c1"&gt;# app/views/components.rb&lt;/span&gt;
    &lt;span class="nb"&gt;require&lt;/span&gt; &lt;span class="s1"&gt;'opal'&lt;/span&gt;
    &lt;span class="nb"&gt;require&lt;/span&gt; &lt;span class="s1"&gt;'reactive-ruby'&lt;/span&gt;
    &lt;span class="n"&gt;require_tree&lt;/span&gt; &lt;span class="s1"&gt;'./components'&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;You may have noticed that, that the &lt;code&gt;application.js.rb&lt;/code&gt; we created
&lt;code&gt;require&lt;/code&gt;s this components.rb file to compile these universal
&lt;code&gt;react.rb&lt;/code&gt; components.&lt;/p&gt;

&lt;h1 id="make-a-controller-to-demonstrate-react-components"&gt;Make a controller to demonstrate react components&lt;/h1&gt;

&lt;p&gt;We will be demonstrating several types of components as
examples. Let&amp;#39;s make a dedicated controller to demo these components with
dedicated actions for each case.&lt;/p&gt;
&lt;pre class="highlight shell"&gt;&lt;code&gt;    % rails g controller home isomorphic iso_convention search_path client_only
&lt;/code&gt;&lt;/pre&gt;
&lt;h1 id="create-your-first-react-component"&gt;Create your first React Component&lt;/h1&gt;

&lt;p&gt;So now that we&amp;#39;re setup for isomorphic components, lets make our first
react.rb component.  We&amp;#39;ll start with a simple &amp;quot;Hello World&amp;quot;
component.  This component takes a single, required param message of
type &lt;code&gt;String&lt;/code&gt;. Note, param in &lt;code&gt;react.rb&lt;/code&gt; corresonds to prop in
react.js; &lt;code&gt;react.rb&lt;/code&gt; calls props &amp;quot;params&amp;quot; to provide a more Rails
familiar API. The component renders this message param in an &lt;strong&gt;h1&lt;/strong&gt; element,
and renders a button that, when clicked, calls &lt;code&gt;alert()&lt;/code&gt; with the same
message.&lt;/p&gt;

&lt;p&gt;Put the following into this file &lt;strong&gt;app/views/components/hello.rb&lt;/strong&gt;:&lt;/p&gt;
&lt;pre class="highlight ruby"&gt;&lt;code&gt;    &lt;span class="k"&gt;class&lt;/span&gt; &lt;span class="nc"&gt;Hello&lt;/span&gt;
      &lt;span class="kp"&gt;include&lt;/span&gt; &lt;span class="no"&gt;React&lt;/span&gt;&lt;span class="o"&gt;::&lt;/span&gt;&lt;span class="no"&gt;Component&lt;/span&gt;
      &lt;span class="n"&gt;required_param&lt;/span&gt; &lt;span class="ss"&gt;:what&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="ss"&gt;type: &lt;/span&gt;&lt;span class="no"&gt;String&lt;/span&gt;

      &lt;span class="k"&gt;def&lt;/span&gt; &lt;span class="nf"&gt;message&lt;/span&gt;
        &lt;span class="s2"&gt;"Hello &lt;/span&gt;&lt;span class="si"&gt;#{&lt;/span&gt;&lt;span class="n"&gt;what&lt;/span&gt;&lt;span class="si"&gt;}&lt;/span&gt;&lt;span class="s2"&gt;"&lt;/span&gt;
      &lt;span class="k"&gt;end&lt;/span&gt;

      &lt;span class="k"&gt;def&lt;/span&gt; &lt;span class="nf"&gt;render&lt;/span&gt;
        &lt;span class="n"&gt;div&lt;/span&gt; &lt;span class="p"&gt;{&lt;/span&gt;
          &lt;span class="n"&gt;h1&lt;/span&gt; &lt;span class="p"&gt;{&lt;/span&gt; &lt;span class="n"&gt;message&lt;/span&gt; &lt;span class="p"&gt;}&lt;/span&gt;
          &lt;span class="n"&gt;button&lt;/span&gt; &lt;span class="p"&gt;{&lt;/span&gt;&lt;span class="s2"&gt;"Press me"&lt;/span&gt;&lt;span class="p"&gt;}.&lt;/span&gt;&lt;span class="nf"&gt;on&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="ss"&gt;:click&lt;/span&gt;&lt;span class="p"&gt;)&lt;/span&gt; &lt;span class="p"&gt;{&lt;/span&gt;&lt;span class="n"&gt;alert&lt;/span&gt; &lt;span class="n"&gt;message&lt;/span&gt;&lt;span class="p"&gt;}&lt;/span&gt;
        &lt;span class="p"&gt;}&lt;/span&gt;
      &lt;span class="k"&gt;end&lt;/span&gt;
    &lt;span class="k"&gt;end&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;You can render the &lt;code&gt;Hello&lt;/code&gt; component directly without needing a
template file in your controller with
&lt;code&gt;render_component()&lt;/code&gt;. &lt;code&gt;render_component()&lt;/code&gt; takes an optional (more on
this later) class name of the component and any parameters you wish to
pass the component.  Implement the &lt;code&gt;isomorphic&lt;/code&gt; action in the
&lt;code&gt;HomeController&lt;/code&gt; like so&lt;/p&gt;
&lt;pre class="highlight ruby"&gt;&lt;code&gt;    &lt;span class="k"&gt;class&lt;/span&gt; &lt;span class="nc"&gt;HomeController&lt;/span&gt; &lt;span class="o"&gt;&amp;lt;&lt;/span&gt; &lt;span class="no"&gt;ApplicationController&lt;/span&gt;
      &lt;span class="k"&gt;def&lt;/span&gt; &lt;span class="nf"&gt;isomorphic&lt;/span&gt;
        &lt;span class="n"&gt;render_component&lt;/span&gt; &lt;span class="s1"&gt;'Hello'&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="ss"&gt;message: &lt;/span&gt;&lt;span class="s1"&gt;'World'&lt;/span&gt;
      &lt;span class="k"&gt;end&lt;/span&gt;
    &lt;span class="k"&gt;end&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Start the server, then visit &lt;a href="http://localhost:3000/home/isomorphic"&gt;&lt;a href="http://localhost:3000/home/isomorphic"&gt;http://localhost:3000/home/isomorphic&lt;/a&gt;&lt;/a&gt; to
view the component.  By default, react.rb prerenders the component on
the server (the reverse of react-rails&amp;#39; &lt;code&gt;react_component()&lt;/code&gt;, but you can force Rails to NOT prerender by appending
?no_prerender=1 to the url, like so&lt;/p&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;http://localhost:3000/home/isomorphic?no_prerender=1
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Let&amp;#39;s take a quick look at the HTML returned by the server in both cases (formatted to be more human-readable)&lt;/p&gt;

&lt;p&gt;For &lt;a href="http://localhost:3000/home/isomorphic"&gt;&lt;a href="http://localhost:3000/home/isomorphic"&gt;http://localhost:3000/home/isomorphic&lt;/a&gt;&lt;/a&gt;
we see the &lt;strong&gt;h1&lt;/strong&gt; and button rendered from the server:&lt;/p&gt;
&lt;pre class="highlight html"&gt;&lt;code&gt;    &lt;span class="nt"&gt;&amp;lt;div&lt;/span&gt; &lt;span class="na"&gt;data-react-class=&lt;/span&gt;&lt;span class="s"&gt;"React.TopLevelRailsComponent"&lt;/span&gt;
         &lt;span class="na"&gt;data-react-props=&lt;/span&gt;&lt;span class="s"&gt;"{&amp;amp;quot;render_params&amp;amp;quot;:{&amp;amp;quot;message&amp;amp;quot;:&amp;amp;quot;World&amp;amp;quot;},&amp;amp;quot;component_name&amp;amp;quot;:&amp;amp;quot;Hello&amp;amp;quot;,&amp;amp;quot;controller&amp;amp;quot;:&amp;amp;quot;Home&amp;amp;quot;}"&lt;/span&gt;&lt;span class="nt"&gt;&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;div&lt;/span&gt; &lt;span class="na"&gt;data-reactid=&lt;/span&gt;&lt;span class="s"&gt;".3hx9dqn6rk"&lt;/span&gt;
           &lt;span class="na"&gt;data-react-checksum=&lt;/span&gt;&lt;span class="s"&gt;"487927662"&lt;/span&gt;&lt;span class="nt"&gt;&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;h1&lt;/span&gt; &lt;span class="na"&gt;data-reactid=&lt;/span&gt;&lt;span class="s"&gt;".3hx9dqn6rk.0"&lt;/span&gt;&lt;span class="nt"&gt;&amp;gt;&lt;/span&gt;Hello World&lt;span class="nt"&gt;&amp;lt;/h1&amp;gt;&lt;/span&gt;
        &lt;span class="nt"&gt;&amp;lt;button&lt;/span&gt; &lt;span class="na"&gt;data-reactid=&lt;/span&gt;&lt;span class="s"&gt;".3hx9dqn6rk.1"&lt;/span&gt;&lt;span class="nt"&gt;&amp;gt;&lt;/span&gt;Press me&lt;span class="nt"&gt;&amp;lt;/button&amp;gt;&lt;/span&gt;
      &lt;span class="nt"&gt;&amp;lt;/div&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;/div&amp;gt;&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;For &lt;a href="http://localhost:3000/home/isomorphic?no_prerender=1"&gt;&lt;a href="http://localhost:3000/home/isomorphic?no_prerender=1"&gt;http://localhost:3000/home/isomorphic?no_prerender=1&lt;/a&gt;&lt;/a&gt;
there is no prerendering and the rendering is done by the client&lt;/p&gt;
&lt;pre class="highlight html"&gt;&lt;code&gt;    &lt;span class="nt"&gt;&amp;lt;div&lt;/span&gt; &lt;span class="na"&gt;data-react-class=&lt;/span&gt;&lt;span class="s"&gt;"React.TopLevelRailsComponent"&lt;/span&gt;
         &lt;span class="na"&gt;data-react-props=&lt;/span&gt;&lt;span class="s"&gt;"{&amp;amp;quot;render_params&amp;amp;quot;:{&amp;amp;quot;message&amp;amp;quot;:&amp;amp;quot;World&amp;amp;quot;},&amp;amp;quot;component_name&amp;amp;quot;:&amp;amp;quot;Hello&amp;amp;quot;,&amp;amp;quot;controller&amp;amp;quot;:&amp;amp;quot;Home&amp;amp;quot;}"&lt;/span&gt;&lt;span class="nt"&gt;&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;/div&amp;gt;&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;h1 id="rails-conventions-isomorphic-i-e-universal-components-and-the-default-component"&gt;Rails conventions, isomorphic (i.e. universal) components and the &amp;quot;default&amp;quot; component&lt;/h1&gt;

&lt;p&gt;In the Rails tradition of convention over configuration, you can
structure/name your components to match your controllers to support a
&amp;quot;default&amp;quot; component, i.e. a component you do NOT need to specify, for
a controller action. To make a default component for the
&lt;code&gt;HomeController#iso_convention&lt;/code&gt; action, create the following file:&lt;/p&gt;
&lt;pre class="highlight ruby"&gt;&lt;code&gt;    &lt;span class="c1"&gt;# app/views/components/home/iso_convention.rb&lt;/span&gt;
      &lt;span class="k"&gt;module&lt;/span&gt; &lt;span class="nn"&gt;Components&lt;/span&gt;
        &lt;span class="k"&gt;module&lt;/span&gt; &lt;span class="nn"&gt;Home&lt;/span&gt;
          &lt;span class="k"&gt;class&lt;/span&gt; &lt;span class="nc"&gt;IsoConvention&lt;/span&gt;
            &lt;span class="kp"&gt;include&lt;/span&gt; &lt;span class="no"&gt;React&lt;/span&gt;&lt;span class="o"&gt;::&lt;/span&gt;&lt;span class="no"&gt;Component&lt;/span&gt;

            &lt;span class="k"&gt;def&lt;/span&gt; &lt;span class="nf"&gt;render&lt;/span&gt;
              &lt;span class="n"&gt;h1&lt;/span&gt; &lt;span class="p"&gt;{&lt;/span&gt; &lt;span class="s2"&gt;"the message is: &lt;/span&gt;&lt;span class="si"&gt;#{&lt;/span&gt;&lt;span class="n"&gt;params&lt;/span&gt;&lt;span class="p"&gt;[&lt;/span&gt;&lt;span class="ss"&gt;:message&lt;/span&gt;&lt;span class="p"&gt;]&lt;/span&gt;&lt;span class="si"&gt;}&lt;/span&gt;&lt;span class="s2"&gt;"&lt;/span&gt; &lt;span class="p"&gt;}&lt;/span&gt;
            &lt;span class="k"&gt;end&lt;/span&gt;
          &lt;span class="k"&gt;end&lt;/span&gt;
        &lt;span class="k"&gt;end&lt;/span&gt;
      &lt;span class="k"&gt;end&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;We now call &lt;code&gt;render_component()&lt;/code&gt; in the action, passing only the
desired params in the action.  &lt;code&gt;render_component()&lt;/code&gt; will instantiate
the &lt;strong&gt;default&lt;/strong&gt; component.&lt;/p&gt;
&lt;pre class="highlight ruby"&gt;&lt;code&gt;    &lt;span class="k"&gt;class&lt;/span&gt; &lt;span class="nc"&gt;HomeController&lt;/span&gt; &lt;span class="o"&gt;&amp;lt;&lt;/span&gt; &lt;span class="no"&gt;ApplicationController&lt;/span&gt;
      &lt;span class="k"&gt;def&lt;/span&gt; &lt;span class="nf"&gt;iso_convention&lt;/span&gt;
        &lt;span class="n"&gt;render_component&lt;/span&gt; &lt;span class="ss"&gt;message: &lt;/span&gt;&lt;span class="s1"&gt;'World'&lt;/span&gt;
      &lt;span class="k"&gt;end&lt;/span&gt;
    &lt;span class="k"&gt;end&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Browsing &lt;a href="http://localhost:3000/home/iso_convention"&gt;&lt;a href="http://localhost:3000/home/iso_convention"&gt;http://localhost:3000/home/iso_convention&lt;/a&gt;&lt;/a&gt;
will render the &lt;code&gt;Components::Home::IsoConvention&lt;/code&gt; component&lt;/p&gt;

&lt;h1 id="the-component-search-path"&gt;The component search path&lt;/h1&gt;

&lt;p&gt;For consistency, you should stick with the Rails directory and
filename conventions. There is some flexibility in where you can
place components. The search path for isomorphic components in
react.rb is described here: &lt;a href="https://github.com/zetachang/react.rb#changing-the-top-level-component-name-and-search-path"&gt;here&lt;/a&gt; which writes:&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;Changing the top level component name and search path&lt;/p&gt;

&lt;p&gt;You can control the top level component name and search path.&lt;/p&gt;

&lt;p&gt;You can specify the component name explicitly in the
render_component method. render_component &amp;quot;Blatz will search the
for a component class named Blatz regardless of the controller
method.&lt;/p&gt;

&lt;p&gt;Searching for components normally works like this: Given a
controller named &amp;quot;Foo&amp;quot; then the component should be either in the
Components::Foo module, the Components module (no controller -
useful if you have just a couple of shared components) or just the
outer scope (i.e. Module) which is useful for small apps.&lt;/p&gt;

&lt;p&gt;Saying render_component &amp;quot;::Blatz&amp;quot; will only search the outer scope,
while &amp;quot;::Foo::Blatz&amp;quot; will look only in the module Foo for a class
named Blatz.&lt;/p&gt;
&lt;/blockquote&gt;

&lt;h1 id="exploring-the-component-search-path"&gt;Exploring the component search path&lt;/h1&gt;

&lt;p&gt;Let&amp;#39;s play around with several components that have the same class name and
see how the search path resolves which component to use.  Create the
file below:&lt;/p&gt;

&lt;p&gt;&lt;code&gt;app/views/components/search_path.rb&lt;/code&gt;&lt;/p&gt;
&lt;pre class="highlight ruby"&gt;&lt;code&gt;      &lt;span class="c1"&gt;# This class departs from 1 class/file and diretory&lt;/span&gt;
      &lt;span class="c1"&gt;# structure/convention, using this to test search path&lt;/span&gt;

    &lt;span class="k"&gt;class&lt;/span&gt; &lt;span class="nc"&gt;SearchPath&lt;/span&gt;
      &lt;span class="kp"&gt;include&lt;/span&gt; &lt;span class="no"&gt;React&lt;/span&gt;&lt;span class="o"&gt;::&lt;/span&gt;&lt;span class="no"&gt;Component&lt;/span&gt;
      &lt;span class="k"&gt;def&lt;/span&gt; &lt;span class="nf"&gt;render&lt;/span&gt;
        &lt;span class="n"&gt;h1&lt;/span&gt; &lt;span class="p"&gt;{&lt;/span&gt;&lt;span class="s2"&gt;"::SearchPath"&lt;/span&gt;&lt;span class="p"&gt;}&lt;/span&gt;
      &lt;span class="k"&gt;end&lt;/span&gt;
    &lt;span class="k"&gt;end&lt;/span&gt;

    &lt;span class="k"&gt;module&lt;/span&gt; &lt;span class="nn"&gt;Home&lt;/span&gt;
      &lt;span class="k"&gt;class&lt;/span&gt; &lt;span class="nc"&gt;SearchPath&lt;/span&gt;
        &lt;span class="kp"&gt;include&lt;/span&gt; &lt;span class="no"&gt;React&lt;/span&gt;&lt;span class="o"&gt;::&lt;/span&gt;&lt;span class="no"&gt;Component&lt;/span&gt;
        &lt;span class="k"&gt;def&lt;/span&gt; &lt;span class="nf"&gt;render&lt;/span&gt;
          &lt;span class="n"&gt;h1&lt;/span&gt; &lt;span class="p"&gt;{&lt;/span&gt;&lt;span class="s2"&gt;"Home::SearchPath"&lt;/span&gt;&lt;span class="p"&gt;}&lt;/span&gt;
        &lt;span class="k"&gt;end&lt;/span&gt;
      &lt;span class="k"&gt;end&lt;/span&gt;
    &lt;span class="k"&gt;end&lt;/span&gt;

    &lt;span class="k"&gt;module&lt;/span&gt; &lt;span class="nn"&gt;Components&lt;/span&gt;
      &lt;span class="k"&gt;class&lt;/span&gt; &lt;span class="nc"&gt;SearchPath&lt;/span&gt;
        &lt;span class="kp"&gt;include&lt;/span&gt; &lt;span class="no"&gt;React&lt;/span&gt;&lt;span class="o"&gt;::&lt;/span&gt;&lt;span class="no"&gt;Component&lt;/span&gt;
        &lt;span class="k"&gt;def&lt;/span&gt; &lt;span class="nf"&gt;render&lt;/span&gt;
          &lt;span class="n"&gt;h2&lt;/span&gt; &lt;span class="p"&gt;{&lt;/span&gt; &lt;span class="s1"&gt;'Components::SearchPath'&lt;/span&gt; &lt;span class="p"&gt;}&lt;/span&gt;
        &lt;span class="k"&gt;end&lt;/span&gt;
      &lt;span class="k"&gt;end&lt;/span&gt;
    &lt;span class="k"&gt;end&lt;/span&gt;

    &lt;span class="k"&gt;module&lt;/span&gt; &lt;span class="nn"&gt;Components&lt;/span&gt;
      &lt;span class="k"&gt;module&lt;/span&gt; &lt;span class="nn"&gt;Home&lt;/span&gt;
        &lt;span class="k"&gt;class&lt;/span&gt; &lt;span class="nc"&gt;SearchPath&lt;/span&gt;
          &lt;span class="kp"&gt;include&lt;/span&gt; &lt;span class="no"&gt;React&lt;/span&gt;&lt;span class="o"&gt;::&lt;/span&gt;&lt;span class="no"&gt;Component&lt;/span&gt;
          &lt;span class="k"&gt;def&lt;/span&gt; &lt;span class="nf"&gt;render&lt;/span&gt;
            &lt;span class="n"&gt;h2&lt;/span&gt; &lt;span class="p"&gt;{&lt;/span&gt; &lt;span class="s1"&gt;'Components::Home::SearchPath'&lt;/span&gt; &lt;span class="p"&gt;}&lt;/span&gt;
          &lt;span class="k"&gt;end&lt;/span&gt;
        &lt;span class="k"&gt;end&lt;/span&gt;
      &lt;span class="k"&gt;end&lt;/span&gt;
    &lt;span class="k"&gt;end&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;To render the &amp;quot;default&amp;quot; component, we can just call &lt;code&gt;render_component()&lt;/code&gt;:&lt;/p&gt;
&lt;pre class="highlight ruby"&gt;&lt;code&gt;    &lt;span class="k"&gt;class&lt;/span&gt; &lt;span class="nc"&gt;HomeController&lt;/span&gt; &lt;span class="o"&gt;&amp;lt;&lt;/span&gt; &lt;span class="no"&gt;ApplicationController&lt;/span&gt;
      &lt;span class="k"&gt;def&lt;/span&gt; &lt;span class="nf"&gt;search_path&lt;/span&gt;
        &lt;span class="n"&gt;render_component&lt;/span&gt;
      &lt;span class="k"&gt;end&lt;/span&gt;
    &lt;span class="k"&gt;end&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Hitting &lt;a href="http://localhost:3000/home/search_path"&gt;&lt;a href="http://localhost:3000/home/search_path"&gt;http://localhost:3000/home/search_path&lt;/a&gt;&lt;/a&gt; the component rendered
&lt;code&gt;Home::SearchPath&lt;/code&gt; as evidenced by the text in the H1 element.&lt;/p&gt;

&lt;p&gt;Specifying the component by unqualified class name in &lt;code&gt;render_component()&lt;/code&gt;, yields the same result: &lt;code&gt;Home::SearchPath=&lt;/code&gt;&lt;/p&gt;
&lt;pre class="highlight ruby"&gt;&lt;code&gt;    &lt;span class="k"&gt;class&lt;/span&gt; &lt;span class="nc"&gt;HomeController&lt;/span&gt; &lt;span class="o"&gt;&amp;lt;&lt;/span&gt; &lt;span class="no"&gt;ApplicationController&lt;/span&gt;
      &lt;span class="k"&gt;def&lt;/span&gt; &lt;span class="nf"&gt;search_path&lt;/span&gt;
        &lt;span class="n"&gt;render_component&lt;/span&gt; &lt;span class="s2"&gt;"SearchPath"&lt;/span&gt;
      &lt;span class="k"&gt;end&lt;/span&gt;
    &lt;span class="k"&gt;end&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;We can explore what will be found next the search path by changing the
found component&amp;#39;s name to &lt;code&gt;SearchPath1&lt;/code&gt;, and then refreshing
&lt;a href="http://localhost:3000/home/search_path"&gt;http://localhost:3000/home/search_path&lt;/a&gt; to see which component is
found.  Doing this for each found component gets the following
results:&lt;/p&gt;

&lt;table style='border:2px black; borderspacing: 4px; ' cellspacing="0" cellpadding="6" rules="groups" frame="hsides"&gt;


&lt;colgroup&gt;
&lt;col  class="org-left" /&gt;

&lt;col  class="org-left" /&gt;
&lt;/colgroup&gt;
&lt;thead&gt;
&lt;tr style='border:2px solid black; padding: 4px; '&gt;
&lt;th style='border:2px solid black; padding: 4px; 'scope="col" class="org-left"&gt;Class name changed from SearchPath&lt;/th&gt;
&lt;th style='border:2px solid black; padding: 4px; 'scope="col" class="org-left"&gt;Component Rendered by search path&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;

&lt;tbody&gt;
&lt;tr style='border:2px solid black; padding: 4px; '&gt;
&lt;td style='border:2px solid black; padding: 4px; 'class="org-left"&gt;none&lt;/td&gt;
&lt;td style='border:2px solid black; padding: 4px; 'class="org-left"&gt;Home::SearchPath&lt;/td&gt;
&lt;/tr&gt;


&lt;tr style='border:2px solid black; padding: 4px; '&gt;
&lt;td style='border:2px solid black; padding: 4px; 'class="org-left"&gt;Home::SearchPath&lt;/td&gt;
&lt;td style='border:2px solid black; padding: 4px; 'class="org-left"&gt;Components::Home::SearchPath&lt;/td&gt;
&lt;/tr&gt;


&lt;tr style='border:2px solid black; padding: 4px; '&gt;
&lt;td style='border:2px solid black; padding: 4px; 'class="org-left"&gt;Components::Home::SearchPath&lt;/td&gt;
&lt;td style='border:2px solid black; padding: 4px; 'class="org-left"&gt;::SearchPath&lt;/td&gt;
&lt;/tr&gt;


&lt;tr style='border:2px solid black; padding: 4px; '&gt;
&lt;td style='border:2px solid black; padding: 4px; 'class="org-left"&gt;::SearchPath&lt;/td&gt;
&lt;td style='border:2px solid black; padding: 4px; 'class="org-left"&gt;Components::SearchPath&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;

&lt;p&gt;If we rename all the &lt;code&gt;SearchPath1&lt;/code&gt; classes back to &lt;code&gt;SearchPath&lt;/code&gt;, we
can force the search path to find our desired component by specifying
the full namespace in the &lt;code&gt;render_component()&lt;/code&gt; call&lt;/p&gt;
&lt;pre class="highlight ruby"&gt;&lt;code&gt;    &lt;span class="k"&gt;class&lt;/span&gt; &lt;span class="nc"&gt;HomeController&lt;/span&gt; &lt;span class="o"&gt;&amp;lt;&lt;/span&gt; &lt;span class="no"&gt;ApplicationController&lt;/span&gt;
      &lt;span class="k"&gt;def&lt;/span&gt; &lt;span class="nf"&gt;search_path&lt;/span&gt;
        &lt;span class="n"&gt;render_component&lt;/span&gt; &lt;span class="s2"&gt;"SearchPath"&lt;/span&gt;
        &lt;span class="c1"&gt;# render_component "Components::SearchPath"&lt;/span&gt;
        &lt;span class="c1"&gt;# render_component "Components::Home::SearchPath"&lt;/span&gt;
        &lt;span class="c1"&gt;# render_component "Home::SearchPath"&lt;/span&gt;
        &lt;span class="c1"&gt;# render_component "::SearchPath"&lt;/span&gt;
      &lt;span class="k"&gt;end&lt;/span&gt;
    &lt;span class="k"&gt;end&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;h1 id="directory-conventions-for-react-rails-opal-and-react-rb"&gt;Directory conventions for react-rails, Opal and react.rb&lt;/h1&gt;

&lt;p&gt;The &lt;strong&gt;react-rails&lt;/strong&gt; Javascript component generators create react.js
components in the &lt;code&gt;app/assets/javascripts/components&lt;/code&gt; directory.  This
makes sense, esp. since Rails out of the box does NOT support
isomorphic code and views; hence this directoy is a logical and
&amp;quot;Rails-like&amp;quot; place for Javascript to go.  Similarly, if you are just
using opal-rails and not not react.rb, then by convention, your &lt;code&gt;Opal&lt;/code&gt;
code will be placed under &lt;code&gt;app/assets/javascripts&lt;/code&gt; where the asset
pipeline knows how to find and transpile the &lt;code&gt;Opal&lt;/code&gt; files to Javascript.
React.rb challenges these directory conventions.  As react.js is often
called the &lt;strong&gt;V&lt;/strong&gt; of &lt;strong&gt;MVC&lt;/strong&gt;, then it makes sense for react.rb components
to live under the &lt;code&gt;app/views/components&lt;/code&gt; directory, esp. as they can
also be rendered on the server.  React.rb is young, and conventions
may change, but at the momemnt this is the prescribed convention.&lt;/p&gt;

&lt;p&gt;You can create react.rb components more in line with react-rails and
Opal conventions by placing them somewhere under the
&lt;code&gt;app/assets/javascripts&lt;/code&gt; directory. The Opal files will be found by
Rails anywhere that the asset pipeline is configured to find
javascript files for both server and client rendering, but I would
recommend a structure similar to how react-rails, i.e. in
&lt;code&gt;app/assets/javascripts/components&lt;/code&gt; to make them easy to find.&lt;/p&gt;

&lt;p&gt;Let&amp;#39;s put the &amp;quot;client side only&amp;quot; component into
&lt;code&gt;app/assets/javascripts&lt;/code&gt;. Since Opal will find the file anywhere the
asset pipeline knows to look, this would be more for organizational
conventions rather than a configuration necessary to make it work.&lt;/p&gt;
&lt;pre class="highlight ruby"&gt;&lt;code&gt;    &lt;span class="c1"&gt;# app/assets/javascripts/components/client_only.rb&lt;/span&gt;
    &lt;span class="k"&gt;class&lt;/span&gt; &lt;span class="nc"&gt;ClientOnly&lt;/span&gt;
      &lt;span class="kp"&gt;include&lt;/span&gt; &lt;span class="no"&gt;React&lt;/span&gt;&lt;span class="o"&gt;::&lt;/span&gt;&lt;span class="no"&gt;Component&lt;/span&gt;
      &lt;span class="n"&gt;required_param&lt;/span&gt; &lt;span class="ss"&gt;:message&lt;/span&gt;&lt;span class="p"&gt;,&lt;/span&gt; &lt;span class="ss"&gt;type: &lt;/span&gt;&lt;span class="no"&gt;String&lt;/span&gt;

      &lt;span class="k"&gt;def&lt;/span&gt; &lt;span class="nf"&gt;render&lt;/span&gt;
        &lt;span class="n"&gt;h1&lt;/span&gt; &lt;span class="p"&gt;{&lt;/span&gt; &lt;span class="s2"&gt;"Client only: &lt;/span&gt;&lt;span class="si"&gt;#{&lt;/span&gt;&lt;span class="n"&gt;params&lt;/span&gt;&lt;span class="p"&gt;[&lt;/span&gt;&lt;span class="ss"&gt;:message&lt;/span&gt;&lt;span class="p"&gt;]&lt;/span&gt;&lt;span class="si"&gt;}&lt;/span&gt;&lt;span class="s2"&gt;"&lt;/span&gt; &lt;span class="p"&gt;}&lt;/span&gt;
      &lt;span class="k"&gt;end&lt;/span&gt;
    &lt;span class="k"&gt;end&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Then in the template for the &lt;code&gt;client_only&lt;/code&gt; action , you can render the
component client side via the &lt;code&gt;react_component()&lt;/code&gt; view helper provided
by react-rails. Since react.rb wraps calls to react.js, the components
become react.js components.&lt;/p&gt;
&lt;pre class="highlight html"&gt;&lt;code&gt;    &lt;span class="nt"&gt;&amp;lt;h1&amp;gt;&lt;/span&gt;Home#client_only&lt;span class="nt"&gt;&amp;lt;/h1&amp;gt;&lt;/span&gt;
    &lt;span class="nt"&gt;&amp;lt;p&amp;gt;&lt;/span&gt;Find me in app/views/home/client_only.html.erb&lt;span class="nt"&gt;&amp;lt;/p&amp;gt;&lt;/span&gt;
    &lt;span class="err"&gt;&amp;lt;&lt;/span&gt;%= react_component 'ClientOnly', message: 'World' %&amp;gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;h1 id="thats-all-for-now"&gt;That&amp;#39;s all for now.&lt;/h1&gt;

&lt;p&gt;So now you have a Rails project with react.rb running with several
examples of react.rb components. All of this code exists in a rails
project
&lt;a href="https://github.com/fkchang/getting-started-react-rails"&gt;here.&lt;/a&gt; This
should be enough to get one started.  Enjoy react.rb and Rails!&lt;/p&gt;

&lt;h2 class="footnotes"&gt;Footnotes: &lt;/h2&gt;

&lt;div class="footdef"&gt;&lt;sup&gt;&lt;a id="fn.1" class="footnum" href="#fnr.1"&gt;1&lt;/a&gt;&lt;/sup&gt; &lt;div class="footpara"&gt;reactive-ruby will fold back into react.rb with the 0.9.0 versions (currently at 0.7.36).  Plans are discussed in the react.rb [roadmap](https://github.com/zetachang/react.rb#road-map)&lt;/div&gt;&lt;/div&gt;

&lt;div class="footdef"&gt;&lt;sup&gt;&lt;a id="fn.2" class="footnum" href="#fnr.2"&gt;2&lt;/a&gt;&lt;/sup&gt;
    &lt;div class="footpara"&gt;A change was made starting with Opal 0.8.\*, to support ordered
requires. If one wishes to continue to use application.js instead
application.rb, one needs to manually load each opal file in the
application.js, as below.  Use of application.rb will automatically load the files in question
&lt;/div&gt;&lt;/div&gt;
&lt;pre class="highlight javascript"&gt;&lt;code&gt;&lt;span class="c1"&gt;// application.js&lt;/span&gt;
&lt;span class="c1"&gt;//= require opal&lt;/span&gt;
&lt;span class="c1"&gt;//= require greeter&lt;/span&gt;
&lt;span class="c1"&gt;//= require_self&lt;/span&gt;
&lt;span class="nx"&gt;Opal&lt;/span&gt;&lt;span class="p"&gt;.&lt;/span&gt;&lt;span class="nx"&gt;load&lt;/span&gt;&lt;span class="p"&gt;(&lt;/span&gt;&lt;span class="s1"&gt;'greeter'&lt;/span&gt;&lt;span class="p"&gt;);&lt;/span&gt; &lt;span class="c1"&gt;// you have to load the opal file&lt;/span&gt;
&lt;span class="c1"&gt;// etc.&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;
&lt;div class="footdef"&gt;&lt;sup&gt;&lt;a id="fn.3" class="footnum" href="#fnr.3"&gt;3&lt;/a&gt;&lt;/sup&gt; &lt;div class="footpara"&gt;While the pattern is that universal will be taking the place of isomorphic, I will use the term isomorphic here because the react.rb docs refer to it as isomorphic&lt;/div&gt;&lt;/div&gt;
</content>
  </entry>
</feed>