On 1 June 2012 17:10, Steve Schwartz <[email protected]> wrote:
> 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? :)
>
>
> -- Steve Schwartz
>
> On Friday, June 1, 2012 at 11:55 AM, Jeremy Walker wrote:
>
>
>
> On 31 May 2012 14:10, Rodrigo Rosenfeld Rosas <[email protected]> wrote:
>
> 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
>
>
>
> 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 %>
> <% 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.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To post to this group, send email to
> rubyonrails-core@googlegroups.**com<[email protected]>
> .
> To unsubscribe from this group, send email to
> rubyonrails-core+unsubscribe@**googlegroups.com<rubyonrails-core%[email protected]>
> .
> For more options, visit this group at http://groups.google.com/**
> group/rubyonrails-core?hl=en<http://groups.google.com/group/rubyonrails-core?hl=en>
> .
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/rubyonrails-core?hl=en.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/rubyonrails-core?hl=en.
>
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
