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
Reactrb is now tested with React V13-V15, and by default does not include any version when you
This gives you at least three ways to include React source into your assets:
Just make sure that you include both
react-domas Reactrb needs both.
If you are using the react-rails gem then do a
require 'react'just before you do a
require 'reactrb'in your
This will load the version compatible with react-rails.
npmor 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.
Otherwise Reactrb includes (but does not require) several versions of react source. Just add
require 'react-latest'right above wherever you do a
If you want another version do
Better Native Imports
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
So now you can say:
class Griddle << React::Component::Base imports 'Griddle' end
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
With auto-importing enabled a component like
Griddle or a library like
ReactBootstrap will automatically be available to your HyperReact components.
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.
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.
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.
Consistency: All the other lifecycle methods are defined as callbacks, so its nice to have render fit in.
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
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!