Route helpers in JS/CS assets

rubyonrails-core
1

Are there any reasons why Rails doesn't have any route helpers available for the JS/CS assets?

We're doing more and more client-side code and it is very likely that you'll need to do something like "$.post products_path, params" somewhere in your code.

Currently for doing that you'd need to create a file like asset.js.coffee.erb and then do something like:

$.post <%= Rails.application.routes.url_helpers.send(:products_path) %>, params

This is not only ugly and impractical, but I also don't want my files to be processed with ERB. This is not even possible inside my ECO templates.

So I decided a while back to create a routes.js.coffee.erb to export my named routes in some way to my other scripts. But as I needed more and more features it got a lot messy now:

<% h = Rails.application.routes.url_helpers    {      sections_json: :json, fields_from_parent: :json_id, move_field: :json,      field: :json_id, field_save: :json, remove_field: :html_id,      field_aggregates_autocomplete: [:json_id, :data_type],      field_dependents_autocomplete: :json_id,      field_set_aggregator: [:html_id, :aggregator_id],      field_remove_aggregate: :html_id,      field_add_dependent: [:html_id, :dependent_id],      field_remove_dependent: [:html_id, :dependent_id],      section_update: :html_id, section_create: :json,    }.each do |named_route, options|      options = Array(options)      format = options.shift      format_options = {}      format_options[:format] = :json if format =~ /json/      options.push format_options      if format =~ /_id/ %>        window.<%= named_route %>_path = (id, options)->          path = "<%= h.send :"#{named_route}_path", '999', *options %>".replace('999', id) <% if options.size > 1 %>          path = path.replace(k, v) for k, v of options          path <% end %> <% else %>        window.<%= named_route %>_path = '<%= h.send :"#{named_route}_path", format_options %>' <% end %>

See how to maintain something like this can become complicated?

Couldn't Rails provide an easier built-in way for the named routes to be easily exported as JS functions/variables?

This way, instead of each application define their own helpers for such a common requirement, an official way would exist and developers moving their jobs or projects would be aware where to look for.

I just feel there is some convention missing here.

Cheers, Rodrigo.

2

There are a couple gems and projects that do this:

I think this is likely outside the scope of rails core, given that most people doing ajax requests will be using the jquery-ujs or prototype-ujs helpers.

One of the issues why I would personally not use this is because, in order for it to work, you need to populate your JS with a list of all available routes throughout your app. For my own apps, I’d rather not have a list of all the applications’ routes in plain text ready to be exploited. Sure, everything is locked-down and access-controlled, but I still don’t necessarily want some random visitor knowing that registered group supervisors moderate their group’s content via this URL, and approve members via that URL. And again, all of this could be handled by only serving specific JS URL helpers to specific users, but it ends up creating more work than it saves.

– Steve Schwartz

3 
    There are a

couple gems and projects that do this:

      I think this is likely outside the scope of rails core,

given that most people doing ajax requests will be using the jquery-ujs or prototype-ujs helpers.

I don't understand how is jquery-ujs related to this issue.

      One of the issues why I would personally not use this is

because, in order for it to work, you need to populate your JS with a list of all available routes throughout your app. For my own apps, I’d rather not have a list of all the applications’ routes in plain text ready to be exploited.

I agree. I'm not suggesting that all routes should be exported, but

I’d like to be able to easily decide which ones to export.

      Sure, everything is locked-down and access-controlled, but

I still don’t necessarily want some random visitor knowing that registered group supervisors moderate their group’s content via this URL, and approve members via that URL. And again, all of this could be handled by only serving specific JS URL helpers to specific users, but it ends up creating more work than it saves.

I'm not sure if you have a proper idea on how much saving is that...

Even if the idea of exporting the routes to a JavaScript files is

not accepted, at least it should be easier to use the routes from an ERB asset.

"Rails.application.routes.url_helpers.send(:products_path)"     is

almost the same as an unsupported operation…

Kind regards,

Rodrigo.
4

Try app.root_path.

5

This only works in Rails console. Not in ERB views.

Steve, while crossroads.js is unrelated to this request, thank you

very much for pointing me out js-routes.

I'll give it a try soon.

Cheers,

Rodrigo.
6

You’re right, I searched my bookmarks for “js rails routes” and that came up, my bad. There is another project that also does this, which was on Hacker News a while back I think, but I can’t remember what it’s called.

– Steve Schwartz

7

I came to this same problem and think that it may perhaps need some convention…First my current solution to this. Suggestion to Rails Core at the bottom.

My solution came from “defining” an api subdirectory/route namespace and that all routes under that namespace are ones to be exported to view clients. The way I achieved this was by adding an #as_json to the Journey::Routes object, adding a RoutesController (in case the client needs to confirm/get updated routes at any point), plus setting a global route object in the JS of the served HTML. (see the attached example file)

This returns an object that looks like this:

[ {:name=>“api_comments”,

:path=>“/api/comments(.:format)”,

:jsonp=>false, :verbs=>[“GET”] },

{ :name=>“api_comment_cache”,

:path=>“/api/comments/:comment_id(/:commenter_id)(.:format)”,

:jsonp=>true, :verbs=>[“GET”]}

]

Then I created a pared down version of the Rails router/parser on the JS end to find the right route for the given request method and fill in the necessary parameters.

Note I also needed to maintain which paths are called with JSONP because they need fully qualified URLs and a wholly different calling mechanism. At this point it is just a specific list in the #as_json method. It could be identified by another namespace, or something.

So…what is my actual suggestion to Rails Core?

That we could consider formalizing Routes#as_json/to_xml for this type of usage. But, quickly, you get to considering implementing the whole Rails routes algorithm in JS for this to work in anything like an automatic process.

But, the goal of DRY routes, with the routes.rb file being in charge is a very appealing one.

client_routes.rb (1.87 KB)

8

Are there any reasons why Rails doesn’t have any route helpers available for the JS/CS assets?

We’re doing more and more client-side code and it is very likely that you’ll need to do something like “$.post products_path, params” somewhere in your code.

This sort of functionality strikes me as similar to the asset handlers (image-url etc) in sass-rails. As I understand it, sass-rails determines the correct url at runtime/compiletime by hooking into the application config.

Could routes be handled in a similar way, so that coffee-rails converts a route into a url at runtime/compiletime?

Maybe a reserved keyword or method is added to coffeescript (e.g. rails_routes) and then parsed when converting to JS. So…

$.get rails_route(products_path 1)

becomes:

$.get(‘/products/1’)

This method would keep all the routes data on the server and avoids any duplication.

The similar other option would be to just check the coffeescript for any functions ending in _path or _url and then parse them accordingly. So…

$.get products_path(1)

becomes:

$.get(‘/products/1’)

This has the advantage of being cleaner to code, but has two disadvantages: It could potentially lead to naming conflicts (but I think that this is probably an issue for the developer to avoid) and it would be probably be slower to compile.

tl;dr;

Hook into routes.rb while compiling CoffeeScript to Javascript and enable native feeling routes in CoffeeScript.

Thoughts?

Jeremy

9

tl;dr;

Hook into routes.rb while compiling CoffeeScript to Javascript and enable native feeling routes in CoffeeScript.

I think the problem there is that you wouldn’t know to put “1” in there at asset compile time. It’d only work for un-nested collection paths like “/products”.

– Steve Schwartz

10

tl;dr;

Hook into routes.rb while compiling CoffeeScript to Javascript and enable native feeling routes in CoffeeScript.

I think the problem there is that you wouldn’t know to put “1” in there at asset compile time. It’d only work for un-nested collection paths like “/products”.

But in the CoffeeScript, the developer will know the id of the resource they’re calling.

So, the CS:

$.get project_path(project.id)

…could be pre-processed, using a lookup in routes.rb, into:

$.get “projects/#{project.id}”

…which then gets compiled to:

$.get “projects/” + project.id

And voila, you have a working solution. Am I missing something? :slight_smile:

11

tl;dr;

                Hook into routes.rb while compiling CoffeeScript

to Javascript and enable native feeling routes in CoffeeScript.

    I think the

problem there is that you wouldn’t know to put “1” in there at asset compile time. It’d only work for un-nested collection paths like “/products”.

At least it would help a bit:

$.get rails_route(product_path(999).replace('999', id))

I actually like this idea. Even if it is not an ideal one...

Cheers,

Rodrigo.
12

Yes, the id will be inside a JS variable. So if you have some constraints like /\d+/, it won’t be able to check them…

13

Good point. Am I correct in saying that the only time this is a real issue is if someone defines two routes, with the same name, but different paths, e.g.

match ‘/products/:id’ => ‘products#show’, :constraints => {:id => /\d/}, as: “product”

match ‘/products/:id/extra’ => ‘products#show’, as: “product”

In other situations, the generated path will be the same, and the server will still check the constraint if/when the request is sent, so the developer loses a little compile-time type-safety, but everything stays safe/secure.

Obviously, the two different routes with the same name thing is an issue, but that idiom strikes me as a bit odd/risky in the first place.

14

tl;dr;

Hook into routes.rb while compiling CoffeeScript to Javascript and enable native feeling routes in CoffeeScript.

I think the problem there is that you wouldn’t know to put “1” in there at asset compile time. It’d only work for un-nested collection paths like “/products”.

But in the CoffeeScript, the developer will know the id of the resource they’re calling.

So, the CS:

$.get project_path(project.id)

…could be pre-processed, using a lookup in routes.rb, into:

$.get “projects/#{project.id}”

…which then gets compiled to:

$.get “projects/” + project.id

And voila, you have a working solution. Am I missing something? :slight_smile:

Yes, the id will be inside a JS variable. So if you have some constraints like /\d+/, it won’t be able to check them…

I’m thinking aloud here, so bare with me.

You’d also need to be able to create coffeescript functionality for static [1] and dynamic segments [2], defining defaults [3], and using constraints of all types (segment constraints, request-based constraints, etc) like Rodrigo mentioned.

Though I’m not entirely convinced constraints would need to be handled, as in you’d get “route not found” on the response end if you didn’t obey the constraint. The reason you’d need constraint checking on the request side (in the JS) would be so that it knows to select the next matching route down the list, which could possibly be considered an edge case to handle later. Maybe the other points I mentioned fall into the same category.

I think the point is, if you make route helpers available in coffeescript, people are going to expect all of the functionality of routes to work. Now I’m not intimately familiar with the innards of rails route compiling; maybe the fact that we’re hooking into routes after they’ve already been generated by Rails makes these points easier to address.

But yes, I would think given enough time and code, you probably could make route helpers work in coffeescript at compile time. Also keep in mind, that this coffeescript functionality would need to be maintained and updated along side the core routes functionality.

The way I handle routes in my apps is to put the URLs in a data- attribute on the element being clicked or submitted (so I can use the core route helpers). Then, in my JS, I’d do:

$project = $(‘#project-link’)

$.get ( $project.data(‘url’) )

[1] Rails Routing from the Outside In — Ruby on Rails Guides

[2] Rails Routing from the Outside In — Ruby on Rails Guides

[3] Rails Routing from the Outside In — Ruby on Rails Guides

– Steve Schwartz

15

Yeah, that would work.

I just thought you were suggesting to use produc_path(id) for

implementing this feature. In that case, it would raise an exception if id is not a number.

How are you thinking about the implementation of such feature while

processing CS?

Also, what if someone still wants to keep using JS instead of CS?

How would it be possible for them to take advantage of the asset pipeline route helpers?

16

I honestly don’t know enough about CS internals to specifically say how I’d implement it. However, the two methods I’d initially explore would be:

  1. Monkey-patch the compiler to recognise the routes’ names as keywords/methods and then either process them for more CS compilation, or process them straight to JS. This method depends a lot on how the compiler has been written and how extendable it is. I would imagine that recognising new nodes as it parses is pretty standard, but it’s how easy it is to insert that functionality in. I imagine 30mins of browsing through code would tell you if it was feasible.

  2. Pre-processing the CS to look for the method names by regex and then convert them to CS, before the processing starts. This method is a bit more brute-force and lots more error prone. I can think of lots of stuff that would go wrong. I’d consider it a last-ditch idea in case the CS compiler wasn’t easily monkey-patchable.

With regards to JS instead of CS. My initial reaction is, they wouldn’t be able to. As Rails now supports CS out of the box (it’s in the generated Gemfile), then I’d expect people to be ok with technologies being built into that. If you want to not use the default Rails JS library (CoffeeScript), then you don’t get all the features. However, if people felt it needed to be build in, then you could use either methods 1 or 2, using a JS interpreter for method 1.

If this is a solution that the Core team feel is worth exploring further, then I’m happy to set some time aside to seriously explore it more. Saying that, there are lots of people who know the internals of CoffeeScript and could probably verify how easy it will be to do without much effort.

17

I also use this technique, except when it is not possible.

When your application gets more complex, you'll need to do some

interactions with the server without rendering any Rails partial view.

For example, I'm currently working in an application where the base

html body is:

<div id=fields-tree></div>

And it will build the whole interface from CS, using ECO templates

and will send tons of JSON requests to the server to get the data.

So, putting the url in data attributes is not a real option for this

kind of application.

And this is not the first time I'm working on applications like this

one.

I've been doing this since 2009 in almost all applications I've been

working with since then.

And this is not just me. With exception of one application, all the

other applications I’ve been worked with since 2009 were developed by different developers.

Given the raise of all those JS MVC-like frameworks and template

libraries popping out all the time I’d say that this is a natural tendency for nowadays web applications.

And the lack of an easy way to use the routes in our client-side

code makes Rails a not ideal framework for working with such kind of applications.

Not that I'd recommend any other web framework that is more suited

to this task.

But this is an issue that should be addressed by Rails as this is

how the web currently works or is moving towards this direction.

Best,

Rodrigo.
18 
                  Good point. Am I correct in saying that the

only time this is a real issue is if someone defines two routes, with the same name, but different paths, e.g.

                  match '/products/:id' => 'products#show',

:constraints => {:id => /\d/}, as: “product”

                  match '/products/:id/extra' =>

‘products#show’, as: “product”

                  In other situations, the generated path will be

the same, and the server will still check the constraint if/when the request is sent, so the developer loses a little compile-time type-safety, but everything stays safe/secure.

                  Obviously, the two different routes with the

same name thing is an issue, but that idiom strikes me as a bit odd/risky in the first place.

Yeah, that would work.

        I just thought you were suggesting to use produc_path(id)

for implementing this feature. In that case, it would raise an exception if id is not a number.

        How are you thinking about the implementation of such

feature while processing CS?

        Also, what if someone still wants to keep using JS instead

of CS? How would it be possible for them to take advantage of the asset pipeline route helpers?

      I honestly don't know enough about CS internals to

specifically say how I’d implement it. However, the two methods I’d initially explore would be:

      1) Monkey-patch the compiler to recognise the routes' names as

keywords/methods and then either process them for more CS compilation, or process them straight to JS. This method depends a lot on how the compiler has been written and how extendable it is. I would imagine that recognising new nodes as it parses is pretty standard, but it’s how easy it is to insert that functionality in. I imagine 30mins of browsing through code would tell you if it was feasible.

      2) Pre-processing the CS to look for the method names by

regex and then convert them to CS, before the processing starts. This method is a bit more brute-force and lots more error prone. I can think of lots of stuff that would go wrong. I’d consider it a last-ditch idea in case the CS compiler wasn’t easily monkey-patchable.

Sorry, but that was not my concern when I asked you about the

implementation.

I'd like to know how you think this should be implemented in the

Rails side.

Given that the CS compiler detected "product_path(id)", how should

it proceed to replace it with JS or CS code?

      With regards to JS instead of CS. My initial reaction is,

they wouldn’t be able to. As Rails now supports CS out of the box (it’s in the generated Gemfile), then I’d expect people to be ok with technologies being built into that. If you want to not use the default Rails JS library (CoffeeScript), then you don’t get all the features. However, if people felt it needed to be build in, then you could use either methods 1 or 2, using a JS interpreter for method 1.

I'm not sure. I don't write JS anymore myself, but I can understand

those who don’t want or feel the need to use CS. Also, someone could want to edit some existent JS to change some fixed path by one generated by the route helpers.

An option for them would be to create a routes.js.coffee file just

for storing the generated paths in some variables and require this file before any other JS using those paths…

      If this is a solution that the Core team feel is worth

exploring further, then I’m happy to set some time aside to seriously explore it more. Saying that, there are lots of people who know the internals of CoffeeScript and could probably verify how easy it will be to do without much effort.

I'd rather discuss the Rails-side implementation effort first, as I

guess this could be the hardest part instead of the CS integration one…

19 
                  Good point. Am I correct in saying that the

only time this is a real issue is if someone defines two routes, with the same name, but different paths, e.g.

                  match '/products/:id' => 'products#show',

:constraints => {:id => /\d/}, as: “product”

                  match '/products/:id/extra' =>

‘products#show’, as: “product”

                  In other situations, the generated path will be

the same, and the server will still check the constraint if/when the request is sent, so the developer loses a little compile-time type-safety, but everything stays safe/secure.

                  Obviously, the two different routes with the

same name thing is an issue, but that idiom strikes me as a bit odd/risky in the first place.

Yeah, that would work.

        I just thought you were suggesting to use produc_path(id)

for implementing this feature. In that case, it would raise an exception if id is not a number.

        How are you thinking about the implementation of such

feature while processing CS?

        Also, what if someone still wants to keep using JS instead

of CS? How would it be possible for them to take advantage of the asset pipeline route helpers?

      I honestly don't know enough about CS internals to

specifically say how I’d implement it. However, the two methods I’d initially explore would be:

      1) Monkey-patch the compiler to recognise the routes' names as

keywords/methods and then either process them for more CS compilation, or process them straight to JS. This method depends a lot on how the compiler has been written and how extendable it is. I would imagine that recognising new nodes as it parses is pretty standard, but it’s how easy it is to insert that functionality in. I imagine 30mins of browsing through code would tell you if it was feasible.

      2) Pre-processing the CS to look for the method names by

regex and then convert them to CS, before the processing starts. This method is a bit more brute-force and lots more error prone. I can think of lots of stuff that would go wrong. I’d consider it a last-ditch idea in case the CS compiler wasn’t easily monkey-patchable.

Sorry, but that was not my concern when I asked you about the

implementation.

I'd like to know how you think this should be implemented in the

Rails side.

Given that the CS compiler detected "product_path(id)", how should

it proceed to replace it with JS or CS code?

Ok, give me an evening to read the internals of routing and I’ll come back to you with some suggestions/code.

20

No pressure at all :slight_smile: I’m using a patched version of js-routes right now:

[https://github.com/railsware/js-routes/pull/46](https://github.com/railsware/js-routes/pull/46)

I'd certainly appreciate your effort on that, but I'd just like to

advice you on thinking about the solution in the Rails side first as I guess this is the hardest part.

You can take a look at the js-routes source code to have some ideas

though.