For developers to setup the basic authentication flow in Rails application, we have to do lot of manual configurations.New developers and small projects teams don’t even need major authentication related feature. But they still need to rely on third party gems or write the whole codebase of the authentication flow from scratch, which is time consuming.Rails has built in generators(eg: model, migration) for different features to avoid manaul coding and configurations. These generators allow developers to focus on building the core features of their application, rather than spending time on basic setup tasks.Authentication generatorRails 8 introduced the basic authentication generator which will add the required codebase for the basic auth flow setup in a Rails application.To add basic authentication to the app, we can use the following authentication generator command:bin/rails generate authenticationIt generates the following files with the necessary configurations. Here is the gist of

Bin folderIn a Rails application, the bin/ folder contains executable scripts that help manage the application. These scripts are generated when we create a new Rails project and ensure that commands like rails, rake, and bundle use the correct environment and gem versions defined in the Gemfile.lock.Example:bin/rails – Runs Rails commands.bin/rake – Runs Rake tasks.bin/setup – Prepares the app for development.Basically, Rails encourages us to use bin/rails rather than just rails because that loads the rails executable from within the bin/ subfolder of our app, ensuring we get the correct version. If we run rails all by itself, that could run any rails executable anywhere on our hard drive.Run bin/rails s instead of rails s to run the server.bin/bundle ensures that the correct version of Bundler is used in our Rails application when running commands like bin/rails s.BeforePreviously, when we created a new Rails app using:rails new myappIt generated a bin/bundle file that activated the

React 19 makes ref easier – just pass it!React 19 brings many exciting updates, and one of the simplest yet powerful change is how ref works. We no longer need forwardRef when passing ref to built-in elements like inputs. Cool, right?This small update makes working with ref much simpler, especially in forms where smooth user interactions matter.The problem with forwardRefBefore React 19, if a parent component wanted to interact with a child component using a ref, we had to wrap the child in forwardRef. Annoying, right?It made the code harder to read and maintain, especially in large projects.Thankfully, React 19 makes ref handling much easier.Let’s check out why ref became smarter than before with an example!Understanding the change with a pizza exampleImagine we have a Pizza Order form with reusable components for selecting pizza type and size. Now, what if selecting a pizza automatically moves the cursor to the size selection field? That would make ordering even smoother, right?Befor

ActionCable integrates websockets with our app which allows two-way communication between the server and client without the need for continuous page refreshes, making real-time updates possible.Channels are similar to controllers in that we define methods for broadcasting or streaming data to connected clients.BeforeBy default, Rails would create a channels folder in the app/ directory to store these channel definitions, allowing developers to easily set up real-time features.# Before Rails 8 when we generate rails new app# Rails app folder structure/app /assets /channels /controllers /helpers /javascript /jobs /mailers /models /viewsAfterRails 8 now removes channels from default app/ structure when we generate new app with rails new command.Now that Hotwire is the default in Rails, this change drops the channels folder from default app/ structure.# Rails app folder structure looks like/app /assets /controllers /helpers /javascript /jobs /mailers /models /viewsThe folder still gets cre

When we work with user input, we want to sanitaize the data shared by user. Sometimes we want to format the data before saving it to the database(eg: downcase emails).Normalization allows us to keep the data clean, consistent and predictable. We can format the data before saving it to the database or further processing.For example, imagine a user signing up with [email protected] and another with [email protected]. Without downcasing these emails, even though they’re the same but system treats them as different emails. We can normalize the email format before saving it to the database.BeforeRails 7.1 introduced ActiveRecord::Base::Normalization, we can specify unique normalization rules for model attributes. When an attribute is assigned or changed, normalization is applied, and the normalised value is stored in the database.The normalizes(*names, with:, apply_to_nil: false) method takes name of the attribute and a block that defines the normalization logic.options:with -> Any callable

When we are running Rails migrations,it’s common to combine multiple changes into a singlechange_table block especially when we want to keep database schema in sync.Before Rails 7.1Previously thevalidate_constraint andvalidate_check_constraint was called outside of thechange_table block to check constraint and its validations into two distinct stepsFor example:class AddNameColumnsAndConstraintToUser < ActiveRecord::Migration[7.0] def change change_table :user, bulk: true do |t| t.string :first_name t.string :last_name t.check_constraint "first_name IS NOT NULL AND last_name IS NOT NULL", name: "name_not_null", validate: false end validate_check_constraint :user, "name_not_null" endendAfterRails 7.1 addedthe enhancement,we can now write cleaner migrations by combining column additionsand constraint validations within a single change_table block.def validate_constraint(*args) @base.validate_constraint(name, *args)enddef validate_check_constraint(*args) @base.validate_check_constraint(nam

ParametersThe data sent with incoming request is known as parameters. The parameters in Rails can be found in the params hash and include:Path Parameters: Embedded in the URL, e.g., /posts/:id.Query String Parameters: Added to the URL, e.g., /posts?title=rails.Form Data: Submitted via forms using POST requests.JSON Data: In APIs where the request body contains JSON.Unlike a plain Ruby hash, the params hash is an ActionController::Parameters object which treats symbols (e.g., :key) and strings (e.g., "key") as equivalent keys.Strong ParametersStrong parameters allow us to explicitly permit and require specific attributes in the controller, preventing mass assignment vulnerabilities.We can manually filter parameters:class PostsController < ApplicationController def create @post = Post.create( title: params[:title], content: params[:content] ) endendTestcase: params = { title: "Welcome to Rails", content: "Deep dive into rails...", published: true }Output: { title: "Welcome to Rails", con

In Rails there is no official way to organize one-off scripts. Unlike recurring tasks, which are automated or scheduled to run at regular intervals (e.g., cron jobs or background workers), these scripts are standalone, ad-hoc scripts that are intended to be run only once or on rare occasions.BeforeBefore Rails 8, managing one-off or custom scripts was often chaotic because there was no dedicated folder for scripts that didn’t fit standard Rake tasks or background jobs. This lack of organization made it harder to keep track of these scripts.As a result, we had to create our own ad-hoc methods for storing and running these scripts. This lead to inconsistent and cluttered solutions.Sometime developers use the bin/ folder but it is primarily for system-level scripts and placing project-specific scripts here often led to confusion.Developers would create custom folders like scripts/, utils/, or tasks/ to store these custom files. While this worked, it caused inconsistency across different R

The TimeWithZone is a Time-like class that can represent a time in any time zone. It is necessary because standard Ruby Time instances are limited to UTC and the system’s ENV['TZ'] zone.TimeWithZone instances implement the same API as Ruby Time instances, so that Time and TimeWithZone instances are interchangeable.TimeWithZone#inspect Returns a string of the object’s date, time, zone, and offset from UTC.BeforeTimeWithZone#inspect used an RFC822-inspired format for displaying timestamps. For instance:Time.zone.now.inspect#=> "Mon, 30 Sep 2024 05:04:48.516544000 UTC +00:00"This format is readable but lacks consistency with Ruby’s internal Time#inspect, which follows the ISO 8601 standard.AfterRails 8 now uses ISO 8601 style time for TimeWithZone#inspect method like Time#inspectTime.zone.now.inspect#=> 2024-09-30 10:37:27.675403 +0530 The update to TimeWithZone#inspect aligns Rails with Ruby standards, ensuring time formatting consistency across the board.

It’s official, Ruby 3.4 first release is available, bringing a wave of excitement to the Ruby community.In this blog, we will go through the latest features, enhancements, and bugfixes introduced in the Ruby 3.4Prism is the new default parserRuby 3.4 switches the default parser from parse.y to Prism, which was introduced in Ruby 3.3 as a new parser designed for better maintainability, error tolerance, and performance.To use the conventional parser, use the command-line argument --parser=parse.y. Feature #20564.Garbage CollectionRuby 3.4 introduced several notable features and enhancements related to its garbage collection (GC) system, aimed at improving performance and flexibility. Here are the key updatesRuby 3.4 allows us to dynamically load different GC implementations. Enable it by configuring Ruby with --with-modular-gc at build time and load GC libraries at runtime with the RUBY_GC_LIBRARY environment variable. Feature #20351.The default GC is now separated into its own library,