Tag Archives: rails

Rails + Webpack + Webpack-Manifest + React + Babel 7 + HMR – [chunkHash]

I’m writing this quick one up so you can save the 1.5 hours that I spent debugging this.

Terms :
HMR – HotModelReload – webpack-dev-server option to trigger browser-auto-refresh when webpack detects filechange (and re-compiles)

Here’s what I’m using :

  • Rails 5.2
  • Webpack-Manifest Gem
  • Yarn
    • Webpack (-cli)
    • Webpack-dev-server
    • @babel/core
    • @babel/preset-react

The issue : When running webpack-dev-server with --hot option (enable HotModelReloading, webpack compile fails with :

ERROR in chunk hello_react [entry]
js/[name]-[contenthash].js
Cannot use [chunkhash] or [contenthash] for chunk in 'js/[name]-[contenthash].js' (use [hash] instead)

Context : With Rails + Webpack-Manifest gem, webpack config is being used from ./config/webpack/environment.js (and it’s named siblings).

This SO discussed the problem and solution
https://stackoverflow.com/questions/50217480/cannot-use-chunkhash-or-contenthash-for-chunk-in-name-chunkhash-js-us
It does not unfortunately tell you very well what to do with

// 4th SO andswer of SO:50217480
output: {
    filename: process.env.production ? `bundle-[chunkHash].js` : `bundle-[hash].js`
}

Luckly, this SO includes a complete webpack.config.js (still not quite where we’re at with webpack-manifest… close.
We’ll notice that output.filename is part of the main config.
I validated this by adding console.log("webpack env", environment) to ./config/webpack/development.js and verifying that, apart from output of virtual-object names, :outputis indeed on the base config object.

SO (THE ANSWER) : edit ./config/webpack/development.js and add : config.output.filename = "js/[name]-[hash].js".

// ./config/webpack/developer.js - at least for my app

process.env.NODE_ENV = process.env.NODE_ENV || 'development'

const environment = require('./environment')

const config = environment.toWebpackConfig();
config.devServer = {
  contentBase: '.',
  host: "localhost",
  port: 3035,
  publicPath: 'http://localhost:3035/',
  historyApiFallback: true,
  proxy: {
    '/packs': { // string to look for proxying requests to api
      target: 'http://localhost:3035', // Path of your rails api server
    },
  },
}
config.output.filename = "js/[name]-[hash].js"

module.exports = config;

Enjoy!

BDD/TDD test cycle for beginners

I sent this message to a RailsMentor Protege of mine :

A couple notes on BDD testing :

1. Never test “the glue”. “Glue” means anything that Ruby or Rails should be doing “automatically”. That means, database querying, sending values from controller to view, etc. So, in a view test, you should be able to adequately test your views using the isolated view tests. This is where you could test that your table-building code is working right as you expect. Your controller tests should be able to be tested without database requests (mocking model instances), see #2.

2. Skinny Controllers, Skinny Views. Make your controller code, and your view usage as absolutely minimal as possible.
The ideal controller method looks like :
def show
respond_with @some_record
end

Yes, THAT SMALL. Rails framework provides a HEAP of assistive methods to accomplish that. #before_filter, #after_filter, #respond_to

Views should contain very little Ruby code. #render :partial and generous use of Helpers allows your view code to be very small (and subsequently, very testable). Repeatable elements like table-rows should be in partials, where they are easily testable.

3. Cucumber-level testing : Are you using Cucumber (http://cukes.info)? Cucumber scripts should really be reserved for “business owner specification”. A business owner would not usually be concerned with error handling or the exact placement (or even widget-type) of elements on the forms. The Business owner instead is interested in knowing that Page A => Page B => Page C works… or for instance, “If I buy product “Widget Sharpener”, then my shopping cart counter increases to 1 ”

There is a general BDD/TDD work cycle :

Create cucumber feature
Code supporting Cucumber step
Cucumber-RED : Cucumber execution fails because step causes failure in model/view/controller
Match expected functionality in model/controller/view RSpec
RSpec-RED : Rspec execution fails because functionality is not implemented
Modify model/view/controller with added functionality
RSpec-GREEN : Rspec now succeeds
Cucumber-GREEN : Cucumber now succeeds

You will often find steps 5-7 (Rspec Red/Green cycle) will repeat several times between Cucumber Red/Green cycles. This is our minute-to-minute Ruby-programmer’s work experience.

I’m looking forward to hearing more from you of your experience learning Ruby and Rails.