It used to be the fact that if you set flash[:notice] and try to render the page, the flash message will not be displayed. That’s why they have to implement flash.now. Is that still the case?
Currently if you set flash[:notice] and render, it’s available both in this request during the render, and in the next request.
With what I’m proposing, flash[:notice] would only be available in this request. If you redirect, rather than render, it would be available next request. (And flash.now goes away.)
I sometimes use flash to keep things between multiple request ex.
searched word and use FlashHash#keep in before filter to keep it when
user is still using the same controller. How can I keep something for
the next request when rendering in your proposed solution? Would I
have to set flash and keep it in the same request ?
I sometimes use flash to keep things between multiple request ex.
searched word and use FlashHash#keep in before filter to keep it when
user is still using the same controller.
Can you provide more info on what you’re doing with this searched word? Highlighting?
My initial reaction is it’s a dubious practice, because it relies on the user visiting the same controller action in the next request. If they open a page in another tab, for instance, it’d get messed up.
I’d usually favor embedding that parameter in the form for the next request (e.g., for a search form, prepopulate the query box with the searched word). If you want it to persist for longer, then perhaps cookie/session storage makes more sense.
How can I keep something for
the next request when rendering in your proposed solution? Would I
have to set flash and keep it in the same request ?
flash[:keyword] = “searched term”
flash.keep :keyword
render :search
Something like that. Or even:
flash.keep[:keyword] = ‘searched term’
i.e., keep the common case clean, at the expense of making the unusual case a bit more work.
Can you provide more info on what you're doing with this searched word?
Highlighting?
I was just using it for coherent navigation. You could go like search
=> show => edit => update => index and see the list filtered with the
searched keyword.
My initial reaction is it's a dubious practice, because it relies on the
user visiting the same controller action in the next request.
Well, that was exactly my point. I expected the user to visit same controller.
If they open a
page in another tab, for instance, it'd get messed up.
Unfortunately true.
I'd usually favor embedding that parameter in the form for the next request
(e.g., for a search form, prepopulate the query box with the searched word).
If you want it to persist for longer, then perhaps cookie/session storage
makes more sense.
cookie/session store has exactly the same problem as flash (in another
tab). In fact flash is stored in session. It is a serialized hash. The
only solution for doing it right is to keep that searched word in url.
But that requires you to write some abstraction over link_to or
remember to add additional parameter to every possible link_to that is
leading to same controller. Cumbersome.
How can I keep something for
the next request when rendering in your proposed solution? Would I
have to set flash and keep it in the same request ?
If someone is considering re-working flash message behavior, I’d like to throw in my +1. I previously encountered issues with them (Some examples of bugs: https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/4082-flash-loses-messages-on-redirect ) and landed on a solution much like George Ogata describes, which is simple to implement and much less error-prone. flash[:foo] is saved only for the duration of a request if rendering occurs, but contents are stored if a redirect occurs.