Integrating Jbuilder

Jbuilder is a gem for Ruby on Rails that allows you to create JSON views more efficiently and expressively. With Jbuilder, you can write JSON views in separate files, rather than embedding them directly in the controller actions. Additionally, Jbuilder offers advanced features like including fragments from other views and dynamically constructing JSONs. In summary, Jbuilder is a very useful tool for creating cleaner and more maintainable JSON views in Ruby on Rails projects.

Examples of some views using Jbuilder:

json.coupons do
  json.array! @coupons, :id, :name, :code, :status, :discount_value, :max_use, :due_date
end

Endpoint for Creating a Category

To begin, let’s first test the category registration route. Before we create the test cases specifically, it's important to think about what needs to be tested in such a route, and two scenarios were considered:

• When the parameters are valid
• When the parameters are invalid

Therefore, we will create two distinct contexts within the request tests. We will add two internal contexts, one for valid parameters and another for invalid ones. For valid parameters, it’s important to test three fundamental aspects: whether a new Category was successfully added, whether it matches the last category added in the database, and whether the response status is 200 (:ok in Rails). These three tests will be added to our code.

context "GET /categories" do
  ...
end

context "POST /categories" do
  let(:url) { "/admin/v1/categories" }

  context "with valid params" do
  end

  context "with valid params" do
   let(:category_params) { { category: attributes_for(:category) }.to_json }

   it 'adds a new Category' do
     expect do
      post url, headers: auth_header(user), params: category_params
     end.to change(Category, :count).by(1)
   end
   
   it 'returns last added Category' do
    post url, headers: auth_header(user), params: category_params
    expected_category = Category.last.as_json(only: %i(id name))
    expect(body_json['category']).to eq expected_category
  end

   it 'returns success status' do
    post url, headers: auth_header(user), params: category_params
    expect(response).to have_http_status(:ok)
  end
 end
end

To ensure these tests pass, we need to implement the Categories controller that covers all scenarios described with valid parameters. We created the method and are checking if the params contain the key category before permitting it.

def create
   @category = Category.new
   @category.attributes = category_params
   @category.save!
   render :show
 rescue
   render json: { errors: { fields: @category.errors.messages } }, status: :unprocessable_entity
 end
end

private

def category_params
  return {} unless params.has_key?(:category)
  params.require(:category).permit(:id, :name)
end

We are saving the @category model with save!, which raises an exception if an error occurs, and rendering the show view. If @category has any errors, it will fall into the rescue block and render a JSON error message. With the endpoint created, we need to create the Jbuilder view for rendering the category in render :show:

json.category do
  json.(@category, :id, :name)
end

Updating and Removing a Category

We follow the same logic as for creating tests before building the endpoints, with the aim of achieving high coverage for all application endpoints. Tests are a crucial part of the software development process for any application, including the backend. They ensure that the code is functioning correctly, meeting specifications, and fulfilling user needs. Additionally, tests help detect and fix errors before the code is deployed to production, preventing issues and reducing costs.

Category Update Code:

def update
  @category = Category.find(params[:id])
  @category.attributes = category_params
  save_category!
end

Category Deletion Code:

def destroy
  @category = Category.find(params[:id])
  @category.destroy!
rescue
  render_error(fields: @category.errors.messages)
end

As noted in both codes, we use a find search for the category, passing the category's id as a parameter. Both the update and destroy actions need to load the category before acting on it. Therefore, let's abstract and place the loading process in a separate function and call it with a before_action for these two routes.

def load_category
  @category = Category.find(params[:id])
end


class CategoriesController < ApiController
  before_action :load_category, only: [:update, :destroy]
  
  ...
end

Search and Sorting Service

In Ruby on Rails, "services" are classes that encapsulate the business logic of an application that doesn’t naturally fit into other objects like models or controllers. Services are typically used for complex tasks or those requiring interactions with multiple parts of the system. They help keep the code clean and organized, separating business logic from the rest of the app and making it easier to test and modify.

A common example of using services is in an e-commerce app, where a "checkout" service could manage the payment process, stock verification, sending notifications, and other tasks related to checkout.

In this case, we will create a search and sorting service called ModelLoadingService. The idea for this service is to implement a call parameter that will receive two parameters: a mandatory one, the model where the search will be performed, and an optional one, the search parameters. These parameters are expected to include order for the sorting key, page and length for pagination, and search[:name] for searching by name. In Ruby on Rails, a service is generally a PORO (Plain Old Ruby Object). To implement a service, we start by creating a constructor method that takes in a model that already implements search by name (search_by_name) and pagination (paginate).

class ModelLoadingService
  def initialize(searchable_model, params = {})
    @searchable_model = searchable_model
    @params = params
    @params ||= {}
  end

  def call
    @searchable_model.search_by_name(@params.dig(:search, :name)).order(@params[:order].to_h)
        .paginate(@params[:page].to_i, @params[:length].to_i)
  end
end

Service to Save Product

We begin by declaring the "NotSavedProductError" error class that we will use, along with the service's available attributes. The next step is to create the constructor method, which will receive the parameters, including the optional product.

Within the constructor, we separate the received parameters in the params variable into those belonging to the Product model and those belonging to the associated entity. We also initialize the errors and product variables, with the latter representing the product being created or updated.

To ensure nothing is saved to the database in case of an error, we open a transaction and use ensure to call the save! method, which we will implement next. This method tries to save both the product and the associated entity productable, and if there are errors, they are stored in the @errors variable.

Finally, if any error occurs during this process, we re-raise the NotSavedProductError exception.

module Admin  
  class ProductSavingService
   class NotSavedProductError < StandardError; end

   attr_reader :product, :errors

    def initialize(params, product = nil)
      params = params.deep_symbolize_keys
      @product_params = params.reject { |key| key == :productable_attributes }
      @productable_params = params[:productable_attributes] || {}
      @errors = {}
      @product = product || Product.new
    end

    def call
      Product.transaction do
      @product.attributes = @product_params.reject { |key| key == :productable }
      build_productable
      ensure
    save!
      end
    end

    def build_productable
      @product.productable ||= @product_params[:productable].camelcase.safe_constantize.new
      @product.productable.attributes = @productable_params
    end

    def save!
      save_record!(@product.productable) if @product.productable.present?
      save_record!(@product)
     raise NotSavedProductError if @errors.present?
      rescue => e
     raise NotSavedProductError
    end
    
   def save_record!(record)
     record.save!
     rescue ActiveRecord::RecordInvalid
     @errors.merge!(record.errors.messages)
   end

  end
end