How to share Rails i18n messages with React through webpack

Very specific title hu? This time I’m here for sharing a solution for a specific problem I encountered a couple of days ago.

There’s this existing Rails monolithic application. Team and customer decided that time had come for this app to be decoupled in two components: Rails would do its usual work as an administration and API backend, while React would be used for the frontend component. Everything related to the frontend would then be rewritten, keeping the same behaviour and visual design. But there are a lot of translations related to the user experience and that have now to be included in the javascript bundle, while they were before used by the server.

To do so, I was aiming to write a webpack plugin that could give access to the Rails yml translations. Then I discovered the Virtual Module Plugin: During webpack compilation this plugin injects a fake file containing the given text.

Working on it led me to an extension that flattens and joins the various translations, providing them to javascript source files without duplicating data: a Rails Translations Plugin. In our case we didn’t even want to share ALL translations between Rails and React, but just a frontend.yml file (that stores messages related to the user experience), so the resulting webpack.config.js is:

// app/frontend/webpack.config.js

const clientApp = path.resolve(__dirname, 'app');
const webpackConfig = {
  entry: [path.join(clientApp, 'index.js')],
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'bundle.js'
  },
  plugins: [
    new RailsTranslationsPlugin({
      root       : clientApp,
      localesPath: path.resolve(__dirname, '../backend/config/locales'),
      pattern    : '**/frontend.yml'
    })
  ],
  module: {
    loaders: [
      {
        include : clientApp,
        test    : /\.(js|jsx|es6)$/,
        loader  : 'babel-loader'
      },
      {
        include : clientApp,
        test    : /\.json$/,
        loader  : 'json-loader'
      }
    ]
  }
};

And this allowed us to use them in ReactIntl:

// app/context.jsx
// ...
import { addLocaleData } from 'react-intl';
import translations from 'translations.json';

for (let locale of Object.keys(translations)) {
  addLocaleData(require(`react-intl/locale-data/${locale}`));
}

const locale   = navigator.language || 'en';
const messages = translations[locale];

return (
  <IntlProvider locale={locale} key={locale} messages={messages}>
    <App />
  </IntlProvider>
)

The only downside is that React Intl is not able, obviously, to work with Rails localization formats, and in fact we needed to iterate over the various locales and require its additional data needed for localization (look at the addLocaleData method in the above snippet). I’m now thinking of improving this plugin adding builtin methods that work like Rails’s I18n.t and I18n.l.

How to: Preview a resource in an iframe

Let’s say I have a form to create/edit a resource. On a side of this form I want to show a live preview of my resource. Whenever the form changes I need to update the preview.

At a first glance the solution seems pretty easy, right? Use an IFrame and update the src update on every change. Continue reading “How to: Preview a resource in an iframe”

Continuous delivery with Travis and ECS

ECS is a good product. Sadly it’s authored by the same UX designer that authored all other AWS products, so a lot of people couldn’t even succeed in starting a simple hello world container.

Some months ago @fusillicode wrote a two-part tutorial on how to dockerize and deploy on ECS a WordPress app (you can find them here: part 1 and part 2). Of course, given we’re talking of docker, the technology you’re using is not so important.

What’s missing in those posts is how to do a painless deploy.
Continue reading “Continuous delivery with Travis and ECS”

Ruby builtin Hash

Today I was really debated whether to publish another post about SQL (it was a reflective post on how ORM may have ruined us) and a post about the introspection of a ruby builtin feature.

I hate to be repetitive (the SQL post would have been my third post in a row) and I always find enlightening to study language internals because there you can see the real programming magic. So, why not to post on the Ruby Hash and its lookup complexity of O(1)?

Then I realized there’s plenty of blog posts about the Hash object. And one of these is written so well that I could never compete.

What I really liked of this post is that the author is not only explaining the theory behind Hash, but he also try to reimplement it.

Why do you need Arel?

In my opinion Arel is one of the greatest and most underestimated gems. Of course today Arel is also one of the most used gems because it’s shipped in Rails, but how many people use it actively? And why would they?

Since Rails 3 Arel is the base block of ActiveRecord. Every time you pass a hash to where, it goes through Arel eventually. Rails exposes this with a public API that we can use when we have to write complex queries.
Continue reading “Why do you need Arel?”