DEV Community: Jeeho Lee

Redirect back, fallback location, and where it may fail

Jeeho Lee — Wed, 28 Feb 2024 19:44:32 +0000

Redirect_back is a handy method that allows you to send back a user to the url that they accessed the action from. Fallback_location is a parameter in the method designed to provide a fallback URL in case the referrer is not available or cannot be determined. However, this is not a catch all for every situations, as it is very dependent on the request referrer.

A particular instance where I found it confusing that fallback didn't seem to be working was when I was destroying a record. For example, if we follow standard rails convention and tried to access a photo of id: 1 from a url called "website.com/photos/1", there would be a method defined in the controller as before_action where you might look to identify the photo id from params as such:

before_action :set_photo, only: %i[ show edit update destroy ]

...

def set_photo
   @photo = Photo.find(params[:id])
end

Now, if I were to use a button in "website.com/photos/1" to destroy the corresponding photo record and specified a redirect back in the destroy action, an ActiveRecord::RecordNotFound error would come up even if the fallback_location is specified. This is because the referrer is recognized as "website.com/photos/1", and the before_action would try to run the set_photo method to identify params[:id], :id being 1 which no longer exists. As per api.rubyonrails.org:

"The referrer information is pulled from the HTTP Referer (sic) header on the request. This is an optional header and its presence on the request is subject to browser security settings and user preferences. If the request is missing this header, the fallback_location will be used."

In our particular situation, this request header does exist (likely website.com/photos/1), albeit pointing to a record that no longer exists. Thus, the fallback is not considered since we do have a referrer, and we're instead met with the RecordNotFound error.

To deal with this RecordNotFound error, we could choose to add in a rescue for the RecordNotFound in a before_action to redirect to our fallback url, or alternatively conditionally check what our referrer is to situationally apply redirect_back. A simple example addition to our situation above could be to add the rescue into our set_photo method like this:

before_action :set_photo, only: %i[ show edit update destroy ]

...

def set_photo
   @photo = Photo.find(params[:id])
   rescue ActiveRecord::RecordNotFound => _
      redirect_to root_url
end

The point to clarify though is that there are situations like this where fallback location might not work like we'd want. Fallback location is still a great tool for situations like when a user tries to directly access an action by typing in a url, where the request referrer would be nil. However, it's important to know when/where these tools actually work and when/where they are not considered.

ActiveRecord Relation and create method

Jeeho Lee — Wed, 21 Feb 2024 22:00:20 +0000

The create method when called on a model creates and saves an ActiveRecord instance object with the attributes that you specified populated.

The method can also be attached on an ActiveRecord Relation which would create an ActiveRecord instance object with the attributes you specified populated, but also any scoped attributes from the relation.

For example, if I were to have a relation generated from the following query on a database called Movies to find instances that have a director_id of 1:

movies = Movie.where({ director_id: 1 })

and then I were to apply the create method on that relation with some attributes filled out:

movies.create(title: "New Title")

The generated ActiveRecord instance would have the title attribute populated but also have the director_id attribute populated with 1 which it took from the relation's attribute scoping. The create method also makes database changes so there is no need to call .save afterwards either.

This will be helpful to remember since it could potentially mean not having to specify attributes manually.

Working with has_many and belongs_to association methods

Jeeho Lee — Tue, 13 Feb 2024 21:10:57 +0000

When using has_many() and belongs_to() to simplify the creation of association methods between models, I wasn't sure if they'd be accurately reflective if the association methods had some additional steps out of the norm. For example, when looking at the many-to-many relationship of users to photos that's linked by a join table of comments, we could possibly write this as a method in the User model:

  def commented_photos
    my_comments = self.comments

    array_of_photo_ids = Array.new

    my_comments.each do |a_comment|
      array_of_photo_ids.push(a_comment.photo_id)
    end

    matching_photos = Photo.where({ :id => array_of_photo_ids })

    unique_matching_photos = matching_photos.distinct

    return unique_matching_photos
  end

However, if we reduce that to:

  has_many(:commented_photos,
    through: :comments,
    source: :photo
  )

It wouldn't be entirely accurate since we're omitting the step of ensuring we return only unique records (i.e. the line where we specify unique_matching_photos = matching_photos.distinct).

We could use the has_many method to create the method commented_photos, and then call the distinct method as a subsequent step, but if we wanted to include distinction within the method like it was initially written, it seems like the version of Rails we're on will determine how that'd be implemented.

For versions prior to Rails 4, you could add the :uniq option within the has_many associations:

  has_many(:commented_photos,
    :through => :comments,
    :source => :photo,
    :uniq => true
  )

However, for more current versions of Rails (up to version 7 at time of this post), we'd now write querying method inside the scope block as such:

  has_many(:commented_photos, -> {distinct},
    through: :comments,
    source: :photo
  )

This was a good reminder on double checking that using associations may save time, but we'll have to be careful to not omit any steps that are "out of the standard", and how scoping would help address these situations.

Ruby variables and pointers

Jeeho Lee — Fri, 09 Feb 2024 20:02:14 +0000

Today I learned that in Ruby, almost every variable is a reference/pointer to an object. It makes sense, since when working with databases in Rails, calling .destroy actually affected the object in the database instead of destroying a copy. I think it'll be good to note going forward on whether a method returns a copy or actually alters the object being referenced.

Order Ascending/Descending Rule with Dates and NIL

Jeeho Lee — Thu, 08 Feb 2024 22:38:37 +0000

While working on reordering a database of people by date of birth, I found it confusing why the oldest people were showing up as the first entry when doing ascending order and youngest people showing up as the first entry when doing descending order. If we're doing ascending, shouldn't it be least to greatest, thus the youngest to oldest?

If I had sorted by age, this would've likely been the case, but because I was sorting by date of birth, I was mistaken. Date/time values are stored as numbers, thus the more recent dates would be a larger number than the older dates. It would make sense that the older dates would show up first when put in ascending order since it's a small value.

Another order related info that I wanted to note was how to handle NULL values. As I naturally would assume, many databases consider NULL to have the lowest value, and thus the first value if ordering by ascending value. However, it seems like for PostgreSQL specifically, NULL values are sorted as if larger than non-null values (see https://stackoverflow.com/questions/5826210/rails-order-with-nulls-last). The nice thing is that it seems PostgreSQL has NULLS FIRST and NULLS LAST options to help with sorting!

Limitations of Cookies

Jeeho Lee — Tue, 06 Feb 2024 22:30:43 +0000

When I was working on my PokeLucky application (https://github.com/jeeheezy/sinatra-pokelucky), which interacts with the PokeApi, I tried to respect the PokeApi rule to cache information so there wouldn't be too many repetitive API calls. Since I was unfamiliar with how to cache information, I decided I'd just store the necessary data I got from the API into cookies to call back a later time. All was working fine until at a certain point, I got an error saying that I was trying to parse a nil object. Taking some time to debug, I found out it was because my conditions which look at if a Pokemon info was saved on a cookie did not take the expected "if" condition.

The core of the issue was that at a certain point, my cookie did not update with the latest information from the API because it had gotten too big. It seems that cookies have a byte limit of ~4000 bytes, which is not a lot. Even more to consider is that the best practice is to ensure the total bytesize of cookies doesn't exceed ~4000 per domain, not per cookie. I guess this is why learning how to use sessionStorage or localStorage is important since their storage capabilities are far greater than that of 4kb of cookies, although I'm not sure how one would access them in Ruby since I understand the two storages to be more front-end related.

TL;DR, cookies have bytesize limit and should not be the primary location to save continuous influx of data.

Some Ruby Details I Find Myself Tripping Up On

Jeeho Lee — Wed, 06 Dec 2023 08:14:34 +0000

I found myself getting caught on what attributes specifically are and how they function separately from methods. Attributes are specific properties of an object and store data, while methods are functions that can be associated with the object and define the behavior/capabilities of the object.

Attributes created by attr_accessor basically declares an instance variable and creates getter and setter methods. The importance of this would be in access the variables outside the scope of the instance, since all instance variables are private by default.

For example, if I were to create an attribute of username in a class of my definition called Person, I can access the attribute by self.username or by @username when inside the scope of Person. However, when I go outside of the scope of Person (let's say I create Jeeho = Person.new), I cannot access the instance variable. With the getter/setter methods defined by the attribute, I can access outside Person (e.g. Jeeho.username). Here, I'm technically not calling object.attribute, but rather object.attribute_method.

class Person
  attr_accessor :username

  def example_method
    return self.username
    # having object self here might be helpful to distinguish from local variable if there's a local variable of the same name as the method
    # same result as just calling @username
  end
end

Jeeho = Person.new
# can't access instance variable @username here outside Person, but still can access it if I have a getter method defined, which attributes does for me
Jeeho.username

Another detail of Ruby I was getting caught in was whether every method requires calling on an object. While object methods are referenced very clearly by object.method, it is still possible to create standalone methods that do not require an object (a good example of this being the square_root method that was in Defining our own classes Lesson).

def square_root(a_number)
  answer = a_number ** 0.5
  return answer
end