4 ms·
It's not really mixed in with your views. You would put in a .js file that has nothing but javascript in it. Some benefits I see are: 1. It just works perfect
by rartichoke 13y ago
It's not really mixed in with your views. You would put in a .js file that has nothing but javascript in it.
Some benefits I see are:
1. It just works perfectly with and without javascript which means your stuff gets crawled by search engines and it works great for people without JS. Then if you have JS enabled you get the enhanced UI.
In #1's case I do this all the time for search boxes. In admin dashboards that I make with rails I allow people to search for data.
It's trivial with rjs to implement a solution that works with no javascript and then if you have JS enabled you get your search results shown immediately without a full page reload.
2. You can tell the rjs code to use server side (erb) partials that you already have created so you don't need to have templates made for both.
Or in #2's case if you just use jquery without using any template engine it gets super messy trying to append elements to another element with inline html strings. All of that is eliminated by using your existing erb partials.
- izietto 13y agoI mean that you would have JS in your app/views folder together with the HTML views, instead of the assets folders only. 1. It doesn't depend from RJS/render :json, but from the fact that your controller responds to sync requests, in addition to the async ones. 2. You can tell to render :json to use server side (erb) partials: render json: { html: render_to_string(partial: 'product') } I do it all the time
- rartichoke 13y agoI didn't know about #2, that's really cool. How does render_to_string handle cached partials? Does it still need to compute the output of the partial's string representation on every request?