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 Reactrb. We are sad to see the "dot" go, but this way the name is consistent everywhere, twitter handle, domain name, github org name, etc.

Within the github org we will use the reactb prefix for all gems and repos unless it really doesn't make sense. So you will find in the repo:

  • reactrb-express (formerly inline-reactive-ruby)
  • reactrb-examples (looking help here to clean these up...)
  • reactrb-router (formerly reactive-router)
  • reactrb-rails-generator (formerly reactiverailsgenerator)

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.

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:

You Pick Your React Version

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!

Reactrb is now tested with React V13-V15, and by default does not include any version when you require 'reactrb'.

This gives you at least three ways to include React source into your assets:

  1. If you are using Webpack or another Javascript dependency manager, then let the Javascript tool chain work out which version to use.

    Just make sure that you include both react and react-dom as Reactrb needs both.

  2. If you are using the react-rails gem then do a require 'react' just before you do a require 'reactrb' in your components.rb file.

    This will load the version compatible with react-rails.

  3. If you are using react-rails and a Javascript dependency manager, then check here for the version that react-rails wants, and include that version explicitly with npm or whatever tool you are using on the JS side.

    This will let the JS tool chain manage the dependencies, but insure you have a compatible version for react-rails.

  4. Otherwise Reactrb includes (but does not require) several versions of react source. Just add require 'react-latest' right above wherever you do a require 'hyper-react'.

    If you want another version do require 'react-v14' or require 'react-v13'

Better Native Imports

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 NativeLibrary class to work.

We wanted to keep NativeLibrary as strictly the mechanism that imports libraries of components, and so we added the imports directive to React::Component.

So now you can say:

class Griddle << React::Component::Base
  imports 'Griddle'

Now once you install the the Griddle Javascript component you can use Griddle like any other HyperReact component.

But wait there's more...

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.

To keep things easy, you can opt in to auto-import by simply adding require 'hyper-react/auto-import' after you require hyper-react.

With auto-importing enabled a component like Griddle or a library like ReactBootstrap will automatically be available to your HyperReact components.

See Using Javascript Components for more details.

Render Call back

Up till now we have been defining the render method as just that an instance method in your component class. That'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.

  1. Render methods are too large: Even using helper methods to keep things small, render methods often exceed the normal 10 line ruby style guide recommendation.

    That is not a problem in itself - after all recommendations are just that. However if you are using tools like RuboCop, then it'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.

    By allowing render to be defined as a call back, you get rid of this problem.

  2. Get Rid of Boiler Plate: 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.

  3. Consistency: All the other lifecycle methods are defined as callbacks, so its nice to have render fit in.

Meanwhile the Element[...].render 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 Element['#top-level'].render App.

This is not a big deal but I think you should try it out, and see if it doesn't lead to more readable components.

CAPS Tag Names

Its been suggested that especially for beginners its a little hard to parse the DSL. You don't know which method is what, and its hard to tell the difference between tags like select 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.

It was a small thing, so we went ahead and added it. Tell us what you think!