automatic return from render and redirect

From a web application point of view, you're usually done after you deliver some content to the client, which in Rails means a render or redirect call usually.

For 99.99% of the cases, there'll be a return following a render or redirect inside some "if".

Some might prefer something like

(render login_url; return) unless authenticated?

Others will prefer something more verbose like

unless authenticated?
     render login_url
     return
end

Others will rely on some undocumented feature of render that might change any time:

render login_url and return unless authenticated?

render (or redirect_to) is not guaranteed to return a truthy value, specially because it really doesn't make any sense for the returning result to have any meaning.

So, I'm suggesting that Rails could support some automatic "return" after each call to render or redirect_to, by calling the method inside a catch-throw block.

For example:

class Dispatcher
     def dispatch(controller, action)
         catch :redirected_or_rendered do
             controller.send action
         end
     end
end

class AbstractController
     def render(*args) # or redirect_to
         do_render(*args)
         throw :redirected_or_rendered
     end
end

Maybe new method names like render_and_return and redirect_and_return could be added for backward compatibility, although I would really prefer to use render and redirect_to with this behavior built-in.

Maybe we could add some option like "Rails.application.config.automatic_return_from_render_or_redirect = true".

Is there any interest on adding such behavior to Rails?

Cheers,

Rodrigo.

throw/catch for flow control is bad.

Nope, I think the current way of doing things is just fine.

throw/catch for flow control is bad.

Indeed it is. It's the one thing in Sinatra I always disliked.

If I had to choose, I would go down the path of render/redirect
returning a response, so you would do something like `return render
:new` or `return redirect_to @object`.

This has the added bonus that it's compatible with 99.9% of the uses
of render and redirect (being the last line of an action/conditional)
thanks to the implicit returns.

def create
  @obj = Obj.new(…)

  if @obj.save
    redirect_to @obj, notice: …
  else
    render :new
  end
end

That still works as expected.

But if you did:

def create
  render :foo
  render :bar
end

You get the response generated by "render :bar" and the other one is
ignored. Because it's just an object returned, instead of some black
magic depending on class state.

That said, this would require quite the refactoring in ActionPack.

But it would be much cleaner, IMHO.

Cheers,
-foca

Yehuda Katz
(ph) 718.877.1325

throw/catch for flow control is bad.

Indeed it is. It’s the one thing in Sinatra I always disliked.

If I had to choose, I would go down the path of render/redirect

returning a response, so you would do something like `return render

:neworreturn redirect_to @object`.

This has the added bonus that it’s compatible with 99.9% of the uses

of render and redirect (being the last line of an action/conditional)

thanks to the implicit returns.

def create

@obj = Obj.new(…)

if @obj.save

redirect_to @obj, notice: …

else

render :new

end

end

That still works as expected.

But if you did:

def create

render :foo

render :bar

end

You get the response generated by “render :bar” and the other one is

ignored. Because it’s just an object returned, instead of some black

magic depending on class state.

That said, this would require quite the refactoring in ActionPack.

It actually wouldn’t require major refactoring. The work we did in 3.0 made this possible. Unfortunately, it breaks some common scenarios:

def create

render :foo

Rails.logger.info “hi”

end

def create

@bar = “1”

lack of render here currently means implicit render, but now the return value is a String

so it would be rendered

end

etc.

raise-rescue is intended for exception handling, while catch-throw is intended for regular control flow in Ruby.

Another possible syntax would be redirect_to and render returning an object that would respond to 'and_return', like:

redirect_to(login_path).and_return unless authenticated?

This reads much better than "return render ..." and is also backward compatible...

raise-rescue is intended for exception handling, while catch-throw is
intended for regular control flow in Ruby.

Right. There's a reason you don't see it often in Ruby code bases.
It's slow, hard to understand, and just generally a bad idea.

Let me know if you find any performance impact on this application:

https://github.com/rosenfeld/ctbenchmark