Route Rollercoaster

When learning Rails, routes are one of the most puzzling things I’ve encountered so far.

Probably any person who knows how to properly use the framework will see this as stupid, but from where I stand, and how I’ve learned it in Codecademy, things were full of exceptions and I couldn’t understand what was what.

So, a couple of days ago, I decided to read the routes documentation:

- https://guides.rubyonrails.org/routing.html

Admittedly, I could only get through 25% of the whole document and realized that this is a big topic.

The Basics

Basically, what I understood at first is that when I have something like:

get "welcome", to: "welcome#index"

I was ‘getting’ the request of going to the welcome page and taking you to the index.html.erb…
In my head, it made sense.
After all, you are ‘getting something’ to ‘somewhere’ :)

After having many routing errors and only being able to make them work by ‘shotgunning’ random name orders at the routes, I had a good session with the LLM to break every part down.

Clearly, I had it all backwards:

get is not getting me anything, but taking me somewhere.
to: is not taking me somewhere, but ‘getting’ a controller.

If I’ve understood it correctly, the structure is basically:

get "welcome" → mydomain/welcome/
to: "welcome#index" → inside my WelcomeController, call the def index method (and apply whatever is inside it).

After understanding these two blocks, it was much easier for me to do very simple static navigation pages or apply any custom method for whatever logic we wanted to use.

Dynamic Segments

Then I came across dynamic values such as :id or :category when building the learning cards experiment.

Suddenly, there were two new things in my route.
I no longer had a simple folder structure for the get, but also had to deal with a thing with a semicolon in it.

Example:

get "theory/category/:category", to: "theory#start", as: "theory_start"

What was :category?
Certainly none of the folders I had. I was a bit confused.
Same goes for the as: "theory_start" part. No idea what these were for.

After more digging, the explanation I got kind of made sense.

("Kind of sense" not because the logic behind it isn’t good—that I don’t know—but because I only understand 60% of it...)

From what I’ve understood:

:value is used to pass dynamic values.
In my case, I had two such values: Card.id and Card.category.
These changed constantly in the routes, so we couldn’t hardcode them.

How to correctly route and call them is still something I’ll need to practice more, but at least I understand why these are different from static ones.

As for the as: "helper_name" part:

I do understand this is the name I want to give the route helper in order to call it.

At first, I thought I could use it like:

theory_start_path[:category]

Which gave me errors.

Turns out these helpers are functions, so we need to use:

theory_start_path(category: "category_id")

I’ll need to practice these more, and I probably should do a couple more experiments where I need to rely more heavily on passing dynamic values.

Namespaces and RESTful Routing

My last surprise when it comes to routes was the encounter I had this morning.
Apparently, there are two ways (that I know of at this point) of defining routes:

namespace :projects do
  get "hacker", to: "hacker#index"
end

And, to my surprise:

namespace :projects do
  resources :hacker, only: [:index]
end

This is how my original routes looked:

# Routes for projects
resources :projects, only: [:index, :create, :edit, :destroy]

namespace :projects do
  # hacker experiment routes
  get "hacker", to: "hacker#index"
  post "hacker/compare", to: "hacker#compare"
  post "hacker/reset", to: "hacker#reset"

  # word experiment routes
  get "wordplay", to: "wordplay#index"
  post "wordplay/transform", to: "wordplay#transform"

  # questionnaire about rails routes
  get "theory/category/:category", to: "theory#start", as: "theory_start"
  get "theory", to: "theory#index"
  get "theory/question/:id", to: "theory#show", as: "theory_question"
  post "theory/question/:id/answer", to: "theory#answer", as: "theory_answer"
  get "theory/results", to: "theory#results", as: "theory_results"
  get "theory/questions/grouped_questions", to: "theory/questions#grouped_questions", as: :grouped_questions

  resources :questions, controller: "theory/questions"
end

After digging into the grammar, I refactored to:

namespace :projects do
  resources :hacker, only: [:index] do
    collection do
      post :reset
      post :compare
    end
  end

  resources :wordplay, only: [:index] do
    collection do
      post :transform
    end
  end

  resources :theory, only: [:index, :show] do
    collection do
      get :start
      post :answer
      get :results
      get :grouped_questions
    end
    member do
      get :question
    end
  end
end

Learnings

Inside the only: [] part, you can only place RESTful methods.
(I don’t know all of them by heart yet—index, delete, and others I should memorize ASAP.)
I was mainly using index and show for the projects section of the site.

Also, from what I understand now:

collection routes apply to a group or general logic (no ID involved).
member routes refer to specific records (usually involving an ID).

Final Thoughts

Clearly, if you’ve read through all of this, you can see I’m still trying to solidify these concepts.

The only reason I’ve decided to write this down is because it’s forcing me to put what’s all wibbly-wobbly in my head into specifics—helping me identify that it was not as ‘understood’ as I thought it was.

After all of this, I think I now understand why, when I introduced a dropdown menu to manually switch between English, German, and Spanish in my mientrenadorpersonal.com website, the LLM wanted me to rename all the links and buttons:

All the routes would break after switching languages.

If I implemented the locale swapper with hardcoded routes and this inserted /de/ or /es/ into the /en/ route, it probably was breaking them.

If that’s the case, there should be an easy solution by refactoring the routes, instead of needing to hunt around every view…
Or, now that I think of it, I’ll probably have to do both anyway…

I guess it’s time for me to dig into Vim shortcuts for VS Code to make my life a bit easier finding references…
(Which probably is not even what I need, but a link tree of some sort).

Anyways… most likely, everything I wrote here is about 50% wrong.
If that’s the case, you’re welcome for the laughs.