DEV Community: not-a-patch

Rubymine running Rails with Foreman

not-a-patch — Fri, 25 Mar 2022 18:55:36 +0000

Rails 7 has made foreman the standard way of running Rails. Rubymine's default project configuration will only start the Rails server and not the additional applications in the Procfile.dev. The Rubymine documentation solves the problem with RVM and gemsets but what if you don't use RVM? How can you get Rubymine to start via Foreman?

At the command line make sure you have foreman. You should not add foreman to the Gemfile!.

gem install foreman

You then create a new configuration for running or debugging the application. RubyMine doesn't have a configuration for Foreman so we will have to make it ourselves.

In the main menu, go to Run | Edit Configurations, click the Add icon, and select Gem Command from the list.
In the Run/Debug Configurations dialog, specify the following settings:

Name: Enter the run/debug configuration name, for example, foreman start.
Gem name: Specify the foreman gem here.
Executable name: Select the foreman executable.
Arguments: Specify an argument for running the application using Foreman, for example, start.

Click on Bundler

Disable bundle exec
- bundle exec stops you finding Gems outside of the Gemfile bundle. If you've followed the instructions faithfully then foreman won't be in the bundle.

Click OK.

You should now be able to run the foreman start configuration from within Rubymine.

References

Foreman manual
Bundler - bundle exec

Thanks

Thanks to the Reddit Rails community and jakefillsbass for the tip!

Switching off RSpec generators

not-a-patch — Wed, 02 Feb 2022 16:56:43 +0000

Finding the correct switch to turn off RSpec generators can be hard as it is sparsely documented. However, RSpec has a number of generators that are listed in this file.

# rspec-rails: lib/generators/rspec/scaffold/scafold_generator.rb
class_option :controller_specs, type: :boolean, default: false, desc: "Generate controller specs"
class_option :request_specs,    type: :boolean, default: true,  desc: "Generate request specs"
class_option :view_specs,       type: :boolean, default: true,  desc: "Generate view specs"
class_option :helper_specs,     type: :boolean, default: true,  desc: "Generate helper specs"
class_option :routing_specs,    type: :boolean, default: true,  desc: "Generate routing specs"

You can then use the list to switch off generators in application.rb.

config.generators do |g|
  g.test_framework :rspec
  g.controller_specs false
  g.request_specs false
  g.view_specs false
  g.helper_specs false
  g.routing_specs false
end

`form_with` option change from `local: false` to `local: true`

not-a-patch — Sat, 29 Jan 2022 15:26:56 +0000

Introduction

form_with was introduced in Rails 5.1 to avoid the confusion of having form_for and form_tag having similar roles.

form_with, was to have by default forms submitted with AJAX, xhr, rather than the standard HTTP request. The difference is that with a HTTP request, the current window is cleared, and the server response is loaded into the window. While an AJAX request, the current window is unaffected and the page can be updated depending on the results of the request.

Rails changes to `form_with`

Rails 5.1 documentation of form_with options described the situation as:

:local - By default form submits are remote and unobstrusive XHRs. Disable remote submits with local: true.

However, by Rails 6.1 the situation has reversed as form_with was now local by default. This is described in the documentation as::

:local - By default form submits via typical HTTP requests. Enable remote and unobtrusive XHRs submits with local: false. Remote forms may be enabled by default by setting config.action_view.form_with_generates_remote_forms = true.

Verify

With all this confusion, it's good to verify that what you think you're doing is actually happening. In the code we add local: false meaning this is a remote form to be submitted by AJAX.

Example Code (from 5.1 release notes)

<%= form_with(model: @article, local: false) do |form| %>
  ...
<% end %>

Produced code

If we view the HTML of the page the produced code includes data-remote="true". We have an AJAX form.

<form action="/articles" ... data-remote="true">
  ...
</form>

Motivation for writing

I keep getting confused about what happened when, and I'm writing this as reference to me. I do like the api dock which makes it easier to see what happened. Obviously, if I've misunderstood something, please feel to correct me. I wouldn't want to make the situation any worse!!

Reading

2.8 Unification of form_for and form_tag into form_with

Rubymine: Enable the JavaScript debugger

not-a-patch — Thu, 09 Dec 2021 17:31:20 +0000

Enable the JavaScript debugger

Open the Run/Debug Configuration by navigating from the main menu:
- Run => Edit Configurations.
Enable run browser
Enter the start URL
Enable Start JavaScript debugger automatically when debugging.

Why did I write this?

This is taken from RubyMine documentation, so why write this?

I wanted to be able to enable the JavaScript debugger within RubyMine, RubyMine 2021.3, and I had no luck until I found this RubyMine tutorial. It took me ages to Google and still can't find it straight away, so I'm leaving this note to myself.

Rails going backwards

not-a-patch — Mon, 20 Sep 2021 11:22:26 +0000

Introduction

This is a Rails review on how to link back to the page you've just visited from. I had struggled to get a solution, and reading through Stackoverflow I don't think I'm alone in this. This is my take and I hope it is useful or can become useful with the help of others.

Solutions

Solution 1: Back with hardcoding
Solution 2: Back with referer
Solution 3: Back with JavaScript
Solution 4: Back with session

Solution 1: Back with hardcoding

If there's only one route in and out of the page. Hardcoding the path out is a clean option. From here, it gets more interesting...

Solution 2: Back with referer

A popular back solution is to use Rails :back symbol to be passed to link_to. An example is in listing 1.

Listing 1



<%= link_to "my link', :back %>

link_to :back rails code It is described in the docs as:

Using a :back Symbol instead of an options hash will generate a link to the referer (a JavaScript back link will be used in place of a referer if none exists).

What's a referer? MDN give a definition for referer they say:

The Referer HTTP request header contains an absolute or partial address of the page making the request. When following a link, this would be the address of the page containing the link.

So, requests often have a URL of the page you were last on. This is the referer, spelt referer in official documents, and Rails uses it to get back again. However, the referer can be missing if the user typed the URL into the search bar directly, as well as other exceptions.

Checking for the referer

I wanted to see how it works. First, I found a way to get the referer in Firefox. You can check the referer by going to the Firefox inspector and then the network tab and searching for referer. In this example, we have navigated to edit page and checking for referer, which is the show page (FYI: the resource was feedbacks).

There are two issues with using the referer:
a. Back twice - if you go back more than once, the referer will point to where you were last. Not where you were when you were last on that page!
b. POST - if you perform a POST on the page, the referer is also reset.

a. Back Twice

We can see, in table 1, that back is fine for step 1 but on step 2 going back ends up in a loop between Show to Edit. In other words, the Referer only remembers one hop and can quickly form a loop because it is always pointing to where you were on the last hop.

Table 1: Stepping through an application, and what happens if you go back?

Step	Page	Referer	Back	Back again	And again	And again
0	Home	Empty	→ Empty	→ Empty	→ Empty	→ Empty
1	Show	Home	→ Home	→ Empty	→ Empty	→ Empty
2	Edit	Show	→ Show	→ Edit	⇾ Show	→ Edit*

It will keep looping between show and edit.

Another way to express this information is in a diagram where we can see the black lines as user clicks and blue lines when the user back clicks.

b. POST

It did not work when you are POST a form on the page and then want to go back. If I had to, POST on the show page, say I added a comment and stayed on the Show page. After you POST the referer gets set to the show page, the current page, and back will take you to the show page. In other words, nowhere.

Back with referer summary

link_to :back is only useful when you want to go back one page. In our case, once it had reached edit, it won't remember the original route it got to show. Further, when you POST on the page, the referer can get reset to the current page and losing the route back.

Solution 3: Back with JavaScript

Another popular class of answers are JavaScript. JavaScript is also used in Rails :back if the referer can't be found. Example of Back with Javascript is in listing 2.

Listing 2



 <%= link_to 'Back', 'javascript:history.back()' %>

JavaScript back uses the browser's page stack. Each time it visits a page, it is added to a stack of URLs. Going back meant popping each page reference off the stack. Here's a Stackoverflow on how a Browser back button works. The downside for this, if the user had gone to the edit and then saved and returned to the show page and then started to use back you would have to go "back" via the edit which might not be what the user expected.

Solution 4: Back with session

The final class of solutions were saving the routes in the session. To get this to work, I added methods to the ApplicationController to set and retrieve the values, as well as code to update the session in the controller and use the session variable in the view's link_to - Listing 3 contains the code.

This is not nearly as nice as the other two solutions, much less cohesion, as there's already 3 files required compared to 1 liners for the other solutions.

I'm not saying this is good code, I'm just saying this is what I had to do to get it to work!

Listing 3 Example of using session to go backwards



# app/controllers/application_controller.rb

class ApplicationController

  ...

  helper_method :retrieve_last_index_page_or_default

  ...

  def store_last_index_page

    session[:last_index_page] = request.fullpath

  end

def retrieve_last_index_page_or_default(default_path: root_path)

    session[:last_index_page] || default_path

  end

  ...

end

Updating session in controller code



# app/controllers/my_controller.rb

class MyController < ApplicationController

  ...

  def index

    ...

    # this could have been in a before_action

    store_last_index_page

    ...

  end

end

View code



  
  
  app/views/my/index.html.erb


  
  
  this could have been a variable set in controller


<%= link_to retrieve_last_index_page_or_default do %>

  ...

<% end %>

Summary

There are four ways to go backwards:

#	link_to	Type	Description
1	link_to my_path	Hardcoded	Clean, limited to one route
2	link_to :back	Referer	Clean, limited to one hop
3	link_to 'javascript:history.back()'	JavaScript	Access to Browser back
4	link_to get_session_variable()	Session	Powerful but complicated

References

link_to Rails docs (6.1.4)
url_helper Rails code (6.1.4)
MDN - Referer
HTTP_referer#Etymology
In what cases will the Referer be empty?
How does the Back button in a web browser work?

DEV Community: not-a-patch

Rubymine running Rails with Foreman

References

Thanks

Switching off RSpec generators

`form_with` option change from `local: false` to `local: true`

Introduction

Rails changes to form_with

Verify

Example Code (from 5.1 release notes)

Produced code

Motivation for writing

Reading

Rubymine: Enable the JavaScript debugger

Enable the JavaScript debugger

Why did I write this?

Rails going backwards

Introduction

Solutions

Solution 1: Back with hardcoding

Solution 2: Back with referer

Listing 1

Checking for the referer

a. Back Twice

Table 1: Stepping through an application, and what happens if you go back?

b. POST

Back with referer summary

Solution 3: Back with JavaScript

Listing 2

Solution 4: Back with session

Listing 3 Example of using session to go backwards

Updating session in controller code

View code

app/views/my/index.html.erb

this could have been a variable set in controller

Summary

References

Rails changes to `form_with`