Ruby 3.0 – The Rails Drop

Rails 7+ API error handling that scales ⚖️

A solid API error strategy gives you:

Consistent JSON error shapes
Correct HTTP status codes
Separation of concerns (domain vs transport)
Observability without leaking internals

Below is a practical, production-ready approach that covers controller hooks, controllers, models/libs, background jobs, and more—illustrated with a real scenario from Session::CouponCode.

Core principles

Keep transport (HTTP, JSON) in controllers; keep domain logic in models/libs.
Map known, expected failures to specific HTTP statuses.
Log unexpected failures; return a generic message to clients.
Centralize API error rendering in a base controller.

1) A single error boundary for all API controllers

Create a base Error::ApiError and rescue it (plus a safe catch‑all) in your ApiController.

# lib/error/api_error.rb
module Error
  class ApiError < StandardError
    attr_reader :status, :details
    def initialize(message, status = :unprocessable_entity, details: nil)
      super(message)
      @status  = status
      @details = details
    end
  end
end

# app/controllers/api_controller.rb
class ApiController < ActionController::Base
  include LocaleConcern
  skip_forgery_protection

  impersonates :user,
               ......

  # Specific handlers first
  rescue_from Error::ApiError,                          with: :handle_api_error
  rescue_from ActionController::ParameterMissing,       with: :handle_bad_request
  rescue_from ActiveRecord::RecordNotFound,             with: :handle_not_found
  rescue_from ActiveRecord::RecordInvalid,              with: :handle_unprocessable
  rescue_from ActiveRecord::RecordNotUnique,            with: :handle_conflict

  # Catch‑all last
  rescue_from StandardError,                            with: :handle_standard_error

  private

  def handle_api_error(e)
    render json: { success: false, error: e.message, details: e.details }, status: e.status
  end

  def handle_bad_request(e)
    render json: { success: false, error: e.message }, status: :bad_request
  end

  def handle_not_found(_e)
    render json: { success: false, error: 'Not found' }, status: :not_found
  end

  def handle_unprocessable(e)
    render json: { success: false, error: e.record.errors.full_messages }, status: :unprocessable_entity
  end

  def handle_conflict(_e)
    render json: { success: false, error: 'Conflict' }, status: :conflict
  end

  def handle_standard_error(e)
    Rollbar.error(e, path: request.fullpath, client_id: try(:current_client)&.id)
    render json: { success: false, error: 'Something went wrong' }, status: :internal_server_error
  end
end

Order matters. Specific rescue_from before StandardError.
This pattern avoids duplicating rescue_from across controllers and keeps HTML controllers unaffected.

2) Errors in before actions

Because before_action runs inside controllers, the same rescue_from handlers apply.

Two patterns:

Render in the hook for simple guard clauses:

before_action :require_current_client

def require_current_client
  return if current_client
  render json: { success: false, error: 'require_login' }, status: :unauthorized
end

Raise a domain/auth error and let rescue_from handle JSON:

# lib/error/unauthorized_error.rb
module Error
  class UnauthorizedError < Error::ApiError
    def initialize(message = 'require_login') = super(message, :unauthorized)
  end
end

before_action :require_current_client

def require_current_client
  raise Error::UnauthorizedError unless current_client
end

Prefer raising if you want consistent global handling and logging.

3) Errors inside controllers

Use explicit renders for happy-path control flow; raise for domain failures:

def create
  form = CreateThingForm.new(params.require(:thing).permit(:name))
  result = CreateThing.new(form: form).call

  if result.success?
    render json: { success: true, thing: result.thing }, status: :created
  else
    # Known domain failure → raise an ApiError to map to 422
    raise Error::ApiError.new(result.message, :unprocessable_entity, details: result.details)
  end
end

Common controller exceptions (auto-mapped above):

ActionController::ParameterMissing → 400
ActiveRecord::RecordNotFound → 404
ActiveRecord::RecordInvalid → 422
ActiveRecord::RecordNotUnique → 409

4) Errors in models, services, and libs

Do not call render here. Either:

Return a result object (Success/Failure), or
Raise a domain‑specific exception that the controller maps to an HTTP response.

Example from our scenario, Session::CouponCode:

# lib/error/session/coupon_code_error.rb
module Error
  module Session
    class CouponCodeError < Error::ApiError; end
  end
end

# lib/session/coupon_code.rb
class Session::CouponCode
  def discount_dollars
    # ...
    case
    when coupon_code.gift_card?
      # ...
    when coupon_code.discount_code?
      # ...
    when coupon_code.multiorder_discount_code?
      # ...
    else
      raise Error::Session::CouponCodeError, 'Unrecognized discount code'
    end
  end
end

Then, in ApiController, the specific handler (or the Error::ApiError handler) renders JSON with a 422.

This preserves separation: models/libs raise; controllers decide HTTP.

5) Other important surfaces

ActiveJob / Sidekiq
Prefer retry_on, discard_on, and job‑level rescue with logging.
Return no HTTP here; jobs are async.

class MyJob < ApplicationJob
  retry_on Net::OpenTimeout, wait: 10.seconds, attempts: 3
  discard_on Error::ApiError
  rescue_from(StandardError) { |e| Rollbar.error(e) }
end

Mailers
Use rescue_from to avoid bubble‑ups crashing deliveries:

class ApplicationMailer < ActionMailer::Base
  rescue_from Postmark::InactiveRecipientError, Postmark::InvalidEmailRequestError do
    # no-op / log
  end
end

Routing / 404
For APIs, keep 404 mapping at the controller boundary with rescue_from ActiveRecord::RecordNotFound.
For HTML, config.exceptions_app = routes + ErrorsController.
Middleware / Rack
For truly global concerns, use middleware. This is rarely necessary for controller-scoped API errors in Rails.
Validation vs. Exceptions
Use validations (ActiveModel/ActiveRecord) for expected user errors.
Raise exceptions for exceptional conditions (invariants violated, external systems fail unexpectedly).

6) Observability

Always log unexpected errors in the catch‑all (StandardError).
Add minimal context: client_id, request.fullpath, feature flags.
Avoid leaking stack traces or internal messages to clients. Send generic messages on 500s.

7) Testing

Unit test domain services to ensure they raise Error::ApiError (or return Failure).
Controller/request specs: assert status codes and JSON shapes for both happy path and error path.
Ensure before_action guards either render or raise as intended.

Applying this to our scenario

/lib/session/coupon_code.rb raises Error::Session::CouponCodeError on unknown/invalid discount values.
/app/controllers/api_controller.rb rescues that error and returns JSON:
{ success: false, error: e.message } with a 422 (or via Error::ApiError base).

This converts prior 500s into clean API responses and keeps error handling centralized.

When to generalize vs. specialize

Keep a catch‑all rescue_from StandardError in ApiController to prevent 500s from leaking internals.
Still add specific handlers (or subclass Error::ApiError) for known cases to control the correct status code and message.
Do not replace everything with only StandardError—you’ll lose semantics and proper HTTP codes.

—

Key takeaways
Centralize API‐wide error handling in ApiController using specific handlers + a safe catch‑all.
Raise domain errors in models/libs; render JSON only in controllers.
Map common Rails exceptions to correct HTTP statuses; log unexpected errors.
Prefer Error::ApiError as a base for consistent message/status handling across the API.

Rails 8 + ActiveAdmin: The Propshaft vs Sprockets Dilemma 😵‍💫

ActiveAdmin traditionally requires Sprockets, but there are actually several alternatives and modern approaches. Let me break down your options:

ActiveAdmin Asset Pipeline Options:

Current Status (2025):

ActiveAdmin 3.x still primarily designed for Sprockets
It has SCSS files with imports, mixins, and variables that need preprocessing
The gem’s CSS compilation expects Sprockets’ asset compilation pipeline

Alternative Approaches:

1. Keep Sprockets (Current Choice)

Pros:

✅ Fully supported, zero configuration issues
✅ All ActiveAdmin features work out-of-the-box
✅ Stable and well-tested

Cons:

❌ Older, slower asset pipeline
❌ More complex than Propshaft
❌ Goes against Rails 8 defaults

2. Hybrid: Propshaft + Manual CSS for ActiveAdmin

We could try keeping Propshaft for our main app and handling ActiveAdmin CSS manually:

ActiveAdmin traditionally requires Sprockets, but the landscape is evolving. Here are your realistic options in 2025:

Current Situation:

ActiveAdmin 3.x: Requires Sprockets (stable)
ActiveAdmin 4.0 beta: Propshaft support is experimental/problematic
Rails 8 default: 🆕 Propshaft (faster, simpler)

https://github.com/activeadmin/activeadmin/releases

Our Options:

Option 1: Stay with Sprockets ⭐ (Recommended for now)

Pros:

✅ Zero configuration issues
✅ All ActiveAdmin features work perfectly
✅ Battle-tested and stable

Cons:

❌ Slower than Propshaft
❌ More complex asset pipeline
❌ Goes against Rails 8 defaults

Option 2: ActiveAdmin Assets Gem (Simplest alternative)

The activeadmin_assets gem was mentioned as a simple solution! Let me add this option:

# Add to Gemfile
gem 'activeadmin_assets'

Pros:

✅ Zero Node.js dependency
✅ Works with Propshaft
✅ Pre-compiled ActiveAdmin assets
✅ Simple one-line installation

Cons:

❌ Can’t customize ActiveAdmin styles
❌ Community-maintained (not official)

Option 3: ActiveAdmin 4.0 Beta + Propshaft ⚠️ (Experimental)

Based on the GitHub discussions, this is possible but complex:

# Rails 8 setup with Propshaft + ActiveAdmin v4 beta
rails new myapp -a propshaft
bundle add activeadmin -v=4.0.0beta15
bundle add cssbundling-rails -v "1.4.1"
bundle add tailwindcss-ruby -v "~> 3.4.17"
yarn add tailwindcss@^3.4.17  # ActiveAdmin uses TailwindCSS v3
rails generate active_admin:install
rails css:install:tailwind
yarn add @activeadmin/activeadmin@4.0.0-beta15
npm pkg set scripts.build:css="tailwindcss -i ./app/assets/stylesheets/active_admin.css -o ./app/assets/builds/active_admin.css --minify -c tailwind-active_admin.config.js"
./bin/dev  # Instead of rails server

Pros:

✅ Modern asset pipeline (Propshaft)
✅ ActiveAdmin v4 features

Cons:

❌ Complex setup with many steps
❌ Requires Node.js/Yarn (defeats the purpose)
❌ Beta software (unstable)
❌ TailwindCSS v3/v4 compatibility issues

Option 4: 🔄 Alternative Admin Gems

If you want to avoid the ActiveAdmin complexity entirely:

RailsAdmin:

gem 'rails_admin'

✅ No asset pipeline issues
✅ Works with Propshaft out of the box
❌ Less customizable than ActiveAdmin

Trestle:

gem 'trestle'

✅ Modern Bootstrap-based admin
✅ Better Rails 8 compatibility
❌ Smaller community

Adminterface (Deprecated):

🚫 No longer maintained (as shown in search results)

🏆 My Recommendation:

For our production app: Stick with Sprockets + ActiveAdmin 3.x

Why?

Stability – Battle-tested combination
Zero configuration issues
Full feature set available
Easy maintenance

The performance difference between Propshaft and Sprockets won’t significantly impact your admin interface, which is typically used by a small number of internal users.

🔮 Future Outlook:

ActiveAdmin v4 will eventually have better Propshaft support
Rails community is working on solutions
Node.js dependency trend for complex CSS is becoming standard anyway

Bottom Line: Don’t let the asset pipeline take over the application preferences. Our current Sprockets setup is perfectly fine for an admin interface! 🎯

The Reality Check:

We completely replaced Propshaft with Sprockets for the entire application.

Current State:

❌ Propshaft: Completely removed
✅ Sprockets: Handles ALL assets (main app + admin)
✅ Importmaps: Still working (unaffected)
✅ Hotwire/Turbo: Still working (unaffected)

🏗️ How ActiveAdmin Works:

ActiveAdmin is NOT a Rails Engine. It integrates directly into your app:

Routes: ActiveAdmin.routes(self) adds /admin routes to your app
Assets: ActiveAdmin’s CSS/JS becomes part of your asset pipeline
Controllers: ActiveAdmin generates controllers in your app’s namespace

It’s tightly coupled to your application, not isolated.

🤷‍♂️ So What Are Our Real Options?

Option 1: Accept Current Setup

What we have:

Modern Rails 8 with Importmaps + Hotwire ✅
Sprockets instead of Propshaft ❌ (but works fine)
Full-featured admin interface ✅

Option 2: Use activeadmin_assets Gem

# Replace current ActiveAdmin setup
gem 'activeadmin_assets'  # Pre-compiled assets
gem 'propshaft'           # Back to Rails 8 default

✅ Get Propshaft back
✅ Keep Rails 8 defaults
❌ Can’t customize admin styles

Option 3: Build Custom Admin

Keep your Rails 8 purity but build admin from scratch:

✅ Pure Rails 8
❌ Weeks of development time

🔍 What activeadmin_assets Actually Does:

The activeadmin_assets gem doesn’t replace ActiveAdmin – it provides pre-compiled static assets for ActiveAdmin to work with Propshaft.

But here’s the critical issue for you:

🚨 activeadmin_assets = NO Customization

If you use activeadmin_assets, you get:

✅ ActiveAdmin functionality
✅ Propshaft compatibility
❌ ZERO ability to customize styles/interface

The assets are pre-compiled and frozen – you can’t modify colors, layouts, or styling.

Since We Want Customization:

We’re actually in the BEST setup possible right now!

Our Current Setup Gives You:

✅ Full ActiveAdmin customization (styles, layouts, themes)
✅ Modern Rails 8 (Importmaps, Hotwire, Turbo)
✅ All ActiveAdmin features (filters, actions, forms)
❌ Sprockets instead of Propshaft (minor trade-off)

Customization Examples We Can Do:

Custom CSS themes and colors
Layout modifications
Custom JavaScript behaviors
Brand styling and logos
Advanced form customizations

🎯 Reality Check:

There’s no solution that gives us:

Full ActiveAdmin customization AND
Propshaft AND
Zero complexity

We have to pick 2 out of 3.

💡 My Honest Last Decision:

Keep our current setup! We’re already using:

Modern Rails 8 patterns (95% of your codebase)
Importmaps and Hotwire (exactly as intended)
Sprockets only affects asset serving (invisible to users)

The Propshaft vs Sprockets difference won’t affect your product’s success, but losing admin customization will limit our UX.

Guide: Integrating React ⚛️ into a Rails 8 Application – Part 3 | Start developing react

Let’s move on to quick development of more react components now. Before that let’s check what we have now and understand it very clear.

📄 File 1:

Our app/javascript/components/App.jsx file:

import React from 'react';

function App() {
  return (
    <div>
      <h1>React is working fine!</h1>
      <p>Welcome to Rails + React App</p>
    </div>
  );
}

export default App;

Let’s examine this React component step by step:

Line 1: Import React

import React from 'react';

import – ES6 module syntax to bring in external code
React – The main React library
from 'react' – Importing from the npm package named “react”
Why needed? Even though we use --jsx=automatic, we still import React for any hooks or React features we might use.

Function Component: Line 3-9

A React function component is a simple JavaScript function that serves as a building block for user interfaces in React applications. These components are designed to be reusable and self-contained, encapsulating a specific part of the UI and its associated logic.

function App() {
  return (
    <div>
      <h1>React is working fine!</h1>
      <p>Welcome to Rails + React App</p>
    </div>
  );
}

🔍 Breaking this down:

Line 3: Component Declaration

function App() {

function App() – This is a React Function Component
Component naming – Must start with capital letter (App, not app)
What it is – A JavaScript function that returns JSX (user interface)

Line 4-8: JSX Return

return (
  <div>
    <h1>React is working fine!</h1>
    <p>Welcome to Rails + React App</p>
  </div>
);

return – Every React component must return something
JSX – Looks like HTML, but it’s actually JavaScript
<div> – Must have one parent element (React Fragment rule)
<h1> & <p> – Regular HTML elements, but processed by React

Line 11: Export

export default App;

export default – ES6 syntax to make this component available to other files
App – The component name we’re exporting
Why needed? So application.js can import and use this component

📄 File 2:

Our app/javascript/application.js file:

// Entry point for the build script in your package.json
import React from 'react';
import { createRoot } from 'react-dom/client';
import App from './components/App';

document.addEventListener('DOMContentLoaded', () => {
  const container = document.getElementById('react-root');

  if(container) {
    const root = createRoot(container);
    root.render(<App />);
  }
});

This is the entry point that connects React to your Rails app:

Imports: Line 2-4

import React from 'react';
import { createRoot } from 'react-dom/client';
import App from './components/App';

🔍 Breaking down each import:

Line 2:

import React from 'react';

Same as before – importing the React library

Line 3:

import { createRoot } from 'react-dom/client';

{ createRoot } – Named import (notice the curly braces)
react-dom/client – ReactDOM library for browser/DOM manipulation
createRoot – New React 18+ API for rendering components to DOM

Line 4:

import App from './components/App';

App – Default import (no curly braces)
./components/App – Relative path to our App component
Note: We don’t need .jsx extension, esbuild figures it out

DOM Integration: Line 6-12

document.addEventListener('DOMContentLoaded', () => {
  const container = document.getElementById('react-root');

  if(container) {
    const root = createRoot(container);
    root.render(<App />);
  }
});

🔍 Step by step breakdown:

Line 6:

document.addEventListener('DOMContentLoaded', () => {

document.addEventListener – Standard browser API
'DOMContentLoaded' – Wait until HTML is fully loaded
() => { – Arrow function (ES6 syntax)
Why needed? Ensures the HTML exists before React tries to find elements

Line 7:

const container = document.getElementById('react-root');

const container – Create a variable to hold the DOM element
document.getElementById('react-root') – Find HTML element with id="react-root"
Where is it? In your Rails view file: app/views/home/index.html.erb

Line 9:

if(container) {

Safety check – Only proceed if the element exists
Prevents errors – If someone visits a page without react-root element

Line 10-11:

const root = createRoot(container);
root.render(<App />);

createRoot(container) – Create a React “root” at the DOM element
root.render(<App />) – Render our App component inside the container
<App /> – JSX syntax for using our component (self-closing tag)

🎯 Key React Concepts You Just Learned:

1. Components

Functions that return JSX
Must start with capital letter
Reusable pieces of UI

2. JSX

Looks like HTML, actually JavaScript
Must return single parent element
Processed by esbuild into regular JavaScript

3. Import/Export

Default exports: export default App → import App from './App'
Named exports: export { createRoot } → import { createRoot } from 'package'

4. React DOM

createRoot() – Modern way to mount React apps (React 18+)
render() – Display components in the browser

5. Rails Integration

Rails serves the HTML page
React takes over the #react-root element
esbuild bundles everything together

🚀 This pattern is the foundation of every React app! We create components, import them, and render them to the DOM.

📚 Step-by-Step React Learning with Todo List

Now let’s build a Todo List app step by step. I’ll explain each React concept thoroughly as we go. Here’s our learning roadmap:

Step 1: Understanding JSX and Basic Component Structure

First, let’s update our App.jsx to create the basic structure of our Todo app:

import React from 'react';

function App() {
  return (
    <div className="todo-app">
      <h1>My Todo List</h1>
      <p>Let's learn React by building a todo app!</p>

      {/* This is a JSX comment */}
      <div className="todo-container">
        <h2>Add a new todo</h2>
        <input type="text" placeholder="Enter a todo..." />
        <button>Add Todo</button>

        <h2>My Todos</h2>
        <ul>
          <li>Learn React basics</li>
          <li>Build a todo app</li>
          <li>Master React hooks</li>
        </ul>
      </div>
    </div>
  );
}

export default App;

🎯 Key Concepts Explained:

JSX (JavaScript XML):

JSX lets you write HTML-like syntax directly in JavaScript
It’s a syntax extension for JavaScript, not actual HTML
JSX gets compiled to JavaScript function calls
You can use {} to embed JavaScript expressions inside JSX

Important JSX Rules:

Use className instead of class (because class is a reserved word in JavaScript)
You can use single quotes for className values in JSX. Both work perfectly fine:

// Both of these are valid:
<div className='todo-app'>    // Single quotes ✅
<div className="todo-app">    // Double quotes ✅

Quote Usage in JSX/JavaScript:

Single quotes vs Double quotes:

JavaScript treats them identically
It’s mostly a matter of personal/team preference
The key is to be consistent throughout your project

Common conventions:

// Option 1: Single quotes for JSX attributes
<div className='todo-app'>
  <input type='text' placeholder='Enter todo...' />
</div>

// Option 2: Double quotes for JSX attributes  
<div className="todo-app">
  <input type="text" placeholder="Enter todo..." />
</div>

// Option 3: Mixed (but stay consistent within each context)
const message = 'Hello World';  // Single for JS strings
<div className="todo-app">      // Double for JSX attributes

When you MUST use specific quotes:

// When the string contains the same quote type
<div className="It's a great day">        // Double quotes needed
<div className='He said "Hello"'>        // Single quotes needed

// Or use escape characters
<div className='It\'s a great day'>       // Escaping single quote
<div className="He said \"Hello\"">      // Escaping double quote

💡 Tip: Many teams use tools like Prettier or ESLint to automatically format and enforce consistent quote usage across the entire project.

All tags must be closed (self-closing tags need / at the end)
JSX comments use {/* */} syntax
Return a single parent element (or use React Fragment <>...</>)

Try updating our App.jsx with this code and see it in your browser!

Step 2: Introduction to State with `useState`

Now let’s add state to make our app interactive. State is data that can change over time.

import React, { useState } from 'react';

function App() {
  // useState Hook - creates state variable and setter function
  const [todos, setTodos] = useState([
    { id: 1, text: 'Learn React basics', completed: false },
    { id: 2, text: 'Build a todo app', completed: false },
    { id: 3, text: 'Master React hooks', completed: true }
  ]);

  const [inputValue, setInputValue] = useState('');

  return (
    <div className="todo-app">
      <h1>My Todo List</h1>

      <div className="todo-container">
        <h2>Add a new todo</h2>
        <input 
          type="text" 
          placeholder="Enter a todo..." 
          value={inputValue}
          onChange={(e) => setInputValue(e.target.value)}
        />
        <button>Add Todo</button>

        <h2>My Todos ({todos.length})</h2>
        <ul>
          {todos.map(todo => (
            <li key={todo.id}>
              {todo.text} {todo.completed ? '✅' : '⏳'}
            </li>
          ))}
        </ul>
      </div>
    </div>
  );
}

export default App;

🎯 Key Concepts Explained:

useState Hook:

useState is a React Hook that lets you add state to functional components
It returns an array with two elements: [currentValue, setterFunction]
const [todos, setTodos] = useState([]) creates a state variable todos and a function setTodos to update it
The initial value is passed as an argument to useState

Controlled Components:

The input field is now “controlled” by React state
value={inputValue} makes the input show what’s in state
onChange={(e) => setInputValue(e.target.value)} updates state when user types

Array.map() for Rendering Lists:

todos.map() transforms each todo into a JSX element
Each list item needs a unique key prop for React’s optimization
{todo.text} embeds the todo text using JSX expressions

Try this code and notice how the input field now responds to typing!

Step 3: Event Handling and Adding Todos

Let’s make the “Add Todo” button work:

import React, { useState } from 'react';

function App() {
  const [todos, setTodos] = useState([
    { id: 1, text: 'Learn React basics', completed: false },
    { id: 2, text: 'Build a todo app', completed: false },
    { id: 3, text: 'Master React hooks', completed: true }
  ]);

  const [inputValue, setInputValue] = useState('');

  // Function to add a new todo
  const addTodo = () => {
    if (inputValue.trim() !== '') {
      const newTodo = {
        id: Date.now(), // Simple ID generation
        text: inputValue,
        completed: false
      };

      setTodos([...todos, newTodo]); // Spread operator to add new todo
      setInputValue(''); // Clear the input field
    }
  };

  // Function to handle Enter key press
  const handleKeyPress = (e) => {
    if (e.key === 'Enter') {
      addTodo();
    }
  };

  return (
    <div className="todo-app">
      <h1>My Todo List</h1>

      <div className="todo-container">
        <h2>Add a new todo</h2>
        <input 
          type="text" 
          placeholder="Enter a todo..." 
          value={inputValue}
          onChange={(e) => setInputValue(e.target.value)}
          onKeyPress={handleKeyPress}
        />
        <button onClick={addTodo}>Add Todo</button>

        <h2>My Todos ({todos.length})</h2>
        <ul>
          {todos.map(todo => (
            <li key={todo.id}>
              {todo.text} {todo.completed ? '✅' : '⏳'}
            </li>
          ))}
        </ul>
      </div>
    </div>
  );
}

export default App;

🎯 Key Concepts Explained:

Event Handlers:

onClick={addTodo} – function runs when button is clicked
onKeyPress={handleKeyPress} – function runs when key is pressed
Event handlers receive an event object (e) with information about the event

State Updates:

setTodos([...todos, newTodo]) – creates a new array with all existing todos plus the new one
Important: Always create new arrays/objects instead of mutating existing ones
React compares old and new state to determine if re-render is needed

Spread Operator (...):

...todos spreads out all elements of the todos array
This is the React way to add items to an array in state

Try adding new todos now!

🎯 Function Syntax Options in JavaScript:

const addTodo = () => {} is a function syntax – specifically an arrow function. Let me explain why it’s declared as const and the different ways to write functions in JavaScript.

1. Function Declaration (Traditional)

function addTodo() {
  // function body
}

2. Function Expression with Arrow Function

const addTodo = () => {
  // function body
};

3. Function Expression (Traditional)

const addTodo = function() {
  // function body
};

🤔 Why use `const` for functions?

Arrow functions are expressions, not declarations:

// This is a DECLARATION - creates a function named addTodo
function addTodo() { }

// This is an EXPRESSION - creates a function and assigns it to a variable
const addTodo = () => { };

Why `const` specifically?

// ❌ Could be reassigned accidentally
let addTodo = () => { };
addTodo = "oops"; // Function is now gone!

// ❌ Could be reassigned accidentally  
var addTodo = () => { };
addTodo = null; // Function is now gone!

// ✅ Cannot be reassigned - prevents bugs
const addTodo = () => { };
addTodo = "something"; // ERROR: Assignment to constant variable

📚 Key Differences:

Function Declaration vs Arrow Function:

// Function Declaration
function addTodo() {
  console.log("Adding todo");
}

// Arrow Function (assigned to const)
const addTodo = () => {
  console.log("Adding todo");
};

Hoisting Behavior:

// ✅ This works - function declarations are "hoisted"
sayHello(); // "Hello!"

function sayHello() {
  console.log("Hello!");
}

// ❌ This doesn't work - arrow functions are not hoisted
sayGoodbye(); // Error: Cannot access 'sayGoodbye' before initialization

const sayGoodbye = () => {
  console.log("Goodbye!");
};

`this` Binding:

// Function declaration has its own 'this'
function regularFunction() {
  console.log(this); // 'this' can change based on how it's called
}

// Arrow function inherits 'this' from surrounding scope
const arrowFunction = () => {
  console.log(this); // 'this' is inherited from parent scope
};

🚀 In React Context:

In React functional components, we typically use arrow functions with const because:

Prevents accidental reassignment – our function won’t get overwritten
Consistent with modern JavaScript – ES6+ standard
Cleaner syntax – less verbose than traditional function expressions
Better for event handlers – this behavior is more predictable

All these are equivalent in React:

// Option 1: Arrow function with const (most common)
const addTodo = () => {
  if (inputValue.trim() !== '') {
    // ... logic
  }
};

// Option 2: Traditional function declaration
function addTodo() {
  if (inputValue.trim() !== '') {
    // ... logic  
  }
}

// Option 3: Function expression with const
const addTodo = function() {
  if (inputValue.trim() !== '') {
    // ... logic
  }
};

💡 Why React developers prefer arrow functions:

Shorter syntax for simple functions
Consistent variable declaration (everything uses const)
No hoisting confusion – functions are defined before they’re used
Better with modern tooling – ESLint, Prettier handle them well

So yes, const addTodo = () => {} is definitely a function! It’s just a modern way to write functions that prevents accidental reassignment and has cleaner syntax.

🎯 What is Hoisting?

Hoisting is a fundamental JavaScript concept that can be confusing at first. Let me explain it clearly with examples.

Hoisting is JavaScript’s behavior of moving declarations to the top of their scope during the compilation phase, before the code is executed.

Think of it like JavaScript “hoists” (lifts up) your variable and function declarations to the top of their scope.

📚 How Hoisting Works:

Function Declarations are Hoisted:

// This works even though we call the function before declaring it!
sayHello(); // Outputs: "Hello!"

function sayHello() {
  console.log("Hello!");
}

Behind the scenes, JavaScript treats it like this:

// JavaScript internally reorganizes it like this:
function sayHello() {
  console.log("Hello!");
}

sayHello(); // Now it makes sense!

Variable Declarations (with `var`) are Hoisted:

console.log(myVar); // Outputs: undefined (not an error!)
var myVar = "Hello";
console.log(myVar); // Outputs: "Hello"

Behind the scenes:

// JavaScript internally treats it like this:
var myVar; // Declaration is hoisted to the top
console.log(myVar); // undefined (declared but not assigned)
myVar = "Hello"; // Assignment stays in place
console.log(myVar); // "Hello"

🚫 What is NOT Hoisted:

`let` and `const` variables:

// ❌ This throws an error!
console.log(myLet); // ReferenceError: Cannot access 'myLet' before initialization
let myLet = "Hello";

// ❌ This also throws an error!
console.log(myConst); // ReferenceError: Cannot access 'myConst' before initialization
const myConst = "Hello";

Arrow Functions (Function Expressions):

// ❌ This throws an error!
sayGoodbye(); // ReferenceError: Cannot access 'sayGoodbye' before initialization

const sayGoodbye = () => {
  console.log("Goodbye!");
};

Function Expressions:

// ❌ This throws an error!
myFunc(); // TypeError: myFunc is not a function

var myFunc = function() {
  console.log("Hello!");
};

🎭 Visual Examples:

Example 1: Function Declaration Hoisting

// What you write:
console.log("1. Start");
myFunction(); // This works!
console.log("3. End");

function myFunction() {
  console.log("2. Inside function");
}

// Output:
// 1. Start
// 2. Inside function  
// 3. End

Example 2: Variable Hoisting with `var`

// What you write:
console.log("Value is:", myVar); // undefined
var myVar = 42;
console.log("Value is:", myVar); // 42

// What JavaScript internally does:
var myVar; // Hoisted to top
console.log("Value is:", myVar); // undefined
myVar = 42; // Assignment stays here
console.log("Value is:", myVar); // 42

Example 3: Why `let` and `const` are different

// Temporal Dead Zone
console.log("Before declaration");

// ❌ This area is the "Temporal Dead Zone" for myLet
console.log(myLet); // ReferenceError!

let myLet = "Hello"; // Declaration and initialization
console.log(myLet); // "Hello"

🎯 Practical Implications:

Why Function Declarations work everywhere:

// This is valid JavaScript
function main() {
  helper(); // Can call helper before it's defined

  function helper() {
    console.log("Helper function");
  }
}

Why Arrow Functions must be defined first:

// ❌ This doesn't work
const main = () => {
  helper(); // Error! helper is not defined yet

  const helper = () => {
    console.log("Helper function");
  };
};

// ✅ This works
const main = () => {
  const helper = () => {
    console.log("Helper function");
  };

  helper(); // Now it works!
};

💡 Best Practices:

Use const and let instead of var to avoid hoisting confusion
Define functions before using them (even though function declarations are hoisted)
Use arrow functions for consistency and to avoid hoisting surprises
Initialize variables when you declare them

🔗 Back to Our React Example:

// This is why we use const for arrow functions
const App = () => {
  // ✅ Good: Function defined before use
  const addTodo = () => {
    // function logic
  };

  // ❌ Bad: Would cause error if we tried to call it here
  // deleteTodo(); // Error!

  const deleteTodo = () => {
    // function logic
  };

  return (
    <div>
      <button onClick={addTodo}>Add</button>
      <button onClick={deleteTodo}>Delete</button>
    </div>
  );
};

Hoisting is JavaScript’s way of making function declarations available throughout their scope, but it doesn’t apply to modern variable declarations (let, const) or arrow functions. That’s why we define our functions with const and make sure to declare them before we use them!

Step 4: Toggling Todo Completion

Let’s add the ability to mark todos as complete/incomplete:

import React, { useState } from 'react';

function App() {
  const [todos, setTodos] = useState([
    { id: 1, text: 'Learn React basics', completed: false },
    { id: 2, text: 'Build a todo app', completed: false },
    { id: 3, text: 'Master React hooks', completed: true }
  ]);

  const [inputValue, setInputValue] = useState('');

  const addTodo = () => {
    if (inputValue.trim() !== '') {
      const newTodo = {
        id: Date.now(),
        text: inputValue,
        completed: false
      };

      setTodos([...todos, newTodo]);
      setInputValue('');
    }
  };

  // Function to toggle todo completion
  const toggleTodo = (id) => {
    setTodos(todos.map(todo => 
      todo.id === id 
        ? { ...todo, completed: !todo.completed } // Toggle completed status
        : todo // Keep todo unchanged
    ));
  };

  const handleKeyPress = (e) => {
    if (e.key === 'Enter') {
      addTodo();
    }
  };

  return (
    <div className="todo-app">
      <h1>My Todo List</h1>

      <div className="todo-container">
        <h2>Add a new todo</h2>
        <input 
          type="text" 
          placeholder="Enter a todo..." 
          value={inputValue}
          onChange={(e) => setInputValue(e.target.value)}
          onKeyPress={handleKeyPress}
        />
        <button onClick={addTodo}>Add Todo</button>

        <h2>My Todos ({todos.length})</h2>
        <ul>
          {todos.map(todo => (
            <li key={todo.id}>
              <span 
                onClick={() => toggleTodo(todo.id)}
                style={{ 
                  textDecoration: todo.completed ? 'line-through' : 'none',
                  cursor: 'pointer',
                  color: todo.completed ? '#888' : '#000'
                }}
              >
                {todo.text}
              </span>
              {todo.completed ? ' ✅' : ' ⏳'}
            </li>
          ))}
        </ul>
      </div>
    </div>
  );
}

export default App;

🎯 Key Concepts Explained:

Array.map() for Updates:

todos.map() creates a new array where each todo is either updated or kept the same
todo.id === id ? { ...todo, completed: !todo.completed } : todo
This pattern is very common in React for updating items in arrays

Conditional Rendering:

todo.completed ? '✅' : '⏳' – ternary operator for conditional display
textDecoration: todo.completed ? 'line-through' : 'none' – conditional styling

Arrow Functions in JSX:

onClick={() => toggleTodo(todo.id)} – arrow function to pass arguments to event handlers
Without the arrow function, toggleTodo(todo.id) would execute immediately

Now you can click on todos to toggle their completion status!

🤔 What we’ve learned so far:

✅ JSX syntax and rules
✅ useState hook for state management
✅ Event handling (onClick, onChange, onKeyPress)
✅ Controlled components
✅ Array mapping for rendering lists
✅ Conditional rendering
✅ State updates with spread operator

Next Steps: In the following steps, we’ll cover:

Deleting todos
Component composition (breaking into smaller components)
Props passing
Filtering todos
More advanced state management

Let’s see in Part 4. Happy React Development! 🚀

📦 Sprockets vs 🧵 Propshaft in Ruby on Rails 7/8 – What’s the Difference?

When working with asset pipelines in Ruby on Rails 7 and 8, you might encounter Sprockets and Propshaft—two asset handling libraries. While both aim to serve static assets like JavaScript, CSS, images, and fonts, they do so in different ways.

This post will walk you through what each does, how they differ, and when you might want to use one over the other.

📦 What is Sprockets?

Sprockets is the original Rails asset pipeline system, introduced way back in Rails 3.1. It allows developers to:

Concatenate and minify JavaScript and CSS
Preprocess assets using things like SCSS, CoffeeScript, ERB, etc.
Fingerprint assets for cache busting
Compile assets at deploy time

It works well for traditional Rails applications where the frontend and backend are tightly coupled.

Pros:

Mature and stable
Rich preprocessing pipeline (SCSS, CoffeeScript, ERB, etc.)
Supports advanced directives like //= require_tree .

Cons:

Complex internal logic
Slower compilation times
Relies on a manifest file that can get messy
Tightly coupled with older Rails asset practices

🧵 What is Propshaft?

Propshaft is the newer asset pipeline introduced by the Rails team as an alternative to Sprockets. It focuses on simplicity and modern best practices. Propshaft was added as an optional asset pipeline starting in Rails 7 and is included by default in some new apps.

Design Philosophy:
Propshaft aims to work like a static file server with fingerprinting and logical path mapping, rather than a full asset compiler.

Key Features:

Uses logical paths (e.g., /assets/application.css)
No preprocessing pipeline by default (but supports it via extensions like Tailwind or Sass)
Supports digesting (fingerprinting) of assets
Leaner and faster than Sprockets
Easier to integrate with modern JavaScript bundlers (like importmaps, esbuild, or webpack)

Pros:

Lightweight and fast
Easier to debug
Works great with importmaps and Hotwire
Modern, forward-looking approach

Cons:

No advanced preprocessing by default
Limited plugin ecosystem (still maturing)
Doesn’t support old Sprockets directives

🔍 Key Differences at a Glance

Feature	Sprockets	Propshaft
Introduced In	Rails 3.1	Rails 7
Default in Rails	Rails 6 and earlier	Optional from Rails 7+
Preprocessing Support	Yes (SCSS, ERB, CoffeeScript, etc.)	No (only raw assets by default)
Speed	Slower	Faster
Configuration Complexity	Higher	Minimal
Plugin Ecosystem	Large and mature	New and growing
Use With Importmaps/Hotwire	Can work, but heavier	Ideal
Debugging	Harder due to complexity	Easier

🧰 When Should You Use Sprockets?

Choose Sprockets if:

You are upgrading a legacy Rails app
Your project already relies on Sprockets
You use heavy asset preprocessing
You need compatibility with gems that depend on Sprockets

⚡ When Should You Use Propshaft?

Choose Propshaft if:

You are starting a new Rails 7/8 project
You use Importmaps or Hotwire/Turbo
You prefer faster and simpler asset handling
You don’t need complex preprocessing

Propshaft pairs particularly well with modern frontend workflows like Tailwind CSS (via build tools) or StimulusJS (with importmaps).

🛠️ Switching from Sprockets to Propshaft

If you’re migrating, here are basic steps:

Remove sprockets-rails gem from your Gemfile: # Gemfile # gem "sprockets-rails"
Add propshaft: gem "propshaft"
Update config/application.rb: config.assets.resolver = Propshaft::Resolver.new( paths: [Rails.root.join("app/assets")] )
Remove app/assets/config/manifest.js (used by Sprockets)
Move all assets to the correct logical paths under app/assets
Use digested URLs as needed (asset_path("application.css") etc.)

🧪 Real Example in Rails 8

Here’s how your application.html.erb might look using Propshaft:

<%= stylesheet_link_tag "application", "data-turbo-track": "reload" %>
<%= javascript_include_tag "application", "data-turbo-track": "reload", defer: true %>

And your app/assets/builds/application.css could be compiled via Tailwind or SCSS using a toolchain.

🧠 Final Thoughts

Sprockets has served Rails well for over a decade, but Propshaft is the new lightweight future. If you’re starting fresh, Propshaft is a strong choice, especially when used alongside Hotwire, Importmaps, or modern JS bundlers.

However, don’t feel pressured to switch if your current Sprockets setup works fine—Rails continues to support both.

✨ TL;DR

Sprockets = older, feature-rich, best for legacy apps
Propshaft = newer, minimal, better for modern workflows

Choose based on your app’s needs and complexity. Cheers! 🚀

Design Studio – Rails 8 e-commerce application: Integrate active admin

Now let’s create an admin interface for our e-commerce Application.

We have a well-structured e-commerce Rails application with:

Models: User, Product, ProductVariant, Order, OrderItem
Authentication: Custom session-based auth with user roles (customer/admin)
Authorization: Already has admin role checking

Admin Interface Recommendations

Here are the best options for Rails admin interfaces, ranked by suitability for our project:

ActiveAdmin (Recommended ⭐)
Best fit for e-commerce with complex associations
Excellent filtering, search, and batch operations
Great customization options and ecosystem
Handles your Product → ProductVariant → OrderItem relationships well
Administrate (Modern Alternative)
Clean, Rails-way approach by Thoughtbot
Good for custom UIs, less configuration
More work to set up initially
Rails Admin (What you asked about)
Quick setup but limited customization
Less actively maintained
Good for simple admin needs
Avo (Modern Premium)
Beautiful modern UI
Some features require paid version
https://avohq.io/rails-admin
https://docs.avohq.io/3.0/

Choose ActiveAdmin for our e-commerce application. Let’s integrate it with our existing authentication system

Add in Gemfile:

gem "activeadmin"
gem "sassc-rails" # Required for ActiveAdmin
gem "image_processing", "~> 1.2" # For variant processing if not already present

Bundle Install and run the Active Admin Generator:

$ bundle install
$ rails generate active_admin:install --skip-users
definition of Rules was here
create app/assets/javascripts/active_admin.js
create app/assets/stylesheets/active_admin.scss
create db/migrate/20250710083516_create_active_admin_comments.rb

Migration File created by Active Admin:

class CreateActiveAdminComments < ActiveRecord::Migration[8.0]
  def self.up
    create_table :active_admin_comments do |t|
      t.string :namespace
      t.text   :body
      t.references :resource, polymorphic: true
      t.references :author, polymorphic: true
      t.timestamps
    end
    add_index :active_admin_comments, [ :namespace ]
  end

  def self.down
    drop_table :active_admin_comments
  end
end

Run database migration:

$ rails db:migrate

in app/initializers/active_admin.rb

# This setting changes the method which Active Admin calls
  # within the application controller.
  config.authentication_method = :authenticate_admin_user!
....
# This setting changes the method which Active Admin calls
  # (within the application controller) to return the currently logged in user.
  config.current_user_method = :current_admin_user
....
 # Default:
  config.logout_link_path = :destroy_session_path

in app/controllers/application_controller.rb

private

  def authenticate_admin_user!
    require_authentication
    ensure_admin
  end

  def current_admin_user
    Current.user if Current.user&.admin?
  end

Run the active admin user, product generator:

rails generate active_admin:resource User
rails generate active_admin:resource Product
rails generate active_admin:resource ProductVariant
rails generate active_admin:resource Order
rails generate active_admin:resource OrderItem

Let’s update all the active admin resources with fields, filters, attributes, panels etc.

Let’s add accepts_nested_attributes_for :variants, allow_destroy: true in Product Model.

accepts_nested_attributes_for is a Rails feature that allows a parent model to accept and process attributes for its associated child models through nested parameters. Here’s what it does:

What it enables:

Nested Forms: You can create/update a Product and its ProductVariants in a single form submission
Mass Assignment: Allows passing nested attributes through strong parameters
CRUD Operations: Create, update, and delete associated records through the parent

In our Product model

class Product < ApplicationRecord
  has_many :variants, dependent: :destroy, class_name: "ProductVariant"
  accepts_nested_attributes_for :variants, allow_destroy: true
end

What this allows:

Before: You’d need separate forms/requests for Product and ProductVariant

# Create product first
product = Product.create(name: "T-Shirt", brand: "Nike")

# Then create variants separately
product.variants.create(size: "M", color: "Red", sku: "NIKE-001-M-RED")
product.variants.create(size: "L", color: "Blue", sku: "NIKE-001-L-BLUE")

After: You can do it all in one go:

Product.create(
  name: "T-Shirt",
  brand: "Nike",
  variants_attributes: [
    { size: "M", color: "Red", sku: "NIKE-001-M-RED" },
    { size: "L", color: "Blue", sku: "NIKE-001-L-BLUE" }
  ]
)

In ActiveAdmin context:

This enables the nested form I created in app/admin/products.rb:

f.inputs "Product Variants" do
  f.has_many :variants, allow_destroy: true, new_record: true do |v|
    v.input :size
    v.input :color
    v.input :sku
    # ... other variant fields
  end
end

The allow_destroy: true option:

Allows deleting associated records by passing _destroy: ‘1’
Essential for updating existing products with variants

Strong Parameters:

In the controller, you need to permit the nested attributes:

permit_params :name, :brand, :category, 
              variants_attributes: [:id, :size, :color, :sku, :mrp, :discount_percent, :_destroy]

Propshaft vs Sprockets

We have an error after integrating ActiveAdmin:

 Rendered layout layouts/application.html.erb (Duration: 13.9ms | GC: 0.5ms)
Completed 500 Internal Server Error in 118ms (ActiveRecord: 28.7ms (1 query, 0 cached) | GC: 27.0ms)

ActionView::Template::Error (undefined method 'load_path' for an instance of Sprockets::Environment)
Caused by: NoMethodError (undefined method 'load_path' for an instance of Sprockets::Environment)

Information for: ActionView::Template::Error (undefined method 'load_path' for an instance of Sprockets::Environment):
    14:     <link rel="icon" href="/icon.svg" type="image/svg+xml">
    15:     <link rel="apple-touch-icon" href="/icon.png">

This error occurs because Rails 8 uses Propshaft by default, but ActiveAdmin requires Sprockets. There’s a conflict between the two asset pipelines. Let’s fix this by switching to Sprockets completely:

Add in Gemfile:

# Use Sprockets for asset pipeline (required for ActiveAdmin)
gem "sprockets-rails"

$ bundle install

# application.rb

# Use Sprockets for asset pipeline
config.assets.enabled = true

Let’s create an admin user for testing our ActiveAdmin:

# seed.rb
# Create admin user
admin_user = User.find_or_create_by(email: "admin@designstudio.com") do |user|
  user.password = "password123"
  user.role = "admin"
end

puts "Admin user created: #{admin_user.email}" if admin_user.persisted?

# run seed
✗ rails db:seed

✅ We have Successfully Integrated ActiveAdmin with Nested Attributes!

I’ve successfully converted your Rails application to use nested attributes (variants_attributes) across the entire stack and integrated ActiveAdmin as your admin interface. Here’s what I accomplished:

🔧 What I Fixed & Updated:

1. Asset Pipeline Issue:

Switched from Propshaft to Sprockets (required for ActiveAdmin)
Updated Gemfile and application configuration
Fixed the load_path error you encountered

2. Model Changes:

Added accepts_nested_attributes_for :variants, allow_destroy: true to Product model

3. Controller Updates:

Changed from singular product_variant to plural variants_attributes
Simplified create/update actions to use Rails nested attributes handling
Updated strong parameters to permit nested variant attributes

4. View Improvements:

Updated product form to handle multiple variants with JavaScript
Added “Add Another Variant” functionality
Implemented proper nested form fields for all variant attributes

5. ActiveAdmin Configuration:

Set up authentication using your existing user system
Created comprehensive admin resources for all models
Added nested variant management in product forms
Built an informative dashboard with key metrics

🎯 Admin Features You Now Have:

Dashboard – Key metrics, recent activity, revenue overview
User Management – Role management, order history
Product Management – Full CRUD with image uploads and nested variants
Order Management – Status updates, batch actions
Inventory Management – ProductVariant and OrderItem tracking

🔑 Admin Access:

URL: http://localhost:3000/admin
Email: admin@designstudio.com
Password: password123

📊 Comparison vs Rails Admin:

ActiveAdmin Advantages:

✅ Better for complex e-commerce relationships
✅ Excellent filtering and search capabilities
✅ Powerful batch operations
✅ Highly customizable forms and views
✅ Active development and community

Rails Admin:

❌ Less actively maintained
❌ Limited customization options
❌ Not as suitable for complex nested relationships

🚀 What’s Working Now:

Nested Variants: Create/edit products with multiple variants in one form
Image Management: Upload multiple product images
Order Processing: Admin can update order statuses with batch actions
User Management: Promote users to admin, view order history
Dashboard Analytics: Revenue tracking, popular products, recent activity

Visit /admin to explore your new admin interface, Cheers!

Check docs: https://activeadmin.info/0-installation.html

⚠️ Tailwind UI Issue after moving to Sprockets

The issue is with <%= stylesheet_link_tag "/tailwind/application.css", "data-turbo-track": "reload" %> where we are trying to load Tailwind CSS from an incorrect path. The tailwindcss-rails gem serves Tailwind CSS differently. Let me fix this:

ls -la app/assets/tailwind/

curl -I http://localhost:3000/tailwind/application.css

rails routes | grep -i tailwind

The issue is that the /tailwind/application.css path is returning 404. The tailwindcss-rails gem works differently. Let’s check how it’s configured and fix this:

find . -name "*.css" -path "*/public/*" | head -10

rails assets:precompile

Now let’s test if the Tailwind CSS is properly accessible:

curl -I http://localhost:3000/assets/tailwind/application.css

The issue is that with the tailwindcss-rails gem, Tailwind CSS gets compiled into the main application.css file rather than a separate file. Let’s check the current asset manifest and fix the layout:

rails assets:precompile

bundle exec tailwindcss build

The Tailwind CSS is already built and located in app/assets/builds/tailwind.css. Let’s fix the configuration:

rails assets:precompile

curl -I http://localhost:3000/assets/tailwind.css

The issue has been fixed. The Tailwind CSS is now properly accessible. Here’s what I did to resolve the problem:

Identified the issue: The Tailwind CSS was being incorrectly referenced as /tailwind/application.css in the layout file, but it wasn’t being served properly through the asset pipeline.
Found the correct location: Discovered that the tailwindcss-rails gem builds the CSS file to app/assets/builds/tailwind.css.
Fixed the asset pipeline configuration:

Updated app/assets/config/manifest.js to include //= link_tree ../builds which includes the built Tailwind CSS
Removed the incorrect tailwind/application.css reference

Updated the layout file:

Changed from <%= stylesheet_link_tag "/tailwind/application.css" %>
To the correct <%= stylesheet_link_tag "tailwind", "data-turbo-track": "reload" %>

Verified the fix:

Successfully precompiled assets
Confirmed that http://localhost:3000/assets/tailwind.css returns a 200 OK status

Install Rails Icons 🍁

For better font-awesome assets, lets add rails-icons gem:

# Rails Icons - Modern icon library support
gem "rails_icons"

$ rails generate rails_icons:install --help
$ rails generate rails_icons:install --libraries=heroicons

$ npm install @fortawesome/fontawesome-free

How to migrate from the CDN to Rails Icons

For a production Rails application, it’s generally better to use a gem rather than a CDN for Font Awesome. Here’s why:

CDN Issues:

External dependency (can fail if CDN is down)
Privacy concerns (external requests)
No version control
Requires internet connection
Not cacheable with your assets

Gem Benefits:

Self-hosted (no external dependencies)
Better performance (served with your assets)
Version control
Works offline
Follows Rails conventions
Better for production

Based on my research, adding a gem is definitely the better approach for a production Rails application. Here are the best options:

Option 1: Modern approach with npm package (Recommended)

Since we’re using Rails 8 with modern tooling, I’d recommend using the npm package:

yarn add @fortawesome/fontawesome-free

npm --version

which node

However, given your current setup, I’d recommend Option 2 which is more Rails-native:

Option 2: Rails Icons gem (Recommended for our setup)

This is a modern gem that supports Font Awesome and other icon libraries with a clean Rails API:

bundle install

rails generate rails_icons:install --help

rails generate rails_icons:install --libraries=heroicons

Let’s remove the CDN and set up Rails Icons properly. Since we’re already using Font Awesome extensively, let’s add Font Awesome as a custom library:

rails generate rails_icons:initializer --custom=fontawesome

npm install @fortawesome/fontawesome-free

find node_modules/@fortawesome/fontawesome-free -name "*.svg" -type f | head -5

cp -r node_modules/@fortawesome/fontawesome-free/svgs/* app/assets/svg/icons/fontawesome/

✅ Rails Icons is now properly set up instead of the CDN. Here’s what we’ve accomplished:

What’s Changed:

✅ Removed the Font Awesome CDN link (no more external dependency)
✅ Added rails_icons gem with Heroicons as the default library
✅ Added Font Awesome as a custom library with all variants (solid, regular, brands)
✅ Self-hosted all icons through Rails asset pipeline

What is Ransack?

Ransack is a popular Ruby gem that provides powerful search and filtering capabilities for Rails applications. It’s commonly used with ActiveAdmin (which your app uses) to create searchable, filterable, and sortable data tables.

Ransackable Attributes and Associations

`ransackable_attributes`

This method defines which model attributes can be searched, filtered, or sorted through Ransack. It’s a security feature that prevents unauthorized access to sensitive data.

def self.ransackable_attributes(auth_object = nil)
  %w[id email role created_at updated_at password_reset_token password_reset_sent_at]
end

What it does:

Allows searching/filtering by id, email, role, created_at, updated_at, etc.
Prevents searching by sensitive fields like password_digest
The auth_object parameter can be used for role-based access control

`ransackable_associations`

This method defines which model associations can be used in Ransack queries.

def self.ransackable_associations(auth_object = nil)
  %w[orders sessions]
end

What it does:

Allows searching/filtering by related models (e.g., “users who have orders”)
Enables joins and complex queries across associations

Why This Matters for Security

Without these methods, Rails 7+ will raise warnings or errors because Ransack needs explicit permission to search certain fields. This prevents:

Information disclosure – Searching sensitive fields like passwords
Performance issues – Searching on unindexed or inappropriate fields
Unauthorized access – Accessing data through unexpected query parameters

Example Usage in ActiveAdmin

In your ActiveAdmin dashboard, this enables features like:

# In app/admin/users.rb
ActiveAdmin.register User do
  # Users can now search by email, role, etc.
  # Users can filter by orders, sessions
  # Users can sort by created_at, updated_at
end

In Our User Model

Looking at your User model:

def self.ransackable_attributes(auth_object = nil)
  %w[id email role created_at updated_at password_reset_token password_reset_sent_at]
end

def self.ransackable_associations(auth_object = nil)
  %w[orders sessions]
end

This means:

✅ Admins can search users by email, role, creation date
✅ Admins can filter users by their orders or sessions
✅ Admins can sort users by any of these attributes
❌ Admins cannot search by password_digest (secure)
❌ Admins cannot search by other sensitive fields

Benefits

Security: Explicit control over what can be searched
Performance: Only searchable fields need indexes
Usability: Provides powerful admin interface features
Compliance: Helps meet data protection requirements

Migration Guide:

Old CDN way:

<i class="fas fa-user"></i>          <!-- solid -->
<i class="far fa-star"></i>          <!-- regular -->
<i class="fab fa-facebook-f"></i>    <!-- brands -->

New Rails Icons way:

<%= icon "user", library: "fontawesome", variant: "solid", class: "size-6" %>
<%= icon "star", library: "fontawesome", variant: "regular", class: "size-6" %>
<%= icon "facebook-f", library: "fontawesome", variant: "brands", class: "size-6" %>

Or use modern Heroicons (recommended for new icons):

<%= icon "user", class: "size-6" %>
<%= icon "star", class: "size-6" %>
<%= icon "heart", class: "size-6" %>

Benefits:

✅ No external dependencies (works offline)
✅ Better performance (served with your assets)
✅ Version control over icons
✅ Multiple libraries (Font Awesome + Heroicons + more)
✅ Consistent API across all icon libraries
✅ Better for production and privacy

Our application should work exactly the same now, but with better performance and no external dependencies! You can gradually migrate icons from <i class="fas fa-x"> to <%= icon "x", library: "fontawesome", variant: "solid" %> as needed.

Asset Issue Again

✅ Final Fix Applied:

Added //= link_tree ../../javascript .js to the manifest, which tells Sprockets to include all JavaScript files from the app/javascript directory tree.

✅ What’s Working Now:

All CSS files properly compiled:

tailwind.css ✅
application.css ✅
active_admin.css ✅

All JavaScript files properly compiled:

application.js ✅
controllers/application.js ✅
controllers/decorative_background_controller.js ✅
controllers/hello_controller.js ✅
controllers/index.js ✅

Asset Pipeline fully functional:

Sprockets serving all assets correctly
Proper cache headers and ETags
All asset links declared in manifest

🎯 Current Status:

Our Rails application now has:

✅ Modern asset pipeline with Sprockets + Importmap
✅ Tailwind CSS for styling (self-hosted)
✅ ActiveAdmin for administration
✅ Rails Icons instead of Font Awesome CDN
✅ Stimulus controllers for JavaScript functionality
✅ All assets properly precompiled and served

Check Github: Active admin changes

📋 Clean Commit History Summary:

✅ Phase 1: feat: Add Rails Icons gem with Font Awesome and Heroicons support #94

Replaced Font Awesome CDN with self-hosted icons
Added Rails Icons with unified API for multiple icon libraries

✅ Phase 2: task: Migrate from Propshaft to Sprockets asset pipeline #96

Switched from Propshaft to Sprockets for ActiveAdmin compatibility
Fixed asset compilation and linking issues

✅ Phase 3: feat: Integrate ActiveAdmin for comprehensive admin interface #94

Complete ActiveAdmin setup with authentication
Full admin resources for all e-commerce models

✅ Phase 4: fix: Resolve ActiveAdmin PostgreSQL and Ransack security issues #94

Fixed PostgreSQL GROUP BY errors in dashboard
Added Ransack security configuration for all models

🚀 Our ActiveAdmin is now fully functional!

You should now be able to:

✅ Access the admin dashboard at localhost:3000/admin
✅ View analytics and statistics without GROUP BY errors
✅ Search and filter all resources safely with Ransack
✅ Manage Users, Products, Variants, Orders, and Order Items
✅ Use nested attributes for product variants
✅ Perform batch operations and advanced filtering

Test it out: Visit localhost:3000/admin and log in with your admin credentials to see the beautiful, fully-functional admin interface! 🎯

to be continued 🚀…

Guide: Integrating React.js ⚛️ into a Rails 8 Application – Part 2: Install React | Add esbuild, Jsx | Integrate React View

Throw back:

rails new design_studio_react --database=postgresql -j esbuild --skip-hotwire

Here’s what our Rails app looks like after skipping Hotwire with the --skip-hotwire flag:

✅ Current JavaScript/Node.js Setup (Clean & Minimal)

📦 Package Management:

package.json – Clean setup with only esbuild script
.node-version – Node.js version 24.1.0
No dependencies – Ready for React installation

📁 JavaScript File Structure (Ultra-Clean):

app/javascript/
└── application.js          # Empty entry point (2 lines total!)

app/javascript/application.js content:

// Entry point for the build script in your package.json

🚫 What Got Successfully Removed:

❌ No Turbo/Stimulus imports in application.js
❌ No controllers/ directory at all
❌ No Hotwire gems in Gemfile (only jsbundling-rails remains)
❌ No @hotwired/turbo-rails or @hotwired/stimulus dependencies

⚙️ Configuration Files (Minimal – Only 4):

package.json – esbuild build script only
.node-version – Node.js version pinning
Procfile.dev – Development processes (js: yarn build --watch)
app/javascript/application.js – Empty entry point

🔧 esbuild Configuration:

{
  "scripts": {
    "build": "esbuild app/javascript/*.* --bundle --sourcemap --format=esm --outdir=app/assets/builds --public-path=/assets"
  }
}

📂 Build Output:

app/assets/builds/ – Contains only .keep file (empty, ready for bundles)

🎯 HTML Integration:

<!-- Still includes the JavaScript module correctly -->
<%= javascript_include_tag "application", "data-turbo-track": "reload", type: "module" %>

(Note: data-turbo-track is just an HTML attribute for cache busting, not the Turbo library)

# create db
✗ rails db:migrate

# run react-rails-app in port 3001
✗ rails s -p 3001

🚀 Next Steps: Install & Setup React

Step 1: Install react, react-dom

Your app is now perfectly clean for React! Just run:

brew install yarn
yarn add react react-dom # check node_modules/ folder for what is installed
yarn add --dev @types/react @types/react-dom  # Optional: for TypeScript support, check node_modules/@types folder

Status: ✅ Minimal JavaScript foundation – No Hotwire bloat, perfect React starting point!

Now that we have a clean Rails app with esbuild setup, here’s our step-by-step roadmap to get React working:

Step 2: Create Your First React Component

Create a simple React component to test the setup:

mkdir app/javascript/components

Then create app/javascript/components/App.jsx:

import React from 'react';

function App() {
  return (
    <div>
      <h1>React is Working!</h1>
      <p>Welcome to your Rails + React app</p>
    </div>
  );
}

export default App;

Step 3: Update JavaScript Entry Point

Modify app/javascript/application.js to render React:

// Entry point for the build script in your package.json
import React from 'react';
import { createRoot } from 'react-dom/client';
import App from './components/App';

document.addEventListener('DOMContentLoaded', () => {
  const container = document.getElementById('react-root');
  if (container) {
    const root = createRoot(container);
    root.render(<App />);
  }
});

Step 4: Create a Controller & Route

Generate a home controller:

rails generate controller Home index

Step 5: Add React Root to View

Update app/views/home/index.html.erb:

<div id="react-root"></div>

Step 6: Set Root Route

Update config/routes.rb:

Rails.application.routes.draw do
  root "home#index"
  # ... other routes
end

Step 7: Start Development

# update Procfile.dev assign port 3001
web: env RUBY_DEBUG_OPEN=true bin/rails server -p 3001

# run our rails-react app by

✗ bin/dev
21:15:27 web.1  | started with pid 12619
21:15:27 js.1   | started with pid 12620
21:15:27 js.1   | yarn run v1.22.22
21:15:27 js.1   | $ esbuild app/javascript/*.* --bundle --sourcemap --format=esm --outdir=app/assets/builds --public-path=/assets --watch
21:15:27 js.1   | /bin/sh: esbuild: command not found
21:15:27 js.1   | error Command failed with exit code 127.
21:15:27 js.1   | info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
21:15:27 web.1  | => Booting Puma
..........

🎯 What This Gives Us:

✅ React components in app/javascript/components/
✅ esbuild automatically bundles JSX
✅ Hot reloading with yarn build --watch
✅ Rails serves your React app

🚨 Error Analysis:

Rails server started fine ✅ (port 3001)

🔧 Solution: Install JavaScript Dependencies

You need to install esbuild and other JavaScript dependencies first:

yarn install

📋 Files `yarn install` Checks:

1. Primary: `package.json`

{
  "name": "app",
  "private": true,
  "scripts": {
    "build": "esbuild app/javascript/*.* --bundle --sourcemap --format=esm --outdir=app/assets/builds --public-path=/assets"
  },
  "dependencies": {
    "react": "^19.1.0",           # ✅ Already added
    "react-dom": "^19.1.0"       # ✅ Already added  
  },
  "devDependencies": {
    "@types/react": "^19.1.8",      # ✅ Already added
    "@types/react-dom": "^19.1.6"   # ✅ Already added
  }
}

2. Lockfile: `yarn.lock`

Ensures exact versions for reproducible installs
Contains resolved URLs and integrity hashes

🚨 The Problem: Missing esbuild!

Our package.json calls esbuild in the build script, but esbuild is not listed as a dependency anywhere!

Rails should have added it, but didn’t. We need to add esbuild:

yarn add --dev esbuild

🔧 What yarn install does:

Reads package.json for dependency list
Reads yarn.lock for exact versions (if exists)
Downloads packages to node_modules/
Updates yarn.lock with new resolutions

Current issue: Our build script expects esbuild command, but it’s not installed in node_modules/.bin/esbuild

Solution: Add esbuild as a dev dependency!

Solved~ and start servers: Error Again!

x bin/dev

* Listening on http://[::1]:3001
22:54:43 web.1  | Use Ctrl-C to stop
22:54:44 js.1   | ✘ [ERROR] The JSX syntax extension is not currently enabled
22:54:44 js.1   |
22:54:44 js.1   |     app/javascript/application.js:11:16:
22:54:44 js.1   |       11 │     root.render(<App />);
22:54:44 js.1   |          ╵                 ^
22:54:44 js.1   |
22:54:44 js.1   |   The esbuild loader for this file is currently set to "js" but it must be set to "jsx" to be able to parse JSX syntax. You can use "--loader:.js=jsx" to do that.
22:54:44 js.1   |
22:54:44 js.1   | 1 error
22:54:44 js.1   | [watch] build finished, watching for changes..

This error occurs because esbuild doesn’t know how to handle JSX syntax! The <App /> is JSX, but esbuild needs to be configured to transform it.

🚨 Problem: esbuild can’t process JSX syntax

Your application.js contains JSX (<App />), but esbuild isn’t configured to transform JSX!

JSX (JavaScript XML) is a syntax extension for JavaScript, commonly used with React, that allows you to write HTML-like code within JavaScript files.

🔧 Solution: Configure esbuild for JSX

Update your package.json build script to handle JSX:

# add this to build
--jsx=automatic --loader:.js=jsx

✅ Fixed! Added JSX support:

What I added:

--jsx=automatic – Enables React’s automatic JSX runtime
--loader:.js=jsx – Treats .js files as JSX files

📝 What this means:

✅ esbuild can now process <App /> syntax
✅ You don’t need to import React in every JSX file
✅ Your .js files can contain JSX

bin/dev

Whola!!

Let’s see in Part 3. Happy React configuration! 🚀

Rails 8 App: Create an Academic software app using SQL without using ActiveRecord – Part 1 | users | products | orders

Let’s create a Rails 8 app which use SQL queries with raw SQL instead of ActiveRecord. Let’s use the full Rails environment with ActiveRecord for infrastructure, but bypass AR’s ORM features for pure SQL writing. Let me guide you through this step by step:

Step 1: Create the Rails App with ActiveRecord and PostgreSQL (skipping unnecessary components)

rails new academic-sql-software --database=postgresql --skip-action-cable --skip-jbuilder --skip-solid --skip-kamal

What we’re skipping and why:

–skip-action-cable: No WebSocket functionality needed
–skip-jbuilder: No JSON API views needed for our SQL practice app
–skip-solid: Skips Solid Cache and Solid Queue (we don’t need caching or background jobs)
–skip-kamal: No deployment configuration needed

What we’re keeping:

ActiveRecord: For database connection management and ActiveRecord::Base.connection.execute()
ActionController: For creating web interfaces to display our SQL query results
ActionView: For creating simple HTML pages to showcase our SQL learning exercises
PostgreSQL: Our database for practicing advanced SQL features

Why this setup is perfect for App with raw SQL:

Minimal Rails app focused on database interactions
Full Rails environment for development conveniences
ActiveRecord infrastructure without ORM usage
Clean setup without unnecessary overhead

=> Open config/application.rb and comment the following for now:

# require "active_job/railtie"
...
# require "active_storage/engine"
...
# require "action_mailer/railtie"
# require "action_mailbox/engine"
...
# require "action_cable/engine"

=> Open config/environments/development.rb config/environments/production.rb config/environments/test.rb comment action_mailer

🤔 Why I am using ActiveRecord (even though I don’t want the ORM):

Database Connection Management: ActiveRecord provides robust connection pooling, reconnection handling, and connection management
Rails Integration: Seamless integration with Rails console, database tasks (rails db:create, rails db:migrate), and development tools
Raw SQL Execution: We get ActiveRecord::Base.connection.execute() which is perfect for our raw SQL writing.
Migration System: Easy table creation and schema management with migrations (even though we’ll query with raw SQL)
Database Configuration: Rails handles database.yml configuration, environment switching, and connection setup
Development Tools: Access to Rails console for testing queries, database tasks, and debugging

Our Learning Strategy: We’ll use ActiveRecord’s infrastructure but completely bypass its ORM methods. Instead of Student.where(), we’ll use ActiveRecord::Base.connection.execute("SELECT * FROM students WHERE...")

Step 2: Navigate to the project directory

cd academic-sql-software

Step 3: Verify PostgreSQL setup

# Check if PostgreSQL is running
brew services list | grep postgresql
# or
pg_ctl status

Database Foundation: PostgreSQL gives us advanced SQL features:

Complex JOINs (INNER, LEFT, RIGHT, FULL OUTER)
Window functions (ROW_NUMBER, RANK, LAG, LEAD)
Common Table Expressions (CTEs)
Advanced aggregations and subqueries

Step 4: Install dependencies

bundle install

What this gives us:

pg gem: Pure PostgreSQL adapter (already included with --database=postgresql)
ActiveRecord: For connection management only
Rails infrastructure: Console, generators, rake tasks

Step 5: Create the PostgreSQL databases

✗ rails db:create
Created database 'academic_sql_software_development'
Created database 'academic_sql_software_test

Our Development Environment:

Creates academic_sql_software_development and academic_sql_software_test
Sets up connection pooling and management
Enables us to use Rails console for testing queries: rails console then ActiveRecord::Base.connection.execute("SELECT 1")

Our Raw SQL Approach:

# We'll use this pattern throughout our app:
connection = ActiveRecord::Base.connection
result = connection.execute("SELECT s.name, t.subject FROM students s INNER JOIN teachers t ON s.teacher_id = t.id")

Why not pure pg gem:

Would require manual connection management
No Rails integration (no console, no rake tasks)
More boilerplate code for connection handling
Loss of Rails development conveniences

Why not pure ActiveRecord ORM:

We want to do SQL query writing, not ActiveRecord methods.
Need to understand database performance implications.
Want to practice complex queries that might be harder to express in ActiveRecord.

Step 6: Create Users table

mkdir -p db/migrate

class CreateUsers < ActiveRecord::Migration[8.0]
  def up
    # create users table
    execute <<~SQL
      CREATE TABLE users (
        id INT,
        username VARCHAR(200),
        email VARCHAR(150),
        phone_number VARCHAR(20)
      );
    SQL
  end

  def down
    execute <<~SQL
      DROP TABLE users;
    SQL
  end
end

class CreateOrders < ActiveRecord::Migration[8.0]
  def up
    # create table orders
    execute <<~SQL
    SQL
  end

  def down
    execute <<~SQL
    SQL
  end
end

execute <<~SQL is a Rails migration method that allows you to run raw SQL statements. Let me break it down:

Components:

execute – A Rails migration method that executes raw SQL directly against the database
<<~SQL – Ruby’s “squiggly heredoc” syntax for multi-line strings that automatically strips leading whitespace (read: https://www.rubyguides.com/2018/11/ruby-heredoc/)

Usage:

class SomeMigration < ActiveRecord::Migration[8.0]
  def change
    execute <<~SQL
      CREATE INDEX CONCURRENTLY idx_users_email_lower 
      ON users (LOWER(email));
    SQL
  end
end

Why use it?

Database-specific features: When you need PostgreSQL-specific syntax, MySQL features, etc.
Complex SQL: For operations that Rails DSL doesn’t support easily
Performance: Direct SQL can sometimes be more efficient
Raw SQL requirements: When you specifically need to write SQL (as mentioned in our requirement)

Example for creating a users table with raw SQL:

class CreateUsers < ActiveRecord::Migration[8.0]
  def up
    execute <<~SQL
      CREATE TABLE users (
        id BIGSERIAL PRIMARY KEY,
        name VARCHAR(255) NOT NULL,
        email VARCHAR(255) NOT NULL,
        created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
        updated_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
      );

      CREATE UNIQUE INDEX idx_users_email ON users(email);
    SQL
  end

  def down
    execute <<~SQL
      DROP TABLE IF EXISTS users;
    SQL
  end
end

The <<~SQL heredoc ends when it encounters the closing SQL keyword, and the ~ strips indentation so your SQL can be properly formatted within the Ruby code.

Q) 🤔 Is it a best practise to repeat the database constraints in model validation in Rails? DB level vs App level? or both?

Best Practice: Use BOTH 🎯

Why both levels are recommended:

Database Level (Last Line of Defense)

-- Database constraints
price DECIMAL(10,2) NOT NULL CHECK (price > 0),
category product_category NOT NULL,
title VARCHAR(250) NOT NULL

Pros:

✅ Data integrity guarantee – No bad data can enter, ever
✅ Performance – Database enforces constraints efficiently
✅ Bulletproof – Protects against bulk operations, direct SQL, data imports
✅ Concurrency safe – Prevents race conditions
✅ Multi-application protection – If other apps access same DB

Application Level (User Experience)

validates :price, presence: true, numericality: { greater_than: 0 }
validates :category, inclusion: { in: %w[men women kids infants] }

Pros:

✅ User-friendly errors – “Price must be greater than 0” vs “CHECK constraint violated”
✅ Better UX – Validation before form submission
✅ Easier testing – Can unit test validations
✅ Conditional logic – Complex business rules
✅ Framework features – Callbacks, custom validators

Real-world scenarios where each matters:

Database saves you when:

# Bulk operations bypass Rails validations
Product.update_all(price: -10)  # DB constraint prevents this

# Direct SQL injection attempts
# DB constraints are your last line of defense

App validations save you when:

# User gets friendly error instead of:
# PG::CheckViolation: ERROR: new row violates check constraint
@product = Product.new(price: -5)
@product.valid? # => false
@product.errors.full_messages # => ["Price must be greater than 0"]

Practical Implementation:

class Product < ApplicationRecord
  # App-level validations for UX
  validates :title, presence: true, length: { maximum: 250 }
  validates :price, presence: true, numericality: { greater_than: 0 }
  validates :category, inclusion: { in: %w[men women kids infants] }

  # Don't duplicate precision validation if DB handles it
  # The DECIMAL(10,2) constraint is sufficient at DB level
end

-- DB-level constraints for data integrity
CREATE TABLE products (
  id BIGSERIAL PRIMARY KEY,
  title VARCHAR(250) NOT NULL,
  price DECIMAL(10,2) NOT NULL CHECK (price > 0),
  category product_category NOT NULL,
  -- DB handles precision automatically with DECIMAL(10,2)
);

What NOT to duplicate:

❌ Precision constraints – DECIMAL(10,2) handles this perfectly
❌ Data type validation – DB enforces INTEGER, BOOLEAN, etc.
❌ Complex regex patterns – Better handled in app layer

Conclusion:

Use both, but strategically:

Database: Core data integrity, type constraints, foreign keys
Application: User experience, business logic, conditional rules
Don’t over-duplicate simple type/precision constraints that DB handles well

This approach gives you belt and suspenders protection with optimal user experience.

to be continued … 🚀

Design Studio v0.9.5: A Visual Improvement in E-commerce Experience 🎨

Published: June 25, 2025

I am thrilled to announce the release of Design Studio v0.9.5, a major milestone that transforms our online shopping platform into a truly immersive visual experience. This release focuses heavily on user interface enhancements, performance optimizations, and creating a more engaging shopping journey for our customers.

🚀 What’s New in v0.9.5

1. Stunning 10-Slide Hero Carousel

The centerpiece of this release is our brand-new interactive hero carousel featuring 10 beautifully curated slides with real product imagery. Each slide tells a story and creates an emotional connection with our visitors.

Dynamic Gradient Themes

Each slide features its own unique gradient theme:

<!-- Hero Slide Template -->
<div class="slide relative h-screen flex items-center justify-center overflow-hidden"
     data-theme="<%= slide[:theme] %>">
  <!-- Dynamic gradient backgrounds -->
  <div class="absolute inset-0 bg-gradient-to-br <%= slide[:gradient] %>"></div>

  <!-- Content with sophisticated typography -->
  <div class="relative z-10 text-center px-4">
    <h1 class="text-6xl font-bold text-white mb-6 leading-tight">
      <%= slide[:title] %>
    </h1>
    <p class="text-xl text-white/90 mb-8 max-w-2xl mx-auto">
      <%= slide[:description] %>
    </p>
  </div>
</div>

Smart Auto-Cycling with Manual Controls

// Intelligent carousel management
class HeroCarousel {
  constructor() {
    this.currentSlide = 0;
    this.autoInterval = 4000; // 4-second intervals
    this.isPlaying = true;
  }

  startAutoPlay() {
    this.autoPlayTimer = setInterval(() => {
      if (this.isPlaying) {
        this.nextSlide();
      }
    }, this.autoInterval);
  }

  pauseOnInteraction() {
    // Pause auto-play when user interacts
    this.isPlaying = false;
    setTimeout(() => this.isPlaying = true, 10000); // Resume after 10s
  }
}

2. Modular Component Architecture

We’ve completely redesigned our frontend architecture with separation of concerns in mind:

<!-- Main Hero Slider Component -->
<%= render 'home/hero_slider' %>

<!-- Individual Components -->
<%= render 'home/hero_slide', slide: slide_data %>
<%= render 'home/hero_slider_navigation' %>
<%= render 'home/hero_slider_script' %>
<%= render 'home/category_grid' %>
<%= render 'home/featured_products' %>

Component-Based Development Benefits:

Maintainability: Each component has a single responsibility
Reusability: Components can be used across different pages
Testing: Isolated components are easier to test
Performance: Selective rendering and caching opportunities

3. Enhanced Visual Design System

Glass Morphism Effects

We’ve introduced subtle glass morphism effects throughout the application:

/* Modern glass effect implementation */
.glass-effect {
  background: rgba(255, 255, 255, 0.1);
  backdrop-filter: blur(10px);
  border: 1px solid rgba(255, 255, 255, 0.2);
  border-radius: 16px;
  box-shadow: 0 8px 32px 0 rgba(31, 38, 135, 0.37);
}

/* Category cards with gradient overlays */
.category-card {
  @apply relative overflow-hidden rounded-xl;

  &::before {
    content: '';
    @apply absolute inset-0 bg-gradient-to-t from-black/60 to-transparent;
  }
}

Dynamic Color Management

Our new helper system automatically manages theme colors:

# app/helpers/application_helper.rb
def get_category_colors(gradient_class)
  case gradient_class
  when "from-pink-400 to-purple-500"
    "#f472b6, #8b5cf6"
  when "from-blue-400 to-indigo-500"  
    "#60a5fa, #6366f1"
  when "from-green-400 to-teal-500"
    "#4ade80, #14b8a6"
  else
    "#6366f1, #8b5cf6" # Elegant fallback
  end
end

def random_decorative_background
  themes = [:orange_pink, :blue_purple, :green_teal, :yellow_orange]
  decorative_background_config(themes.sample)
end

4. Mobile-First Responsive Design

Every component is built with mobile-first approach:

<!-- Responsive category grid -->
<div class="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 xl:grid-cols-4 gap-6">
  <% categories.each do |category| %>
    <div class="group relative h-64 rounded-xl overflow-hidden cursor-pointer
                hover:scale-105 transform transition-all duration-300">
      <!-- Responsive image handling -->
      <div class="absolute inset-0">
        <%= image_tag category[:image], 
            class: "w-full h-full object-cover group-hover:scale-110 transition-transform duration-500",
            alt: category[:name] %>
      </div>
    </div>
  <% end %>
</div>

5. Public Product Browsing

We’ve opened up product browsing to all visitors:

# app/controllers/products_controller.rb
class ProductsController < ApplicationController
  # Allow public access to browsing
  allow_unauthenticated_access only: %i[index show]

  def index
    products = Product.all

    # Smart category filtering
    if params[:category].present?
      products = products.for_category(params[:category])
      @current_category = params[:category]
    end

    # Pagination for performance
    @pagy, @products = pagy(products)
  end
end

🔧 Technical Improvements

Test Coverage Excellence

I’ve achieved 73.91% test coverage (272/368 lines), ensuring code reliability:

# Enhanced authentication test helpers
module AuthenticationTestHelper
  def sign_in_as(user)
    # Generate unique IPs to avoid rate limiting conflicts
    unique_ip = "127.0.0.#{rand(1..254)}"
    @request.remote_addr = unique_ip

    session[:user_id] = user.id
    user
  end
end

Asset Pipeline Optimization

Rails 8 compatibility with modern asset handling:

# config/application.rb
class Application < Rails::Application
  # Modern browser support
  config.allow_browser versions: :modern

  # Asset pipeline optimization
  config.assets.css_compressor = nil # Tailwind handles this
  config.assets.js_compressor = :terser
end

Security Enhancements

# Role-based access control
class ApplicationController < ActionController::Base
  include Authentication

  private

  def require_admin
    unless current_user&.admin?
      redirect_to root_path, alert: "Access denied."
    end
  end
end

📊 Performance Metrics

Before vs After v0.9.5:

Metric	Before	After v0.9.5	Improvement
Test Coverage	45%	73.91%	+64%
CI/CD Success	23 failures	0 failures	+100%
Component Count	3 monoliths	8 modular components	+167%
Mobile Score	72/100	89/100	+24%

🎨 Design Philosophy

This release embodies our commitment to:

Visual Excellence: Every pixel serves a purpose
User Experience: Intuitive navigation and interaction
Performance: Fast loading without sacrificing beauty
Accessibility: Inclusive design for all users
Maintainability: Clean, modular code architecture

🔮 What’s Next?

Version 0.9.5 sets the foundation for exciting upcoming features:

Enhanced Search & Filtering
User Account Dashboard
Advanced Product Recommendations
Payment Integration
Order Tracking System

🎉 Try It Today!

Experience the new Design Studio v0.9.5 and see the difference visual design makes in online shopping. Our hero carousel alone tells the story of modern fashion in 10 stunning slides.

Key Benefits for Users:

✨ Immersive visual shopping experience
📱 Perfect on any device
⚡ Lightning-fast performance
🔒 Secure and reliable

For Developers:

🏗️ Clean, maintainable architecture
🧪 Comprehensive test suite
📚 Well-documented components
🚀 Rails 8 compatibility

Design Studio v0.9.5 – Where technology meets artistry in e-commerce.

Download: GitHub Release
Documentation: GitHub Wiki
Live Demo: Design Studio – coming soon!

Enjoy Rails 8 with Hotwire! 🚀

Hotwire 〰 in Rails 8 World – And How My New Rails App Puts this into Work 🚀

When you create a brand-new Rails 8 project today you automatically get a super-powerful front-end toolbox called Hotwire.

Because it is baked into the framework, it can feel a little magical (“everything just works!”). This post demystifies Hotwire, shows how its two core libraries—Turbo and Stimulus—fit together, and then walks through the places where the design_studio codebase is already using them.

1. What is Hotwire?

Hotwire (HTML Over The Wire) is a set of conventions + JavaScript libraries that lets you build modern, reactive UIs without writing (much) custom JS or a separate SPA. Instead of pushing JSON to the browser and letting a JS framework patch the DOM, the server sends HTML fragments over WebSockets, SSE, or normal HTTP responses and the browser swaps them in efficiently.

Hotwire is made of three parts:

Turbo – the engine that intercepts normal links/forms, keeps your page state alive, and swaps HTML frames or streams into the DOM at 60fps.
Stimulus – a “sprinkle-on” JavaScript framework for the little interactive bits that still need JS (dropdowns, clipboard buttons, etc.).
(Optional) Strada – native-bridge helpers for mobile apps; not relevant to our web-only project.

Because Rails 8 ships with both turbo-rails and stimulus-rails gems, simply creating a project wires everything up.

2. How Turbo & Stimulus complement each other

Turbo keeps pages fresh – It handles navigation (Turbo Drive), partial page updates via <turbo-frame> (Turbo Frames), and real-time broadcasts with <turbo-stream> (Turbo Streams).
Stimulus adds behaviour – Tiny ES-module controllers attach to DOM elements and react to events/data attributes. Importantly, Stimulus plays nicely with Turbo’s DOM-swapping because controllers automatically disconnect/re-connect when elements are replaced.

Think of Turbo as the transport layer for HTML and Stimulus as the behaviour layer for the small pieces that still need JavaScript logic.

# server logs - still identify as HTML request, It handles navigation through (Turbo Drive)

Started GET "/products/15" for ::1 at 2025-06-24 00:47:03 +0530
Processing by ProductsController#show as HTML
  Parameters: {"id" => "15"}
.......

Started GET "/products?category=women" for ::1 at 2025-06-24 00:50:38 +0530
Processing by ProductsController#index as HTML
  Parameters: {"category" => "women"}
.......

Javascript and css files that loads in our html head:

    <link rel="stylesheet" href="/assets/actiontext-e646701d.css" data-turbo-track="reload" />
<link rel="stylesheet" href="/assets/application-8b441ae0.css" data-turbo-track="reload" />
<link rel="stylesheet" href="/assets/tailwind-8bbb1409.css" data-turbo-track="reload" />
    <script type="importmap" data-turbo-track="reload">{
  "imports": {
    "application": "/assets/application-3da76259.js",
    "@hotwired/turbo-rails": "/assets/turbo.min-3a2e143f.js",
    "@hotwired/stimulus": "/assets/stimulus.min-4b1e420e.js",
    "@hotwired/stimulus-loading": "/assets/stimulus-loading-1fc53fe7.js",
    "trix": "/assets/trix-4b540cb5.js",
    "@rails/actiontext": "/assets/actiontext.esm-f1c04d34.js",
    "controllers/application": "/assets/controllers/application-3affb389.js",
    "controllers/hello_controller": "/assets/controllers/hello_controller-708796bd.js",
    "controllers": "/assets/controllers/index-ee64e1f1.js"
  }
}</script>
<link rel="modulepreload" href="/assets/application-3da76259.js">
<link rel="modulepreload" href="/assets/turbo.min-3a2e143f.js">
<link rel="modulepreload" href="/assets/stimulus.min-4b1e420e.js">
<link rel="modulepreload" href="/assets/stimulus-loading-1fc53fe7.js">
<link rel="modulepreload" href="/assets/trix-4b540cb5.js">
<link rel="modulepreload" href="/assets/actiontext.esm-f1c04d34.js">
<link rel="modulepreload" href="/assets/controllers/application-3affb389.js">
<link rel="modulepreload" href="/assets/controllers/hello_controller-708796bd.js">
<link rel="modulepreload" href="/assets/controllers/index-ee64e1f1.js">
<script type="module">import "application"</script>
    <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/6.0.0-beta3/css/all.min.css">

3. Where Hotwire lives in design_studio

Because Rails 8 scaffolded most of this for us, the integration is scattered across a few key spots:

3.1 Gems & ES-modules are pinned

# config/importmap.rb

pin "@hotwired/turbo-rails",  to: "turbo.min.js"
pin "@hotwired/stimulus",     to: "stimulus.min.js"
pin "@hotwired/stimulus-loading", to: "stimulus-loading.js"
pin_all_from "app/javascript/controllers", under: "controllers"

The Gemfile pulls the Ruby wrappers:

gem "turbo-rails"
gem "stimulus-rails"

3.2 Global JavaScript entry point

# application.js 

import "@hotwired/turbo-rails"
import "controllers"   // <-- auto-registers everything in app/javascript/controllers

As soon as that file is imported (it’s linked in application.html.erb via
javascript_include_tag "application", "data-turbo-track": "reload"
), Turbo intercepts every link & form on the site.

3.3 Stimulus controllers

The framework-generated controller registry lives at app/javascript/controllers/index.js; the only custom controller so far is the hello-world example:

connect() {
  this.element.textContent = "Hello World!"
}

You can drop new controllers into app/javascript/controllers/anything_controller.js and they will be auto-loaded thanks to the pin_all_from line above.

pin_all_from "app/javascript/controllers", under: "controllers"

3.4 Turbo Streams in practice – removing a product image

The most concrete Hotwire interaction in design_studio today is the “Delete image” action in the products feature:

Controller action responds to turbo_stream:

respond_to do |format|
  ...
  format.turbo_stream   # <-- returns delete_image.turbo_stream.erb
end

Stream template sent back:

# app/views/products/delete_image.turbo_stream.erb

<turbo-stream action="remove" target="product-image-<%= @image_id %>"></turbo-stream>

Turbo receives the <turbo-stream> tag, finds the element with that id, and removes it from the DOM—no page reload, no hand-written JS.

# app/views/products/show.html.erb
....
<%= link_to @product, 
    data: { turbo_method: :delete, turbo_confirm: "Are you sure you want to delete this product?" }, 
    class: "px-4 py-2 bg-red-500 text-white rounded-lg hover:bg-red-600 transition-colors duration-200" do %>
    <i class="fas fa-trash mr-2"></i>Delete Product
<% end %>
....

3.5 “Free” Turbo benefits you might not notice

Because Turbo Drive is on globally:

Standard links look instantaneous (HTML diffing & cache).
Form submissions automatically request .turbo_stream when you ask for format.turbo_stream in a controller.
Redirects keep scroll position/head tags in sync.

All of this happens without any code in the repo—Rails 8 + Turbo does the heavy lifting.

4. Extending Hotwire in the future

More Turbo Frames – Wrap parts of pages in <turbo-frame id="cart"> to make only the cart refresh on “Add to cart”.
Broadcasting – Hook Product model changes to turbo_stream_from channels so that all users see live stock updates.
Stimulus components – Replace jQuery snippets with small controllers (dropdowns, modals, copy-to-clipboard, etc.).

Because everything is wired already (Importmap, controller autoloading, Cable), adding these features is mostly a matter of creating the HTML/ERB templates and a bit of Ruby.

Questions

1. Is Rails 8 still working with the real DOM?

Yes, the browser is always working with the real DOM—nothing is virtualized (unlike React’s virtual DOM).

Turbo intercepts navigation events (links, form submits). Instead of letting the browser perform a “hard” navigation, it fetches the HTML with fetch() in the background, parses the response into a hidden document fragment, then swaps specific pieces (usually the whole <body> or a <turbo-frame> target) into the live DOM.
Because Turbo only swaps the changed chunks, it keeps the rest of the page alive (JS state, scroll position, playing videos, etc.) and fires lifecycle events so Stimulus controllers disconnect/re-connect cleanly.

“Stimulus itself is a tiny wrapper around MutationObserver. It attaches controller instances to DOM elements and tears them down automatically when Turbo replaces those elements—so both libraries cooperate rather than fighting the DOM.”

2. How does the HTML from Turbo Drive get into the DOM without a full reload?

Step-by-step for a normal link click:

turbo-rails JS (loaded via import “@hotwired/turbo-rails”) cancels the browser’s default navigation.
Turbo sends an AJAX request (actually fetch()) for the new URL, requesting full HTML.
The response text is parsed into an off-screen DOMParser document.
Turbo compares the <head> tags, updates <title> and any changed assets, then replaces the <body> of the current page with the new one (or, for <turbo-frame>, just that frame).
It pushes a history.pushState entry so Back/Forward work, and fires events like turbo:load.

Because no real navigation happened, the browser doesn’t clear JS state, WebSocket connections, or CSS; it just swaps some DOM nodes—visually it feels instantaneous.

3. What does `pin` mean in `config/importmap.rb`?

Rails 8 ships with Importmap—a way to use normal ES-module import statements without a bundler.pin is simply a mapping declaration:

pin "@hotwired/turbo-rails", to: "turbo.min.js"
pin "@hotwired/stimulus",    to: "stimulus.min.js"

Meaning:

When the browser sees import "@hotwired/turbo-rails", fetch …/assets/turbo.min.js
When it sees import “controllers”, look at
pin_all_from "app/javascript/controllers"
which expands into individual mappings for every controller file.

Think of pin as the importmap equivalent of a require statement in a bundler config—just declarative and handled at runtime by the browser. That’s all there is to it: real DOM, no page reloads, and a lightweight way to load JS modules without Webpack.

Take-aways

Hotwire is not one big library; it is a philosophy (+ Turbo + Stimulus) that keeps most of your UI in Ruby & ERB but still feels snappy and modern.
Rails 8 scaffolds everything, so you may not even realize you’re using it—but you are!
design_studio already benefits from Hotwire’s defaults (fast navigation) and uses Turbo Streams for dynamic image deletion. The plumbing is in place to expand this pattern across the app with minimal effort.

Happy hot-wiring! 🚀

Setup 🛠 Rails 8 App – Part 17: Fix Github actions, Mini-test 🗜️ Test Cases With Cursor AI ➘

Hello friends, in this post lets look into the issues we faced after integrating:

Sessions for users (sign in functionality)
Order, Order items models and the related code base

Check our Github actions failure cases here: https://github.com/MIRA-Designs/design_studio/actions/runs/14953772366/job/42006659413?pr=31

What is working?

Rubocop linting checks
Test cases – Fails
Brakeman security scan – Pending

Why the issue?

I made a mistake of integrating the sessions with Order and Order items model (I used the help of Co-piolet for improvement). I have only written the test cases for sessions. Why I made this mistake? Because for last some days the development was not happening in our design_studio project. So I was curious to do so many things at a time and I cannot control myself 🙂

Now what’s next?

Let’s solve the test cases issues. First I cannot get ‘why this test cases for Rate limit issue is happening’. I have to research on this. I want to try Cursor – how it works with these kind of scenarios. Cursor provide me details about exact issue in our test cases and updated for me. I was happy that I saved some time.

Let’s see What is the findings of cursor:

The current test case has few issues:

It’s testing for 11 attempts, but the rate limit is set to 10 attempts. We should test that the 11th attempt is rate limited, but also verify that the first 10 attempts work as expected.
We should verify that the rate limiting is time-based (within 1 minute) by testing that after waiting, the rate limit resets.

Fix the test case:

Cursor updated the test case to properly test the rate limiting functionality. Here’s what the improved test does:

First, it makes 10 attempts and verifies that each attempt gets the normal “invalid credentials” response
Then it makes the 11th attempt and verifies that it gets rate limited with the “Try again later” message
Finally, it uses Rails’ travel helper to move forward in time past the rate limit window (1 minute + 1 second) and verifies that the rate limit has been reset by making another attempt

This test now properly verifies:

The rate limit threshold (10 attempts)
The rate limit behavior (redirect with “Try again later” message)
The rate limit duration (1 minute)
The rate limit reset after the time window expires

The test is now more thorough and matches the actual implementation in the SessionsController.

Run the test case with the fix:

Failure:
SessionsControllerTest#test_should_rate_limit_login_attempts [test/controllers/sessions_controller_test.rb:34]:
--- expected
+++ actual
@@ -1 +1 @@
-"Try again later."
+"Try another email address or password."

the problem is that the rate limiting is happening at the controller level using rate_limit, but our test isn’t properly simulating real-world timing. Let me modify the test to ensure we’re making the requests within the 1-minute window and properly testing the rate limiting.

We fixed it and still the issues are not solved:

# Running:
F
Failure:
SessionsControllerTest#test_should_rate_limit_login_attempts [test/controllers/sessions_controller_test.rb:36]:
--- expected
+++ actual
@@ -1 +1 @@
-"Try again later."
+"Try another email address or password."

bin/rails test test/controllers/sessions_controller_test.rb:23

The issue may be with our SessionsController rate_limit directive. That is not working in test environment. I had this doubt. Let’s see what cursor tell us regarding this:

Looking at the SessionsController, the rate limiting is implemented using Rails’ rate_limit macro, but it seems the rate limiting might not be working as expected in the test environment. Let’s try to debug this by checking if we need to enable rate limiting in the test environment or if there’s a different approach needed.

Cursor suggested Rails cache setup and wipe out cache:

require "test_helper"

class SessionsControllerTest < ActionDispatch::IntegrationTest
  setup do
    # Use memory store for rate limiting in tests
    Rails.cache = ActiveSupport::Cache::MemoryStore.new
  end

  teardown do
    Rails.cache.clear
  end

  ......

The test environment is configured to use :null_store for caching, which means rate limiting won’t work. Let’s modify the test environment configuration:

environments/test.rb:

- config.cache_store = :null_store
+ config.cache_store = :memory_store

Cursor made two important changes:

Changed the test environment’s cache store from :null_store to :memory_store to ensure rate limiting works properly
Added a consistent IP address in the test requests using
headers: { REMOTE_ADDR: “192.168.1.1” }
since rate limiting is typically done based on the client’s IP address

The test should now work correctly because:

We have proper caching enabled in the test environment
We’re using a consistent IP address for all requests, which is what rate limiting typically uses to track requests
We’re still maintaining the time window with travel_to and travel
The cache is cleared between tests to ensure a clean state

Try running the test again – it should now properly detect when the rate limit is exceeded on the 11th request.

Running 5 tests in a single process (parallelization threshold is 50)
Run options: --seed 55394

# Running:
.

Finished in 1.222473s, 0.8180 runs/s, 28.6305 assertions/s.
1 runs, 35 assertions, 0 failures, 0 errors, 0 skips
Coverage report generated for Unit Tests to /Users/abhilash/rails/design_studio/public/coverage.
Line Coverage: 21.37% (81 / 379)

Works!! Cursor – you beauty.

Let us see why the fix worked:

The main issue was that the test environment was using :null_store for caching, which effectively disabled all caching. Since Rails’ rate limiting feature relies on caching to track request counts, it wasn’t working properly.
By changing to :memory_store, we enabled proper caching in the test environment, allowing the rate limiting to track requests.
Adding the consistent IP address (REMOTE_ADDR: “192.168.1.1”) in the test requests was also important because Rails’ rate limiting typically uses the client’s IP address as part of the cache key to track requests per client.
The test structure ensures clean state by:

Using setup to initialize a fresh cache store for each test
Using teardown to clear the cache after each test
Using travel_to to ensure consistent timing for rate limit windows
Using consistent IP addresses for request tracking

This is a good example of how testing rate limiting requires careful consideration of the entire environment, including caching, timing, and request attributes. The test now properly verifies that:

Users can make up to 10 attempts within a minute
The 11th attempt gets rate limited
After waiting for a minute, they can try again

I may need some more time to get the fact that: “Rails’ rate limiting feature relies on caching to track request counts”. Here is the importance of AI tool like cursor. It saved a lot of my debugging time.

Core principles

1) A single error boundary for all API controllers

2) Errors in before actions

3) Errors inside controllers

4) Errors in models, services, and libs

5) Other important surfaces

6) Observability

7) Testing

Applying this to our scenario

When to generalize vs. specialize

ActiveAdmin Asset Pipeline Options:

Current Status (2025):

Alternative Approaches:

1. Keep Sprockets (Current Choice)

2. Hybrid: Propshaft + Manual CSS for ActiveAdmin

Current Situation:

Our Options:

Option 1: Stay with Sprockets ⭐ (Recommended for now)

Option 2: ActiveAdmin Assets Gem (Simplest alternative)

Option 3: ActiveAdmin 4.0 Beta + Propshaft ⚠️ (Experimental)

Option 4: 🔄 Alternative Admin Gems

RailsAdmin:

Trestle:

Adminterface (Deprecated):

🏆 My Recommendation:

🔮 Future Outlook:

The Reality Check:

Current State:

🏗️ How ActiveAdmin Works:

🤷‍♂️ So What Are Our Real Options?

Option 1: Accept Current Setup

Option 2: Use activeadmin_assets Gem

Option 3: Build Custom Admin

🔍 What activeadmin_assets Actually Does:

🚨 activeadmin_assets = NO Customization

Since We Want Customization:

Our Current Setup Gives You:

Customization Examples We Can Do:

🎯 Reality Check:

💡 My Honest Last Decision:

📄 File 1:

Line 1: Import React

Function Component: Line 3-9

Line 11: Export

📄 File 2:

Imports: Line 2-4

DOM Integration: Line 6-12

🎯 Key React Concepts You Just Learned:

1. Components

2. JSX

3. Import/Export

4. React DOM

5. Rails Integration

📚 Step-by-Step React Learning with Todo List

Step 1: Understanding JSX and Basic Component Structure

🎯 Key Concepts Explained:

Quote Usage in JSX/JavaScript:

Step 2: Introduction to State with useState

🎯 Key Concepts Explained:

Step 3: Event Handling and Adding Todos

🎯 Key Concepts Explained:

🎯 Function Syntax Options in JavaScript:

1. Function Declaration (Traditional)

2. Function Expression with Arrow Function

3. Function Expression (Traditional)

🤔 Why use const for functions?

Arrow functions are expressions, not declarations:

Why const specifically?

📚 Key Differences:

Function Declaration vs Arrow Function:

Hoisting Behavior:

this Binding:

🚀 In React Context:

All these are equivalent in React:

💡 Why React developers prefer arrow functions:

🎯 What is Hoisting?

📚 How Hoisting Works:

Function Declarations are Hoisted:

Variable Declarations (with var) are Hoisted:

🚫 What is NOT Hoisted:

Step 2: Introduction to State with `useState`

🤔 Why use `const` for functions?

Why `const` specifically?

`this` Binding:

Variable Declarations (with `var`) are Hoisted:

`let` and `const` variables:

Example 2: Variable Hoisting with `var`

Example 3: Why `let` and `const` are different

`ransackable_attributes`

`ransackable_associations`