CODEWITHSUNDEEP
ruby-on-railsrubyruby-on-rails-4
FlyingV
FlyingV

Reputation: 3535

Questions regarding link_to function within Rails

Executive Summary

  1. Reading API and have a working "link_to", through brute force guessing.
  2. Providing API and description, and attempting to figure out how my brute force guess even worked!?

== End

I am trying to learn "How to Read API Documentation within Rails". One specific function that gives me a great deal of trouble is link_to function. Plain and simple, i just need to learn how to 'read api functions' and this question is related to that.

URL: http://apidock.com/rails/v4.0.2/ActionView/Helpers/UrlHelper/link_to

The current documentation details the following

1. link_to(body, url, html_options = {})
  # url is a String; you can use URL helpers like
  # posts_path

2. link_to(body, url_options = {}, html_options = {})
  # url_options, except :method, is passed to url_for

3. link_to(options = {}, html_options = {}) do
  # name
end

4. link_to(url, html_options = {}) do
  # name
end

Ultimately, I wanted to to add a whole bunch of HTML styling and leveraging AJAX to my link_to feature using a DO block.

This is what worked, but I just don't understand why Option #4 was used and not option #3 according to the prototype?

THIS WORKED:

<%= link_to session_path(@account.id), {remote: true, :method => :delete, id: "abc",style: "display:inline-block; top: 20px; color: red; outline: none;" } do %>
            <span class="glyphicon glyphicon-log-out" style: "display:inline-block; top: 20px; color: red; outline: none;"></span>
            <span id="nav_loginout_action" style= "top: 20px; color: none; outline: none;display:inline-block;margin-left: 5px;">
             Logout </span>
            <% end %>

THIS DID NOT

However if you notice {remote:true, method => delete} is being used for the OPTIONS, and {id: "abc",style: "display:inline-block; top: 20px; color: red; outline: none;"} for the HTML_OPTIONS

<%= link_to session_path(1), {remote: true, :method => :delete}, {id: "abc",style: "display:inline-block; top: 20px; color: red; outline: none;" } do %>
                <span class="glyphicon glyphicon-log-out" style: "display:inline-block; top: 20px; color: red; outline: none;"></span>
                <span id="nav_loginout_action" style= "top: 20px; color: none; outline: none;display:inline-block;margin-left: 5px;">
                 Logout </span>
                <% end %>

Can anyone explain how to read Rails documentation?

In particular

Here is what troubles me: 

In the documentation OPTIONS = {} is specifically defined as ".... :data, :method and remote:true.

In OPTION 4 it requires a HTML_OPTION (**NOT a OPTIONS, which is specifically requested within option #3 **). See URL link provided

The ONLY, and repeat the ONLY place where OPTIONS hash is mentioned is in OPTION 3! I initially tried to use option #3, but i wasn't sure what the #name was. That is another issue... (that i am wondering). But the main issue at the moment is how HTML_OPTIONS magically means OPTIONS.

My worry is I am not sure how to read some of these docs, so my ability to get self-help is limited. Please help.

Upvotes: 2

Views: 135

Answers (2)

limekin
limekin

Reputation: 1944

I've understood your concern. I have checked why it (first link_to you gave) works by reading the source. They are actually checking for remote and method keys in the html options passed to the link_to and not in url_options (except for remote). But in the docs where they list the options it can take for the field, instead of 'html_options', they gave it as 'options', that made it appear that those options are for options and url_options but not for html_options. Of course it seemed magical that it works the way you said with that kind of info. Also 'url_options' and 'options' are basically the same, I think it's a mistake in the doc.

The call in the second case is clearly not matched with any of the available signatures (argument lists). And yeah, the # name inside the block actually means the contents that should come inside the anchor tags. I think # link content is much more appropriate there.

So I think it isn't really you (you are sure of how to read the docs), there are some inconsistencies just like you said. :)

Upvotes: 1

vmarquet
vmarquet

Reputation: 2532

For #3, options is the URL options, so it should probably have been named url_options as in #2. Proof: rails source.

This perfectly normal that the "THIS WORKED" example worked, and it is perfectly normal that #4 was used and not #3, since the first parameter you give is session_path(@account.id), which is not a hash, whereas #3 first parameter is expected to be a hash.

It is also normal that your "THIS DID NOT WORKED" attempt didn't work, since you're passing 3 paremeters before the block, and there is no prototype for 3 paramaters followed by a block.

About Rails documentation in general

I agree that the docs are sometimes not very clear, but usually you can guess the missing informations by looking at the examples.

In your case, you could also simply have looked at the HTML generated.

If it's still not clear, the only solution is to look at the sources, as I did above.

Upvotes: 1

Related Questions