Webpacker 3.0 released

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

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.

DateTime, Timestamp, Time and Date in Rails

Learn about key differenece between DateTime, Timestamp, Time and Date in Rails
31 October 2017   593

The difference between different date/time formats in ActiveRecord have little to do with Rails and everything to do with whatever database you're using.

Using MySQL as an example (if for no other reason because it's most popular), you have DATEDATETIMETIME and TIMESTAMP column data types; just as you have CHARVARCHARFLOATand INTEGER.

So, main differences: DATE only stores a date, TIME only stores a time of day, while DATETIME stores both.

The difference between DATETIME and TIMESTAMP is a bit more subtle: DATETIME is formatted as YYYY-MM-DD HH:MM:SS. Valid ranges go from the year 1000 to the year 9999 and everything in between. While TIMESTAMP looks similar when you fetch it from the database, it's really a just a front for a unix timestamp. Its valid range goes from 1970 to 2038. The difference here, aside from the various built-in functions within the database engine, is storage space. Because DATETIMEstores every digit in the year, month day, hour, minute and second, it uses up a total of 8 bytes. As TIMESTAMP only stores the number of seconds since 1970-01-01, it uses 4 bytes.

You can read more about the differences between time formats in MySQL here.

In the end, it comes down to what you need your date/time column to do. Do you need to store dates and times before 1970 or after 2038? Use DATETIME. Do you need to worry about database size and you're within that timerange? Use TIMESTAMP. Do you only need to store a date? Use DATE. Do you only need to store a time? Use TIME.

Having said all of this, Rails actually makes some of these decisions for you. Both :timestamp and :datetime will default to DATETIME, while :date and :time corresponds to DATE and TIME, respectively.