Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Flash message appears on yoursite.com and does not appear on the page that is loaded after the form is submitted. Oops.

Doesn't really seem like an oops to me.

State breaks the internet.

You submitted a form. That presumably changed the state of the resources at that url too.

The page should set the flash state when the state transition is done, not when it starts. It shouldn't matter if the user sees the message on the page after the form or from a different page altogether. What if every page had a history of all of the flash messages ever produced? You wouldn't call that "state" any more or less than the state of the objects you were trying to change in the form itself.

I think the part of this you actually don't like is that the following GET implicitly deletes the state (which is why we can optimize and store it in session rather than the db). But when the state is "messages unseen by the user" then it seems reasonable to me.

I think we can agree that any state where it matters what page they view the message on is probably not a good candidate for flash. I'm not even a rails programmer but I think there are better examples for the state-is-bad idea.



Consider applying for YC's Winter 2027 batch! Applications are open till November 2.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: