Webpacker 3.0 released

New major version of Webpacker for Rails availble now
31 August 2017   764

On 30th of August new major update of Webpacker was released. There are two big changes: 

What's new?

Two major features:  

  • separate process is no longer needed in development
  • the vast majority of the config now lives in the Webpacker npm package, so your config/ directory stays clean and updates are much easier.

Now Webpacker compiles on-demand in development as well as testing. Developers done a lot of work to speed up this process, and for lots of apps, the performance will be increased. But if you have big app or you would lie reloading or hot module replacements, you can still use the bin/webpacker-dev-server. Webpacker will automatically detect if this process is running and start serving packs from there rather than on-demand.

Developers also cut down on the amount of config boilerplate that’s generated in the Rails config/ directory. All the standard stuff is now inside the Webpacker npm module, which makes upgrading so much easier. And you can still overwrite any of the defaults as you please. 

This follows from a large refactoring of the Webpacker internals. Gone are the many individual singletons, replaced by a single top-level singleton that just aggregates a normal set of classes for configuration, compilation, and so on.

Webpacker 3.0 points to what a Webpack-by-default strategy could look like in Rails 6.0. One where the asset pipeline focuses on static assets, like images, fonts, sounds, and compiled CSS, using SASS and so on, but bows out of the JavaScript compilation game. We still haven’t pinned the final approach, but this is our best current take on how the two could split the work-load of dealing with JavaScript, stylesheets, and other assets in the next big Rails release.

How to redirect to 404 page in Rails?

Small tutorial that will help you to redirect user to a "fake" 404 page, using Rails
31 October 2017   655

Rails has this functionality built in already. If you want to show a 404 page, create a render_404 method (or not_found ) in ApplicationController like this:

def not_found
  raise ActionController::RoutingError.new('Not Found')

Rails also handles AbstractController::ActionNotFound, and ActiveRecord::RecordNotFound the same way.

This does two things better:

It uses Rails' built in rescue_from handler to render the 404 page, and 2) it interrupts the execution of your code, letting you do nice things like:

  user = User.find_by_email(params[:email]) or not_found

without having to write ugly conditional statements.

As a bonus, it's also super easy to handle in tests.